[mythtv-users] Hard disk speed needs for MythTV system

Dave Stewart davs2rt at earthlink.net
Thu Sep 25 22:39:34 EDT 2003


Thank you, for appreciating it!

Dave

On Wed, 2003-09-24 at 23:36, Itai Tavor wrote:
> 
> On Monday, September 22, 2003, at 01:03 PM, Date Stewart wrote:
> >
> > As with a lot of things in computers, "it all depends...."
> >
> > With modern interfaces, the usual limiting factor in data transfer is
> > how fast bits are going by the read/write head.  That varies with bit
> > density on the platters, number of platters, disk size, etc. etc.  Of
> > course, you only approach these maximum speeds when you're reading long
> > runs on a largely unfragmented disk, but this is typical for video.
> >
> > A fragmented file can invoke several seeks during a file, drastically
> > reducing overall bandwidth.  We did some experiments with 2 and 4 gig
> > SCSI disks several years ago, and files with more than 2-3 fragments
> > were significantly compromised.  For short (system) files, the limiting
> > factor is the finding the right block through the file system, not the
> > read bandwidth.  But I digress...  (Is anyone looking at 
> > defragmentation
> > in Linux and/or video4linux?)
> >
> > But some generalities: on identical platters, 5400 rpm drives should
> > deliver data 54/72ths as fast, about 75%.  Also, since more bits can be
> > put on an outer cylinder than an inner cylinder due to the longer
> > circumference, the data rate is higher at the beginning of the disk 
> > than
> > at the end (inner tracks). I Googled a few references: A Western 
> > Digital
> > 40GB 5400RPM drive was tested at ~30MByte/sec (outer tracks) and ~22
> > MB/sec (inner).  A WD 120GB 7200RPM drive was closer to 50 MB/s outer
> > and 35 MB/s inner.  (I don't know what the platter densities were.)
> >
> > However, the implications are pretty clear.  If an older 5400 RPM drive
> > will deliver a 22 MB/second worst case stream, it *should* be able to
> > record two or three sub-1 MByte/second video capture streams, provided
> > the OS isn't doing something really dumb.  You could imagine a
> > degenerate case where the file system tries to interleave writing 1
> > block of each of 2 video files on opposite ends of the disk,
> > guaranteeing a worst case seek per block written. Personally, I know
> > nothing about the internals of the Linux file system, but I've been 
> > told
> > that it optimizes these situations correctly.
> >
> > One other factoid: it's been years since disks were interleaved.  The
> > point of interleave was that in the olden days, the disk controllers
> > were not fast enough to read, decode and error check sequential sectors
> > on the disk.  Instead, a sector or more would pass under the head,
> > unread, while the controller worked.  Therefore the "next" sector was
> > not adjacent, but interleaved with one or more sectors that were part 
> > of
> > a different sequence. As controllers got faster, interleave eventually
> > achieved 1:1, i.e. sequential sectors.
> 
> Dave, this is an excellent in-depth analysis. Thanks!
> 
> ----
> 

> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users




More information about the mythtv-users mailing list