9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: ori@eigenstate.org
To: 9fans@9fans.net
Subject: Re: [9fans] Dual dialing/forking sessions to increase 9P throughput
Date: Wed, 27 Jan 2021 08:52:22 -0800	[thread overview]
Message-ID: <21AE5944012F26AD61546F797F677050@eigenstate.org> (raw)
In-Reply-To: <bf9df1d7-20ee-4dc2-9445-f18dc983a15a@www.fastmail.com>

Quoth David Arroyo <droyo@aqwari.net>:
> On Tue, Dec 29, 2020, at 18:50, cigar562hfsp952fans@icebubble.org wrote:
> > It's well-known that 9P has trouble transferring large files (high
> > volume/high bandwith) over high-latency networks, such as the Internet.
> 
> From what I know of 9P, I don't think this is the fault of the protocol
> itself. In fact, since 9P lets the clients choose Fid and Tag identifiers,
> it should be uniquely well suited for "long fat pipes". You could avoid
> waiting for round-trips by optimistically assuming your requests succeed.
> For example, you could do the following to optimistically read the first
> 8K bytes of a file without needing to wait for a response from the server.
> 
> * Twalk tag=1 fid=0 newfid=1 /path/to/somefile
> * Topen tag=2 fid=1 o_read
> * Tread tag=3 fid=1 off=0 count=4096
> * Tread tag=4 fid=1 off=4096 count=4096
> * Tclunk tag=5 fid=1
> 
> I'm not aware of any client implementations that do this kind of
> pipelining, though.
> 
> David

This also has some hairy edge cases. For example,
what happens to the actions in the pipeline if one
of the operations fails?

I think that for this kind of pipelining to be
effective, 9p may need some notion of 'bundles',
where the first failure, short write, or other
exceptional operation would cause all other
commands in the bundle to be ignored.

Another issue is that its' difficult to retrofit
this pipelining into the plan 9 system call
interface; when do you return an error from
read(2)? what if there are mutiple Treads?

Finally, there's the problem of flow control;
with 9p, round trip time limits starvation,
at least to a degree. But how do you handle
congestion if you can stuff as many 9p packets
down a single connection as possible? There's
no packet loss, but you can end up with very
long delays as small reads like /dev/mouse
get queued behind bulk transfers.

There are some programs that try to handle this
for 'well behaved' file systems (eg, fcp(1),
or http://src.a-b.xyz/clone/, but making it
happen in general is not trivial.


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-Maff5e0961941062961ff4f2d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

  parent reply	other threads:[~2021-01-27 16:52 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-29 23:50 cigar562hfsp952fans
2020-12-30  8:12 ` [9fans] " joey
2021-01-03 23:51 ` [9fans] " Ethan Gardener
2021-01-04 10:55   ` Ole-Hjalmar Kristensen
2021-01-04 11:03     ` hiro
2021-01-04 19:08       ` joe
2021-01-04 20:44         ` hiro
2021-01-04 21:01         ` ori
2021-01-05  3:41 ` Joe S
2021-01-05  9:40   ` hiro
2021-01-06 22:21   ` [9fans] " cigar562hfsp952fans
2021-01-07  8:06     ` hiro
2021-01-07 16:02   ` [9fans] " ori
2021-01-25 22:31 ` David Arroyo
2021-01-27 16:25   ` Ethan Gardener
2021-01-27 16:52   ` ori [this message]
2021-01-27 17:34     ` Charles Forsyth
2021-01-28  0:17     ` David Arroyo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=21AE5944012F26AD61546F797F677050@eigenstate.org \
    --to=ori@eigenstate.org \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).