[Live-devel] Live555 performance configuration

[Patrick White]

On Saturday 07 February 2009 2:00 pm, Morgan Tørvolt wrote:
> The calculations are easy. A disk with 100MB/s read speed and 10ms
> access time will give you 1MB per 10ms read time. If you read 1MB at a
> time on random spots on the disk, you will use 10ms per read, and 10ms
> on average for moving to the next spot on the disk. Effectively giving
> you a maximum 50MB/s because half of your read time goes to moving the
> disk read heads.

This is only valid if A) the filesystem subsystem supports 1MB atomic reads, 
and B) the file isn't fragmented.  Win, for example, reads in 64KB chunks.  
Its still faster to ask the filesystem to read 1MBwith a single syscall than 
ask it to read (16) 64KB chunks, but if you try to do simultaneous reads on 
that filesystem you'll probably interleave reading of 64KB chunks and kill 
your throughput with the seeks.

> If you only read 10KB per read, the read will take 
> only 0.1ms, but the head will still use 10ms to move around. Theory
> will then give you 0.1ms read time every 10.1ms, giving you somewhere
> around 1MB/s throughput. Cache and block sizes might improve this
> somewhat, but you get the idea. Read large chucks.

This is true, but not for those reasons.  Most filesystems, and the disk 
hardware too these days, reads ahead.  Unfortunately, they only read ahead 
sequentially on the same track, so it only helps if the file is on the disk 
sequentially.

The suggestion to use multiple spindles and manage disk load in your code is 
probably the best solution.  An ordinary DMA100 PATA drive (128GB drive, 
3.5", linux, sans filesystem) can do 40 MB/Sec sustaiend sequential read or 
write, and only 3-4 MB/sec sustained simultaneous sequential read and 
sequential write.  Newer generation of disks and SATA should be able to 
handle more, but you'll still want to ensure the file is on the media 
sequentially and not write anything to the spindle that you're reading from.  
With more spindles on the job, you'll have to worry less about those sorts of 
issues, and be at less risk if one fails.  With a hand-written mirroring 
program designed not to saturate the disk interfaces, you might even be able 
to mirror from an existing drive to a new one while up and serving -- if 
downtime is an issue, this could be a significant time savings as you're only 
completely down long enough to swap physical media.