From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> In-Reply-To: <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> From: Skip Tavakkolian Date: Wed, 11 May 2016 22:39:38 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c07e9e806fdaa053298b82b Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ee0ec08-ead9-11e9-9d60-3106f5b1d025 --94eb2c07e9e806fdaa053298b82b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =E2=80=9C-6= =E2=80=9D 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=E3=80=81Kenny Lasse Hoff Levinsen > =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > > > > 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 networ= k > 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. > > > --94eb2c07e9e806fdaa053298b82b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
what's the latency caused by the auth step?
FYI, f= rom 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 P= M arisawa <arisawa@ar.aichi-= u.ac.jp> 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 =E2=80=9C-6=E2= =80=9D option.
If we want to connect by IPv6, literal IP address is required in the argume= nt of the command.

Kenji Arisawa

> In my experience, it's almost unfailingly the DNS that slows down<= br> > establishing an Internet session of any type.
>
> Lucio.

> 2016/05/12 0:23=E3=80=81Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com>= ; =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A
>
> Well, based on the 9fs test that was posted, I'd think dial is bei= ng awfully slow.
>
> Maybe try something simpler? aux/listen1 echo hello and a simple netwo= rk connection?
>
> Best regards,
> Kenny Levinsen
>
> On 11. maj 2016, at 16.13, Charles Forsyth <charles.forsyth@gmail.com> w= rote:
>
>>
>> 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 mou= nt dance, including the initial dial. It shouldn't take 3s to dial, tho= ugh.
>>
>> There's something initially slow in connecting to=C2=A0 grid.n= yx.link with cpu, and setting up, but once there it's fine.


--94eb2c07e9e806fdaa053298b82b--