9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] cpu command latency
@ 2016-05-11  9:04 arisawa
  2016-05-11  9:23 ` Charles Forsyth
       [not found] ` <CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>
  0 siblings, 2 replies; 15+ messages in thread
From: arisawa @ 2016-05-11  9:04 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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. 
unfortunately I don’t 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 ‘dom=DOM’ -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







^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11  9:04 [9fans] cpu command latency arisawa
@ 2016-05-11  9:23 ` Charles Forsyth
       [not found] ` <CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>
  1 sibling, 0 replies; 15+ messages in thread
From: Charles Forsyth @ 2016-05-11  9:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 577 bytes --]

On 11 May 2016 at 10:04, arisawa <arisawa@ar.aichi-u.ac.jp> 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 ‘dom=DOM’ -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.

[-- Attachment #2: Type: text/html, Size: 1005 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
       [not found] ` <CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>
@ 2016-05-11 13:12   ` arisawa
  2016-05-11 13:44     ` Kenny Lasse Hoff Levinsen
  0 siblings, 1 reply; 15+ messages in thread
From: arisawa @ 2016-05-11 13:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 13:12   ` arisawa
@ 2016-05-11 13:44     ` Kenny Lasse Hoff Levinsen
  2016-05-11 14:13       ` Charles Forsyth
  2016-05-12 13:06       ` arisawa
  0 siblings, 2 replies; 15+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-05-11 13:44 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 ultimately calls srv(4) and mount(1) as necessary - if the channel exists, it is simply a call to mount(1), which translates to an attach(5) 9P message on the existing connection.

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.

Best regards,
Kenny Levinsen

> On 11. maj 2016, at 15.12, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
> 
> 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
> 
> 



^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 13:44     ` Kenny Lasse Hoff Levinsen
@ 2016-05-11 14:13       ` Charles Forsyth
  2016-05-11 15:23         ` Kenny Lasse Hoff Levinsen
  2016-05-12 13:06       ` arisawa
  1 sibling, 1 reply; 15+ messages in thread
From: Charles Forsyth @ 2016-05-11 14:13 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 359 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 827 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 14:13       ` Charles Forsyth
@ 2016-05-11 15:23         ` Kenny Lasse Hoff Levinsen
  2016-05-11 15:58           ` lucio
  2016-05-11 21:05           ` arisawa
  0 siblings, 2 replies; 15+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-05-11 15:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

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 <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 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.

[-- Attachment #2: Type: text/html, Size: 1469 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 15:23         ` Kenny Lasse Hoff Levinsen
@ 2016-05-11 15:58           ` lucio
  2016-05-11 21:05           ` arisawa
  1 sibling, 0 replies; 15+ messages in thread
From: lucio @ 2016-05-11 15:58 UTC (permalink / raw)
  To: 9fans

> 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.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 15:23         ` Kenny Lasse Hoff Levinsen
  2016-05-11 15:58           ` lucio
@ 2016-05-11 21:05           ` arisawa
  2016-05-11 22:39             ` Skip Tavakkolian
  1 sibling, 1 reply; 15+ messages in thread
From: arisawa @ 2016-05-11 21:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <kennylevinsen@gmail.com> のメール:
> 
> 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 <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 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.




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 21:05           ` arisawa
@ 2016-05-11 22:39             ` Skip Tavakkolian
  2016-05-12 13:18               ` arisawa
  2016-05-12 15:40               ` Skip Tavakkolian
  0 siblings, 2 replies; 15+ messages in thread
From: Skip Tavakkolian @ 2016-05-11 22:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 1750 bytes --]

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 <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 “-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 <kennylevinsen@gmail.com>
> のメール:
> >
> > 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 <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 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 2392 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 13:44     ` Kenny Lasse Hoff Levinsen
  2016-05-11 14:13       ` Charles Forsyth
