From mboxrd@z Thu Jan 1 00:00:00 1970 From: arisawa Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Wed, 11 May 2016 18:04:55 +0900 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: [9fans] cpu command latency Topicbox-Message-UUID: 8ea47f2a-ead9-11e9-9d60-3106f5b1d025 Hello, some people say that cpu command latency will be so big that world wide = grid computing using cpu command will be useless because of the latency.=20= unfortunately I don=E2=80=99t have experimental data. it seems bell-labs grid servers are now closed. latency data between japan and other country will be enough. I want to have those times: for(i in 1 2 3){ time cpu -h HOST -k =E2=80=98dom=3DDOM=E2=80=99 -c pwd sleep 3 } they are cache sensitive. therefore, we need to restart the plan9 = terminal in the experiment. if there are open grid servers for 9fans, I would do myself. let me know = if you know, please. I am also happy if someone give me data by accessing my grid server. then the HOST is grid.nyx.link and the DOM is = outside.plan9.bell-labs.com and need your bell-labs key in factotum. thanks in advance. Kenji Arisawa From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 11 May 2016 10:23:16 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114230da707f0a05328d9777 Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ea936aa-ead9-11e9-9d60-3106f5b1d025 --001a114230da707f0a05328d9777 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11 May 2016 at 10:04, arisawa wrote: > latency data between japan and other country will be enough. > > I want to have those times: > for(i in 1 2 3){ > time cpu -h HOST -k =E2=80=98dom=3DDOM=E2=80=99 -c pwd > sleep 3 > } > they are c > It takes ages to get through each time, 15 seconds, but if instead I cpu and type commands, the response is respectable, especially since /usr/forsyth comes from /mnt/term/usr being bound into your /usr so I'm not sure why the cpu command above is so slow. --001a114230da707f0a05328d9777 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 11 May 2016 at 10:04, arisawa <arisawa@ar.aichi-u.ac.jp><= /span> wrote:
latency data between japan and other country will be enough.

I want to have those times:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 for(i in 1 2 3){
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 time cpu -h HOST -k= =E2=80=98dom=3DDOM=E2=80=99 -c pwd
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 sleep 3
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
they are c

It takes ages to get through each ti= me, 15 seconds, but if instead I cpu and type commands, the response is res= pectable,
especially since /usr/forsyth com= es from /mnt/term/usr being bound into your /usr=C2=A0
so I'm not sure why the cpu command above is so slow.
=
--001a114230da707f0a05328d9777-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: Date: Wed, 11 May 2016 22:12:19 +0900 Content-Transfer-Encoding: 7bit Message-Id: References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8eb2a9ba-ead9-11e9-9d60-3106f5b1d025 thanks charles for your quick response. the times below are mount latency just after rebooting. the first is much larger than others. 0.00u 0.00s 3.73r 9fs sources 0.00u 0.00s 0.71r 9fs sources 0.00u 0.00s 0.21r 9fs sources with the script below: for(i in 1 2 3){ time 9fs $host unmount /n/$host sleep 3 } } probably cpu command latency will show similar behavior with much more time. Kenji Arisawa From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Kenny Lasse Hoff Levinsen Content-Type: text/plain; charset=us-ascii In-Reply-To: Message-Id: Date: Wed, 11 May 2016 15:44:36 +0200 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ebe004e-ead9-11e9-9d60-3106f5b1d025 Your loop only seems to dials the server once, then reuses the channel from /= srv. 9fs(4) is just a convenience wrapper for common hosts and tasks that ul= timately calls srv(4) and mount(1) as necessary - if the channel exists, it i= s simply a call to mount(1), which translates to an attach(5) 9P message on t= he existing connection. Delete the channel from /srv in the loop to test a full remote mount dance, i= ncluding the initial dial. It shouldn't take 3s to dial, though. Best regards, Kenny Levinsen > On 11. maj 2016, at 15.12, arisawa wrote: >=20 > thanks charles for your quick response. >=20 > the times below are mount latency just after rebooting. > the first is much larger than others. > 0.00u 0.00s 3.73r 9fs sources > 0.00u 0.00s 0.71r 9fs sources > 0.00u 0.00s 0.21r 9fs sources > with the script below: > for(i in 1 2 3){ > time 9fs $host > unmount /n/$host > sleep 3 > } > } >=20 > probably cpu command latency will show similar behavior with much more tim= e. >=20 > Kenji Arisawa >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 11 May 2016 15:13:05 +0100 Message-ID: From: Charles Forsyth To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11442b6cf4b12c053291a3c5 Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ec229e4-ead9-11e9-9d60-3106f5b1d025 --001a11442b6cf4b12c053291a3c5 Content-Type: text/plain; charset=UTF-8 On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen 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. --001a11442b6cf4b12c053291a3c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen <kennylevinsen@gm= ail.com> wrote:
Delete the channel from /= srv in the loop to test a full remote mount dance, including the initial di= al. It shouldn't take 3s to dial, though.

