* [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
[parent not found: <CAFSF3XOQY2rH2fRmFEV2d5vGbc6ONkVpRvKY=dR7AvorqB7aKA@mail.gmail.com>]
* 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 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
* 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
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).