@ 2016-05-12 13:06       ` arisawa
  1 sibling, 0 replies; 15+ messages in thread
From: arisawa @ 2016-05-12 13:06 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello,

> 2016/05/11 22:44、Kenny Lasse Hoff Levinsen <kennylevinsen@gmail.com> のメール:
> 
> 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% 

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% 

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% 

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% 

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.





^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 22:39             ` Skip Tavakkolian
@ 2016-05-12 13:18               ` arisawa
  2016-05-12 15:40               ` Skip Tavakkolian
  1 sibling, 0 replies; 15+ messages in thread
From: arisawa @ 2016-05-12 13:18 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

thanks skip for the information.

> 2016/05/12 7:39、Skip Tavakkolian <skip.tavakkolian@gmail.com> のメール:
> 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 ‘dom=DOM’ -c pwd
		sleep 3
	}

thanks in advance.
Kenji Arisawa




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-11 22:39             ` Skip Tavakkolian
  2016-05-12 13:18               ` arisawa
@ 2016-05-12 15:40               ` Skip Tavakkolian
  2016-05-12 16:00                 ` Balaji
  2016-05-14 13:30                 ` arisawa
  1 sibling, 2 replies; 15+ messages in thread
From: Skip Tavakkolian @ 2016-05-12 15:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2020 bytes --]

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 <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 <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 “-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 <kennylevinsen@gmail.com>
>> のメール:
>> >
>> > 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 <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 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.
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 2867 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-12 15:40               ` Skip Tavakkolian
@ 2016-05-12 16:00                 ` Balaji
  2016-05-14 13:30                 ` arisawa
  1 sibling, 0 replies; 15+ messages in thread
From: Balaji @ 2016-05-12 16:00 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 2307 bytes --]

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 authenticaiton
> 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 <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 “-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 <kennylevinsen@gmail.com>
>>> のメール:
>>> >
>>> > 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 <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 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.
>>>
>>>
>>>

