Re: [9fans] 9p server to multiply 9p messages?

[hiro <23hiro@gmail.com>]

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 <23hiro@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 <rminnich@gmail.com> wrote:
>> On Tue, May 31, 2022 at 11:29 AM hiro <23hiro@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