it might be worth instrumenting the cpu command to time the authenticaiton step. i think that's where the problem is. On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian wrote: > what's the latency caused by the auth step? > FYI, from Seattle I see about 8 seconds to establish but as Charles noted, > it's reasonably fast after that. > > > On Wed, May 11, 2016 at 2:05 PM arisawa wrote: > >> Hello, >> >> we can measure the latency that comes from network connection >> by executing simple program such as telnet or something others >> to the port 8006 of grid.nyx.link. the content is: >> #!/bin/rc >> cat $net/local >> cat $net/remote >> >> yes the DNS may make a problem in IPv4/IPv6 mixed environment. >> my server supports both IPs. >> the cpu command will select IPv4. the command does not have “-6” option. >> If we want to connect by IPv6, literal IP address is required in the >> argument of the command. >> >> Kenji Arisawa >> >> > In my experience, it's almost unfailingly the DNS that slows down >> > establishing an Internet session of any type. >> > >> > Lucio. >> >> > 2016/05/12 0:23、Kenny Lasse Hoff Levinsen >> のメール： >> > >> > Well, based on the 9fs test that was posted, I'd think dial is being >> awfully slow. >> > >> > Maybe try something simpler? aux/listen1 echo hello and a simple >> network connection? >> > >> > Best regards, >> > Kenny Levinsen >> > >> > On 11. maj 2016, at 16.13, Charles Forsyth >> wrote: >> > >> >> >> >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen < >> kennylevinsen@gmail.com> wrote: >> >> Delete the channel from /srv in the loop to test a full remote mount >> dance, including the initial dial. It shouldn't take 3s to dial, though. >> >> >> >> There's something initially slow in connecting to grid.nyx.link with >> cpu, and setting up, but once there it's fine. >> >> >>