There&#= 39;s something initially slow in connecting to=C2=A0=C2=A0grid.nyx.link with cpu, and setting up, but once there it= 9;s fine.
--001a11442b6cf4b12c053291a3c5-- From mboxrd@z Thu Jan 1 00:00:00 1970 References: From: Kenny Lasse Hoff Levinsen Content-Type: multipart/alternative; boundary=Apple-Mail-CC7C1663-CD4C-4569-BF5C-D078F8188E34 In-Reply-To: Message-Id: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> Date: Wed, 11 May 2016 17:23:02 +0200 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ec6819c-ead9-11e9-9d60-3106f5b1d025 --Apple-Mail-CC7C1663-CD4C-4569-BF5C-D078F8188E34 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 con= nection? Best regards, Kenny Levinsen > On 11. maj 2016, at 16.13, Charles Forsyth wro= te: >=20 >=20 >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen wrote: >> Delete the channel from /srv in the loop to test a full remote mount danc= e, including the initial dial. It shouldn't take 3s to dial, though. >=20 > There's something initially slow in connecting to grid.nyx.link with cpu,= and setting up, but once there it's fine. --Apple-Mail-CC7C1663-CD4C-4569-BF5C-D078F8188E34 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Well, based on the 9fs test that was p= osted, I'd think dial is being awfully slow.

Maybe try something simpler? a= ux/listen1 echo hello and a simple network connection?

Best regards,
Kenny Levinsen

