> 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