[-- Attachment #2: Type: text/html, Size: 3457 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-12 15:40               ` Skip Tavakkolian
  2016-05-12 16:00                 ` Balaji
@ 2016-05-14 13:30                 ` arisawa
  2016-05-18  7:31                   ` arisawa
  1 sibling, 1 reply; 15+ messages in thread
From: arisawa @ 2016-05-14 13:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello

this is a partial report of cpu command latency.

we have code below in rexcall() of cpu.c 

	na = netmkaddr(host, 0, service);
	//na = netmkaddr(host, “tcp”, service);//DBG
	syslog(0,"cpu","rexcall:netmkaddr %lld μsec; %s",(nsec()-t0)/1000,na);//DBG
	procsetname("dialing %s", na);
	syslog(0,"cpu","rexcall:dialing %lld μsec; %s",(nsec()-t0)/1000,na);//DBG
	if((*fd = dial(na, 0, devdir, 0)) < 0)
		return "can't dial";
	syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG

lines with “DBG” 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 μsec; net!io!ncpu
	vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
	vbt May 14 21:27:53 rexcall:dial 1161556 μsec

	vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
	vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
	vbt May 14 21:27:58 rexcall:dial 1109949 μsec

replacing
	na = netmkaddr(host, 0, service);
by
	na = netmkaddr(host, “tcp”, service);
we get much better performance as shown below.
	vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
	vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
	vbt May 14 22:21:18 rexcall:dial 3099 μsec

	vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
	vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
	vbt May 14 22:21:22 rexcall:dial 7287 μsec

isn’t it better the default net be “tcp”?
even if you do want “net”, you can do
	cpu -h net!host 

Kenji Arisawa



> 2016/05/13 0:40、Skip Tavakkolian <skip.tavakkolian@gmail.com> のメール:
> 
> 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 <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 <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 “-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 <kennylevinsen@gmail.com> のメール:
> >
> > 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 <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 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.
> 
> 




^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [9fans] cpu command latency
  2016-05-14 13:30                 ` arisawa
@ 2016-05-18  7:31                   ` arisawa
  0 siblings, 0 replies; 15+ messages in thread
From: arisawa @ 2016-05-18  7:31 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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=outside.plan9.bell-labs.com ...
0.00u 0.00s 9.35r 	 cpu -h grid.nyx.link -k dom=outside.plan9.bell-labs.com ...
0.00u 0.01s 9.39r 	 cpu -h grid.nyx.link -k dom=outside.plan9.bell-labs.com ...

after fixing:
0.00u 0.01s 14.59r 	 cpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.04s 7.65r 	 cpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...
0.00u 0.00s 7.51r 	 cpu -h tcp!grid.nyx.link -k dom=luna.nyx.link ...

you need to recompile libauthsrv, factotum and kernel.
I am happy if anyone send me data from outside of japan.
putting “tcp!” is clumsy. fixing cpu.c is also desirable.

p.s. thanks skip for the suggestion.

Kenji Arisawa

> 2016/05/14 22:30、arisawa <arisawa@ar.aichi-u.ac.jp> のメール:
> 
> Hello
> 
> this is a partial report of cpu command latency.
> 
> we have code below in rexcall() of cpu.c 
> 
> 	na = netmkaddr(host, 0, service);
> 	//na = netmkaddr(host, “tcp”, service);//DBG
> 	syslog(0,"cpu","rexcall:netmkaddr %lld μsec; %s",(nsec()-t0)/1000,na);//DBG
> 	procsetname("dialing %s", na);
> 	syslog(0,"cpu","rexcall:dialing %lld μsec; %s",(nsec()-t0)/1000,na);//DBG
> 	if((*fd = dial(na, 0, devdir, 0)) < 0)
> 		return "can't dial";
> 	syslog(0,"cpu","rexcall:dial %lld μsec",(nsec()-t0)/1000);//DBG
> 
> lines with “DBG” 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 μsec; net!io!ncpu
> 	vbt May 14 21:27:52 rexcall:dialing 592 μsec; net!io!ncpu
> 	vbt May 14 21:27:53 rexcall:dial 1161556 μsec
> 
> 	vbt May 14 21:27:57 rexcall:netmkaddr 677 μsec; net!io!ncpu
> 	vbt May 14 21:27:57 rexcall:dialing 1082 μsec; net!io!ncpu
> 	vbt May 14 21:27:58 rexcall:dial 1109949 μsec
> 
> replacing
> 	na = netmkaddr(host, 0, service);
> by
> 	na = netmkaddr(host, “tcp”, service);
> we get much better performance as shown below.
> 	vbt May 14 22:21:18 rexcall:netmkaddr 489 μsec; tcp!io!ncpu
> 	vbt May 14 22:21:18 rexcall:dialing 861 μsec; tcp!io!ncpu
> 	vbt May 14 22:21:18 rexcall:dial 3099 μsec
> 
> 	vbt May 14 22:21:22 rexcall:netmkaddr 565 μsec; tcp!io!ncpu
> 	vbt May 14 22:21:22 rexcall:dialing 977 μsec; tcp!io!ncpu
> 	vbt May 14 22:21:22 rexcall:dial 7287 μsec
> 
> isn’t it better the default net be “tcp”?
> even if you do want “net”, you can do
> 	cpu -h net!host 
> 
> Kenji Arisawa
> 
> 
> 
>> 2016/05/13 0:40、Skip Tavakkolian <skip.tavakkolian@gmail.com> のメール:
>> 
>> 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 <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 <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 “-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 <kennylevinsen@gmail.com> のメール:
>>> 
>>> 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 <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 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.
>> 
>> 
> 
> 




^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2016-05-18  7:31 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-05-11  9:04 [9fans] cpu command latency arisawa
2016-05-11  9:23 ` Charles Forsyth
     [not found] ` <CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>
2016-05-11 13:12   ` arisawa
2016-05-11 13:44     ` Kenny Lasse Hoff Levinsen
2016-05-11 14:13       ` Charles Forsyth
2016-05-11 15:23         ` Kenny Lasse Hoff Levinsen
2016-05-11 15:58           ` lucio
2016-05-11 21:05           ` arisawa
2016-05-11 22:39             ` Skip Tavakkolian
2016-05-12 13:18               ` arisawa
2016-05-12 15:40               ` Skip Tavakkolian
2016-05-12 16:00                 ` Balaji
2016-05-14 13:30                 ` arisawa
2016-05-18  7:31                   ` arisawa
2016-05-12 13:06       ` arisawa

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).