On 1= 1. maj 2016, at 16.13, Charles Forsyth <charles.forsyth@gmail.com> 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 t= he 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.
= --Apple-Mail-CC7C1663-CD4C-4569-BF5C-D078F8188E34-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <1481a54de76d90a6f92244d244739efe@proxima.alt.za> To: 9fans@9fans.net Date: Wed, 11 May 2016 17:58:26 +0200 From: lucio@proxima.alt.za In-Reply-To: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ecaea98-ead9-11e9-9d60-3106f5b1d025 > Well, based on the 9fs test that was posted, I'd think dial is being awfully slow. In my experience, it's almost unfailingly the DNS that slows down establishing an Internet session of any type. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> Date: Thu, 12 May 2016 06:05:04 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8edc55a8-ead9-11e9-9d60-3106f5b1d025 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. >=20 > 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 >=20 > Well, based on the 9fs test that was posted, I'd think dial is being = awfully slow. >=20 > Maybe try something simpler? aux/listen1 echo hello and a simple = network connection? >=20 > Best regards, > Kenny Levinsen >=20 > On 11. maj 2016, at 16.13, Charles Forsyth = wrote: >=20 >>=20 >> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen = 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. >>=20 >> There's something initially slow in connecting to grid.nyx.link with = cpu, and setting up, but once there it's fine. 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: Date: Thu, 12 May 2016 22:06:43 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1F52205A-BB37-480A-BE55-60394099481A@ar.aichi-u.ac.jp> References: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8ee5bd96-ead9-11e9-9d60-3106f5b1d025 Hello, > 2016/05/11 22:44=E3=80=81Kenny Lasse Hoff Levinsen = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > 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. thanks for the advice. I retried for(i in 1 2 3){ time 9fs $host #unmount /n/$host rm /srv/$host sleep 3 } term% try -m sources outside.plan9.bell-labs.com arisawa post... 0.00u 0.01s 1.31r 9fs sources post... 0.00u 0.03s 0.69r 9fs sources post... 0.00u 0.00s 0.58r 9fs sources term%=20 term% try -m sources outside.plan9.bell-labs.com arisawa post... 0.00u 0.01s 1.30r 9fs sources post... 0.00u 0.01s 0.60r 9fs sources post... 0.00u 0.01s 0.55r 9fs sources term%=20 for(i in 1 2 3){ time 9fs $host unmount /n/$host #rm /srv/$host sleep 3 } term% try -m sources outside.plan9.bell-labs.com arisawa post... 0.00u 0.00s 1.25r 9fs sources 0.00u 0.01s 0.18r 9fs sources 0.00u 0.00s 0.19r 9fs sources term%=20 term% try -m sources outside.plan9.bell-labs.com arisawa post... 0.00u 0.00s 1.26r 9fs sources 0.00u 0.00s 0.19r 9fs sources 0.00u 0.01s 0.20r 9fs sources term%=20 the values reported yesterday are: 0.00u 0.00s 3.73r 9fs sources 0.00u 0.00s 0.71r 9fs sources 0.00u 0.00s 0.21r 9fs sources which shows mount latency depends much on the network condition. From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: Date: Thu, 12 May 2016 22:18:46 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <9F0697EE-3061-4DAE-969E-0FFB896B09E2@ar.aichi-u.ac.jp> References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8eea18dc-ead9-11e9-9d60-3106f5b1d025 thanks skip for the information. > 2016/05/12 7:39=E3=80=81Skip Tavakkolian = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A > FYI, from Seattle I see about 8 seconds to establish but as Charles = noted, it's reasonably fast after that. I am glad if you can show me the raw data measured by for(i in 1 2 3){ time cpu -h HOST -k =E2=80=98dom=3DDOM=E2=80=99 -c pwd sleep 3 } thanks in advance. Kenji Arisawa 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: From: Skip Tavakkolian Date: Thu, 12 May 2016 15:40:12 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=94eb2c0628e8e915600532a6f980 Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8eee3156-ead9-11e9-9d60-3106f5b1d025 --94eb2c0628e8e915600532a6f980 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =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 with >> cpu, and setting up, but once there it's fine. >> >> >> --94eb2c0628e8e915600532a6f980 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
it might be worth instrumenting the cpu command to time th= e authenticaiton step. i think that's where the problem is.

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 r= easonably fast after that.


On Wed, May 11, 2016 at 2:05 PM ar= isawa <ari= sawa@ar.aichi-u.ac.jp> wrote:
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.


