[vlc-devel] [PATCH] Patch to fix bug #1532, and improve http seek times.

[Rémi Denis-Courmont]

Le vendredi 13 juin 2008 20:29:30 Bill C. Riemers, vous avez écrit :
> Seek operations can always be fast.  All you do is defer any IO.

But VLC demuxers usually read data immediately after they have sought, so you 
can only by one function call (a few nanoseconds, right). Even your local 
hard drive won't be fast enough.

> What do you think happens when you do a NFS seek? When the seek returns,
> has the next data block been sent across the wire?

Even for local filesystems, lseek will not physically move the hard drive 
heads, until the next read.

> No it just told the 
> kernel the next place you want to read from.  From that point on the
> kernel is busy negotiating with the NFS server to get you that data as
> soon as possible.   Even when you request a seek off your hard drive,
> the same thing happens.   The seek doesn't return when the hard drive
> head has moved to the new data location, it returns when kernel has been
> told were that location should be...
>
> If we want the exact same behaviour  for  http, we simply need to
> implement the same code logic in user space.   But that is really
> optimizing read speeds...

There are two big differences.

First, HTTP is (most) commonly used over high-latency links, whereas NFS is 
mostly (if not only) used over low-latency local area networks. Of course, if 
you use HTTP and NFS between the same client and server pair, you may notice 
identical performances (I suspect HTTP will even outperform NFS), but 
the "normal" usage patterns are different.

Second, NFS is a filesystem protocol, whereas HTTP is file transfer protocol. 
With HTTP, you need to close the connection, open a new one, and start a 
brand new request, because you cannot interrupt a running transfer otherwise. 
HTTP simply sucks at random access. I bet the NFS performance degrades a lot 
less from sequential to random access than that of HTTP.

-- 
Rémi Denis-Courmont
http://www.remlab.net/