From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <413bc7b7a183474c7405763c23674fe6@brasstown.quanstro.net> References: <413bc7b7a183474c7405763c23674fe6@brasstown.quanstro.net> Date: Sun, 5 Jan 2014 17:02:23 +0100 Message-ID: From: Rudolf Sykora To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] chess? Topicbox-Message-UUID: ada82ada-ead8-11e9-9d60-3106f5b1d025 On 5 January 2014 15:36, erik quanstrom wrote: >> Thanks, this is possibly a way, but, at least in my case, this takes age= s... >> (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=C2=B5s. > > 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=3D find 708642= 1: 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/n= ull > 0.00u 0.00s 33.61r rc -c fcp lsr /tmp && grep chess /tmp/lsr >/dev/= null > Thanks for the information! R