In case this is not immediately clear: theoretically preventable 1rtt minimum delays are much less bad than the practically unbounded maximum delays in congested networks.
Put in another way: making some few things fast is much more easy than making sure that everything else doesn't get infinitely slow as a result to this. Right now huge streams don't get huge unfair advantages unless the rtt is very small or the parallelism very high On 6/1/22, hiro <23h...@gmail.com> wrote: > I don't think the reason nobody is doing this is that it's difficult per > se. > > Fcp also achieves parallelism without any changes to 9p. > > And posix fs also share some of our statefulness. > > A file system can have offsets, readahead can help. > > Other synthetic FS need different tricks, but we can exchange some > guarantees that are only needed in seekable files for an optimization > that shall only be done on pipes and streaming access. > > There's some trivial heuristic solutions for this but they are not > generic naturally. > > If one were to do this right, after a few increments one will see that > bandwidth limits are hit, which is a new problem that is much harder > to solve and impossible without even more heuristics classifications > possibly applied by a distributed 9p scheduler (dynamic multi hop > network congestion awareness anybody?) > > On 6/1/22, ron minnich <rminn...@gmail.com> wrote: >> On Tue, May 31, 2022 at 11:29 AM hiro <23h...@gmail.com> wrote: >>> >>> so virtiofs is not using 9p any more? >>> >>> and with 10 million parallel requests, why shouldn't 9p be able to >>> deliver 10GB/s ?! >> >> Everyone always says this. I used to say it too. >> >> 9p requires a certain degree of ordering -- as Andrey once pointed >> out, it's not productive to close a file, then write it. So there is a >> tricky ordering requirement you need to get right, due to Plan 9 being >> stateful. >> >> The way we use 9p in Plan 9, as a general purpose protocol for >> everything, like devices, requires that each Tread or Twrite occur in >> order, but also requires that each T be retired before the next T is >> issued. devmnt does this. If you don't do this, hardware can get >> confused (e.g. ordering of Twrite followed by Tread followed by Twrite >> needs to be maintained. E.g. you don't want to issue the Tread before >> you know the Twrite happened. E.g. pre-posting 100 Treads to >> /dev/mouse is not a good idea if you suddenly want to do a Twrite in >> the middle of it). >> >> This is why 9p starts to perform poorly in networks with high >> bandwidth*delay products -- if you watch the net traffic, you see each >> T op on fid blocked by the previous Reply (by devmnt). >> >> I never figured out a way to fix this without fixing devmnt -- by >> removing its general nature. >> >> But, more to the point, whether or not 9p should be able to do all >> these parallel requests and get high performance, nobody has yet done >> it. The only numbers ever reported for making high bandhwidth*delay >> networks better were in Floren's thesis, when he added Tstream. >> >> After 20+ years of this discussion, I start to wondering whether it's >> harder than it looks. >> >> ron ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T769854fafd2b7d35-M099a56feb7c401cc1d0b3ed6 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
