Re: [9front] Slow cp, support for 9P2000.s

[Romano <unobe@cpan.org>]

Thank you, Aiju!

Using fcp , I get 0.36u 0.70s 25.66r, so more than halving the time. And in retrospect I should have read the man page for cp first, where I would have seen fcp.

I lurk on reddit.com, so no account. I see there's reddit.com/r/9P2020, but it's private. Is the discussion re: 9P2020 mostly there, or elsewhere? I grepped 9P2020 under /n/lists/9front and only saw your message to me.



On April 24, 2020 4:28:15 AM UTC, aiju <aiju@phicode.de> wrote:
>Yes his solution has been discussed and found wanting. If I remember
>right 
>it breaks the syscall interface and forces 9P to run over TCP.
>
>There have been ongoing talks about our own protocol 9P2020 to solve
>this 
>problem, but little progress because it's a hard problem to solve
>properly 
>without messing up Plan 9 too much.
>
>In the meantime, `fcp` is fast cp.
>
>- aiju
>
>
>
>On Fri, 24 Apr 2020, Romano wrote:
>
>> On my local wireless network at home between my work laptop and my
>rpi 4, I tested using 'cp' while in drawterm.  I ran drawterm -G on my
>rpi, and used srvfs to export its file system. I ran drawterm on my
>work laptop, and mounted the exported filesystem as /n/pi.  I then
>timed a 20MB file from /mnt/term/root/ on my work laptop to the /n/pi:
>0.20u 0.82s 70.14r. 70s is atrociously slow for a local copy when
>compared to http or scp, so I decided to look to see if this was known
>and if any work had been done on this problem for 9p.  I came across
>John Floren's thesis from 2010[1] and his testing showed that increased
>latency over 9p significantly increased the time files took to
>transfer. He also shows modifications to 'cp' and 'exportfs' to allow
>for streams to make 9p have similar speeds as http.
>>
>> So considering Floren's research, I then decided to look at my
>latency on my local network, and sure enough, I'm getting the following
>ping results (for 144 packets transmitted, with 1 packet lost):
>round-trip min/avg/max/stddev = 2.273/15.264/497.869/44.018 ms . With
>an average latency of 15ms, the time it took for  20MB file to transfer
>over 9p roughly matches Floren's tests.
>>
>> I think that modifying 'cp' and 'exportfs' would resolve this problem
>and will look at patching it per Floren's thesis to confirm.  Would
>modifying 'cp' and 'exportfs' to allow for streams be something others
>would be interested in? Or has this already been discussed and the
>stream solution been found wanting for some technical reason? The
>protocol, as mentioned in the paper, is called 9P2000.s. I don't see
>that flavor listed here: http://9p.cat-v.org/implementations
>>
>> [1]
>https://pdfs.semanticscholar.org/9b47/22e251df61b4abbe0da61720e57ac7b62f61.pdf
>>