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.35rcpu -h grid.nyx.link -k
dom=outside.
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
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.tavakkol...@gmail.com> wrote:
> it might be worth instrumenting the cpu command to time the authenticaiton
> step.
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,
thanks skip for the information.
> 2016/05/12 7:39、Skip Tavakkolian のメール：
> 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 HO
Hello,
> 2016/05/11 22:44、Kenny Lasse Hoff Levinsen のメール：
>
> 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
#unmoun
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
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
> 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.
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 Lass
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,
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 m
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.73r9fs sources
0.00u 0.00s 0.71r9fs sources
0.00u 0.00s 0.21r9fs sources
with the script below:
for(i in 1 2 3){
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 ‘dom=DOM’ -c pwd
> sleep 3
> }
> they are c
>
It takes ages to get throu
14 matches
Mail list logo
