From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from phicode.de ([46.4.114.246]) by ewsd; Fri Apr 24 00:28:19 EDT 2020 Comment: DomainKeys? See http://domainkeys.sourceforge.net/ DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=phicode.de; b=lIpcTFkh2kh+NeUwWExxSZAaajgAddi0NF4zcvPJSGx8VYcPGYW+BpvHXW051Vo2ftcafO/ggStKymKInTnNSXh2ZznVhtSa/iIQyMys5T1gpsLwkjOtFeLaSVi06P3NL19wdnOeRxp4J1LO+P3zyBVKv7twfHTLQ1IWZpY8rzI=; h=Received:Received:Date:From:To:Subject:In-Reply-To:Message-ID:References:User-Agent:MIME-Version:Content-Type; DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=phicode.de; h=date:from:to :subject:in-reply-to:message-id:references:mime-version :content-type; s=default; bh=sYi6GLAf1zyHav95VtYILimY7mg=; b=ba7 Xd25aN+aNCbx4ds7FZGY8dixKOyT0vD88isrTE0q4OVfe8EPwQJt4/ki7/VonuO4 7bZMp7YpC/0B3WMLFKyxXpWVHfhEq8twn68KJg3CutMIbaCiPh2xjHkB4TVKaoLp wUdXh/5nuKKGRsIebPnFVR5ITLWyNPW3uqmzSEqs= Received: (qmail 11208 invoked from network); 24 Apr 2020 04:28:16 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Apr 2020 04:28:16 -0000 Date: Fri, 24 Apr 2020 06:28:15 +0200 (CEST) From: aiju To: 9front@9front.org Subject: Re: [9front] Slow cp, support for 9P2000.s In-Reply-To: <2DE413B1-B05D-45EF-A08A-6F9F119FB745@cpan.org> Message-ID: References: <2DE413B1-B05D-45EF-A08A-6F9F119FB745@cpan.org> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: firewall plugin-aware SQL over XMPP framework out-scaling extension 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 >