[Gllug] Embedded Linux & 1Gbps?

[Nix]

On 18 Oct 2007, Thomi Richards said:

> On 10/17/07, Nix <nix at esperi.org.uk> wrote:
>> For normal I/O, and especially for things like find(1), the delay is on
>> the disk end. I know my 100Mb/s network can throw data around somewhat
>> faster than the RAID-5 array backing its NFS-mounted drives can read or
>> write data. (Maybe much faster disks could fix this, but the PCI bus
>> isn't all that terribly fast itself...)
>
> Why is that though? Surely the data transfer rate should be constant,
> no matter what the file size?

Well, yes, but you notice delays more if you're throwing gigabytes
around. Any non-caching network filesystem is going to be slower than
local disks even if the local disk is slower than the network
connection, because any I/O has to come over *both* the disk and
network, and so you'll get the slowest of either of them at any
moment. You've got more essentially serial buses involved, so you're
going to get more serialization.

> For example, when streaming a large movie over NFS, if I seek to half
> way though the movie, it takes *ages* - surely NFS doesn't try and
> transmit the entire first half of the file?  Although I guess this
> might have more to do with the way the movie player is written rather
> thant he disk protocol, right? I always assumes that mplayer (and
> others) just did a seek() call to get to the right place in the file,
> but I guess that would depend on the file format (many media formats
> aren't that simple)..

They're invariably not that simple. With most video formats they'll seek
to get to a keyframe (often there's one of these every ten or twenty
seconds), but then they'll have to read everything from there up to the
point you actually seeked to.

-- 
`Some people don't think performance issues are "real bugs", and I think 
such people shouldn't be allowed to program.' --- Linus Torvalds
-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug