9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: arisawa <arisawa@ar.aichi-u.ac.jp>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] cpu command latency
Date: Wed, 18 May 2016 16:31:16 +0900	[thread overview]
Message-ID: <B05201CE-8098-40E3-AA29-8853FF53F1DD@ar.aichi-u.ac.jp> (raw)
In-Reply-To: <EDA02E24-32C5-4E82-B0C6-594CBAAFDECE@ar.aichi-u.ac.jp>

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




  reply	other threads:[~2016-05-18  7:31 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-11  9:04 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 [this message]
2016-05-12 13:06       ` arisawa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=B05201CE-8098-40E3-AA29-8853FF53F1DD@ar.aichi-u.ac.jp \
    --to=arisawa@ar.aichi-u.ac.jp \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).