Re: [9fans] chess?

[Rudolf Sykora <rudolf.sykora@gmail.com>]

On 5 January 2014 15:36, erik quanstrom <quanstro@quanstro.net> wrote:
>> Thanks, this is possibly a way, but, at least in my case, this takes ages...
>> (Say it can run for >45 mins; maybe much more; I do not know the true
>> reason why,
>> but I intuitively suspect the protocol.)
>> Therefore I asked for a more specific pointer.
>> Also, generally, there should be a quicker way.
>
> it's easy to blame the protocol.  but it's more than that.
> 0.  the i/o unit is just 8k, this means that directories like
> /sys/src/9 take 2 or more round trips.  this is trivial to fix
> by upping MAXRPC in devmnt.  i've uppted this to
> 56k + IOHDRSZ.  this makes a difference even when the
> rtt is 50µs.
>
> 1.  (or 0a) the kernel won't issue more than one concurrent
> rpc for the same request.
>
> 2.  find/du are single threaded, so they they take full rtt latency
> on each syscall.
>
> there's a small demonstration of 2 at the end of this email.
>
> - erik
>
> ---
> note that except for the fcp test, rtt dominates.  even 384kbps
> is more than enough to keep up.  in fact, except for the fcp
> test time_link0 * rtt_link0/rtt_link1 tracks pretty closely with
> the actual result.  since link1 is dsl, keeping track of the actual
> rtt could have reduced some of this error.
>
> link0:
> rtt ~ 32ms uplink/downlink ~ 100mbps/100mbps:
>
> 0.29u 0.37s 895.45r      rc -c find | grep chess  # status= find 7086421: errors|
> 0.03u 0.03s 68.77r       rc -c cp lsr /tmp && grep chess /tmp/lsr
> .0.04u 0.10s 5.40r       rc -c fcp lsr /tmp && grep chess /tmp/lsr
>
> link1:
> rtt ~ 52ms uplink/downlink ~ .384mbps/1.5mbps
> 0.00u 0.00s 1468.26r     rc -c find | grep chess
> 0.00u 0.01s 131.03r      rc -c cp lsr /tmp && grep chess /tmp/lsr >/dev/null
> 0.00u 0.00s 33.61r       rc -c fcp lsr /tmp && grep chess /tmp/lsr >/dev/null
>

Thanks for the information!

R