Re: [9fans] Modern development language for Plan 9, WAS: Re: RESOLVED: recoving important header file rudely

[erik quanstrom <quanstro@quanstro.net>]

> The point I was trying to make (but clearly not clearly) was
> that simplicity and performance are often at cross purposes
> and a simple solution is not always "good enough".  RPC
> (which is what 9p is) is simpler and perfectly fine when
> latencies are small but not when there is a lot of latency in
> relation to the amount of work doable with each rpc call.

this is a pretty general claim.  but i don't see the argument.

the difference between, e.g. tcp and an explicitly rpc protocol
like 9p is basically 2 relevant things
1.  9p requires 1:1 message and reply; tcp can combine replies
2.  9p sends a set of tagged messages; tcp sends an ordered byte
stream.

i don't see how either one is necessarly going to slow 9p down.

the structure of 9p (tagged rpc) is the same for reads & writes
as aoe.  aoe is always talking over a long fat network
with large jitter, as disk drives are slow and sometimes misseek
but have relatively large bandwidth.  i've had no trouble filling
even 10gbe pipes with aoe traffic.

> Instead of reading/writing in small chunks, you want to
> minimize the number of request/response round trips by
> conveying information at a more abstract level (which is
> what rsync does).

that's not what rsync does.  rsync calculates and sends the
differences.  that's not on the same planet as 9p.

by the way, rsync is fundamentally broken.  it takes unbounded
memory to do its job.

> It is inherent to 9p (and RPC).

please defend this.  i don't see any evidence for this bald claim.

> I think it is worth looking at a successor protocol instead
> of just minimally fixing up 9p (a clean slate approach frees
> up your mind.  You can then merge the two later).

what is the goal?  without a clear problem to solve that you
can build a system around, i don't see the point.  making replica
fast doesn't seem like sufficient motivation to me at all.

as to the problem of latency, i think there are two things
i note

1.  plan 9 can work well with latency.

most days i do some link that has 25-2000ms latency.
the way plan 9 is structured, this latency is not very noticable
until it reaches ~750ms, and then only when i'm saving files,
or sometimes, due to an oversite or bug in acme, when searching.
clearly a kernel mk over a 2000ms link will take nearly forever,
but you don't have to do that.  you can cpu where you need to
be and work there.

2.  at cross-u.s. latencies of 80ms, serial file operations like
mk can be painful.  if bringing the work to the data doesn't work
or still takes too many rtts, the only solution i see is to cache everything.
and try to manage coherence vs. latency.

- erik