--94eb2c0628e8e915600532a6f980-- 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-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: Date: Sat, 14 May 2016 22:30:17 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8f17034c-ead9-11e9-9d60-3106f5b1d025 Hello this is a partial report of cpu command latency. we have code below in rexcall() of cpu.c=20 na =3D netmkaddr(host, 0, service); //na =3D netmkaddr(host, =E2=80=9Ctcp=E2=80=9D, service);//DBG syslog(0,"cpu","rexcall:netmkaddr %lld =CE=BCsec; = %s",(nsec()-t0)/1000,na);//DBG procsetname("dialing %s", na); syslog(0,"cpu","rexcall:dialing %lld =CE=BCsec; = %s",(nsec()-t0)/1000,na);//DBG if((*fd =3D dial(na, 0, devdir, 0)) < 0) return "can't dial"; syslog(0,"cpu","rexcall:dial %lld =CE=BCsec",(nsec()-t0)/1000);//D= BG lines with =E2=80=9CDBG=E2=80=9D are code added for measurement. looking the result I found dial() takes as much as on second in my home = network! vbt May 14 21:27:52 rexcall:netmkaddr 122 =CE=BCsec; net!io!ncpu vbt May 14 21:27:52 rexcall:dialing 592 =CE=BCsec; net!io!ncpu vbt May 14 21:27:53 rexcall:dial 1161556 =CE=BCsec vbt May 14 21:27:57 rexcall:netmkaddr 677 =CE=BCsec; net!io!ncpu vbt May 14 21:27:57 rexcall:dialing 1082 =CE=BCsec; net!io!ncpu vbt May 14 21:27:58 rexcall:dial 1109949 =CE=BCsec replacing na =3D netmkaddr(host, 0, service); by na =3D netmkaddr(host, =E2=80=9Ctcp=E2=80=9D, service); we get much better performance as shown below. vbt May 14 22:21:18 rexcall:netmkaddr 489 =CE=BCsec; tcp!io!ncpu vbt May 14 22:21:18 rexcall:dialing 861 =CE=BCsec; tcp!io!ncpu vbt May 14 22:21:18 rexcall:dial 3099 =CE=BCsec vbt May 14 22:21:22 rexcall:netmkaddr 565 =CE=BCsec; tcp!io!ncpu vbt May 14 22:21:22 rexcall:dialing 977 =CE=BCsec; tcp!io!ncpu vbt May 14 22:21:22 rexcall:dial 7287 =CE=BCsec isn=E2=80=99t it better the default net be =E2=80=9Ctcp=E2=80=9D? even if you do want =E2=80=9Cnet=E2=80=9D, you can do cpu -h net!host=20 Kenji Arisawa > 2016/05/13 0:40=E3=80=81Skip Tavakkolian = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > it might be worth instrumenting the cpu command to time the = authenticaiton step. i think that's where the problem is. >=20 > 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. >=20 >=20 > On Wed, May 11, 2016 at 2:05 PM arisawa = wrote: > Hello, >=20 > 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 >=20 > 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. >=20 > Kenji Arisawa >=20 > > In my experience, it's almost unfailingly the DNS that slows down > > establishing an Internet session of any type. > > > > Lucio. >=20 > > 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 = 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. >=20 >=20 From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: arisawa In-Reply-To: Date: Wed, 18 May 2016 16:31:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D68DE52-7413-4B52-8BBF-35EFCE609CB6@gmail.com> <2202C006-B0C9-40AE-B6FC-CA415D41A66A@ar.aichi-u.ac.jp> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] cpu command latency Topicbox-Message-UUID: 8f20140a-ead9-11e9-9d60-3106f5b1d025 Hello, fixing authdial bug I got remarkable result. I measured using mobile wireless network (the bandwidth is a few tens = mega bps). before fixing: 0.00u 0.00s 44.73r cpu -h grid.nyx.link -k = dom=3Doutside.plan9.bell-labs.com ... 0.00u 0.00s 9.35r cpu -h grid.nyx.link -k = dom=3Doutside.plan9.bell-labs.com ... 0.00u 0.01s 9.39r cpu -h grid.nyx.link -k = dom=3Doutside.plan9.bell-labs.com ... after fixing: 0.00u 0.01s 14.59r cpu -h tcp!grid.nyx.link -k dom=3Dluna.nyx.link = ... 0.00u 0.04s 7.65r cpu -h tcp!grid.nyx.link -k dom=3Dluna.nyx.link = ... 0.00u 0.00s 7.51r cpu -h tcp!grid.nyx.link -k dom=3Dluna.nyx.link = ... you need to recompile libauthsrv, factotum and kernel. I am happy if anyone send me data from outside of japan. putting =E2=80=9Ctcp!=E2=80=9D is clumsy. fixing cpu.c is also = desirable. p.s. thanks skip for the suggestion. Kenji Arisawa > 2016/05/14 22:30=E3=80=81arisawa = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >=20 > Hello >=20 > this is a partial report of cpu command latency. >=20 > we have code below in rexcall() of cpu.c=20 >=20 > na =3D netmkaddr(host, 0, service); > //na =3D netmkaddr(host, =E2=80=9Ctcp=E2=80=9D, service);//DBG > syslog(0,"cpu","rexcall:netmkaddr %lld =CE=BCsec; = %s",(nsec()-t0)/1000,na);//DBG > procsetname("dialing %s", na); > syslog(0,"cpu","rexcall:dialing %lld =CE=BCsec; = %s",(nsec()-t0)/1000,na);//DBG > if((*fd =3D dial(na, 0, devdir, 0)) < 0) > return "can't dial"; > syslog(0,"cpu","rexcall:dial %lld =CE=BCsec",(nsec()-t0)/1000);//D= BG >=20 > lines with =E2=80=9CDBG=E2=80=9D are code added for measurement. > looking the result I found dial() takes as much as on second in my = home network! >=20 > vbt May 14 21:27:52 rexcall:netmkaddr 122 =CE=BCsec; net!io!ncpu > vbt May 14 21:27:52 rexcall:dialing 592 =CE=BCsec; net!io!ncpu > vbt May 14 21:27:53 rexcall:dial 1161556 =CE=BCsec >=20 > vbt May 14 21:27:57 rexcall:netmkaddr 677 =CE=BCsec; net!io!ncpu > vbt May 14 21:27:57 rexcall:dialing 1082 =CE=BCsec; net!io!ncpu > vbt May 14 21:27:58 rexcall:dial 1109949 =CE=BCsec >=20 > replacing > na =3D netmkaddr(host, 0, service); > by > na =3D netmkaddr(host, =E2=80=9Ctcp=E2=80=9D, service); > we get much better performance as shown below. > vbt May 14 22:21:18 rexcall:netmkaddr 489 =CE=BCsec; tcp!io!ncpu > vbt May 14 22:21:18 rexcall:dialing 861 =CE=BCsec; tcp!io!ncpu > vbt May 14 22:21:18 rexcall:dial 3099 =CE=BCsec >=20 > vbt May 14 22:21:22 rexcall:netmkaddr 565 =CE=BCsec; tcp!io!ncpu > vbt May 14 22:21:22 rexcall:dialing 977 =CE=BCsec; tcp!io!ncpu > vbt May 14 22:21:22 rexcall:dial 7287 =CE=BCsec >=20 > isn=E2=80=99t it better the default net be =E2=80=9Ctcp=E2=80=9D? > even if you do want =E2=80=9Cnet=E2=80=9D, you can do > cpu -h net!host=20 >=20 > Kenji Arisawa >=20 >=20 >=20 >> 2016/05/13 0:40=E3=80=81Skip Tavakkolian = =E3=81=AE=E3=83=A1=E3=83=BC=E3=83=AB=EF=BC=9A >>=20 >> it might be worth instrumenting the cpu command to time the = authenticaiton step. i think that's where the problem is. >>=20 >> 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. >>=20 >>=20 >> On Wed, May 11, 2016 at 2:05 PM arisawa = wrote: >> Hello, >>=20 >> 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 >>=20 >> 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. >>=20 >> Kenji Arisawa >>=20 >>> In my experience, it's almost unfailingly the DNS that slows down >>> establishing an Internet session of any type. >>>=20 >>> Lucio. >>=20 >>> 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 >>>=20 >>> Well, based on the 9fs test that was posted, I'd think dial is being = awfully slow. >>>=20 >>> Maybe try something simpler? aux/listen1 echo hello and a simple = network connection? >>>=20 >>> Best regards, >>> Kenny Levinsen >>>=20 >>> On 11. maj 2016, at 16.13, Charles Forsyth = wrote: >>>=20 >>>>=20 >>>> On 11 May 2016 at 14:44, Kenny Lasse Hoff Levinsen = 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. >>>>=20 >>>> There's something initially slow in connecting to grid.nyx.link = with cpu, and setting up, but once there it's fine. >>=20 >>=20 >=20 >=20