I thought russ (and charles and sape?) proposed a good solutions to the latency issues in 9P at IWP9. Actually as far as I can remember it was the only change to 9P that was accepted as justified.
My memory is bad, probably got the details wrong but I think there were two approaches: one by allowing multiple requests with the same tag to be grouped, and another with an extra flag filed that indicates if more messages in a group are on their way. I still don't understand what could be wrong with either approach (but again, I don't even remember the details of either) and why nemo had to invent yet another protocol. Maybe someone can enlighten my usual ignorance. uriel On 6/23/07, erik quanstrom <[EMAIL PROTECTED]> wrote:
> 9P is just great for use when latency is reasonable (or not too bad, > with cfs), but to go further > away and still be comfortable using remote files, I'd say we need > another protocol. > I'd love to be proved wrong :) are there any protocols that deal well with latency? the only way i know to deal with latency is to do some sort of tagged queueing. (perhaps i don't know enough computer history.) unfortunately, this doesn't work if part of the data you need depend on some prior part; a conversation means ping-pong communication. the great news for 9p is that latency is decreasing. in /sys/doc/net/net.ps, the IL/ether latency is listed as having a latency of 1420µs. my home fileserver has a 57µs latency to my cpu server. (the fileserver is a pIII with a $19 rtl8169.) even custom Cyclone interface between the file server and the cpu server is listed as having a latency of 375µs. let's hope the same holds true for wireless networking. - erik
