From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> Date: Thu, 12 May 2016 11:00:15 -0500 Message-ID: From: Balaji To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114e566a07d26b0532a7412b Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ef26e10-ead9-11e9-9d60-3106f5b1d025 --001a114e566a07d26b0532a7412b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable the ZKP process involves 3 synchronous round trips. SRP used to have same problem but they can now do it in 1.5 round trips. On Thu, May 12, 2016 at 10:40 AM, Skip Tavakkolian < skip.tavakkolian@gmail.com> wrote: > it might be worth instrumenting the cpu command to time the authenticaito= n > step. i think that's where the problem is. > > On Wed, May 11, 2016 at 3:39 PM Skip Tavakkolian < > skip.tavakkolian@gmail.com> 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 =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 >>> 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 wit= h >>> cpu, and setting up, but once there it's fine. >>> >>> >>> --001a114e566a07d26b0532a7412b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
the ZKP process involves 3 synchronous round trips. SRP us= ed to have same problem but they can now do it in 1.5 round trips.

<= div>
On Thu, May 12, 2= 016 at 10:40 AM, Skip Tavakkolian <skip.tavakkolian@gmail.com= > wrote:
it mi= ght 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 <skip.tavakkolia= n@gmail.com> wrote:
what's the latency caused by the auth step?FYI, from Seattle I see about 8 seconds to establish but as Charles note= d, it's reasonably fast after that.

=

On Wed, May 11= , 2016 at 2:05 PM 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.



--001a114e566a07d26b0532a7412b--