Re: [9fans] Limbo manual

[Jacob Todd]

the programming with limbo book is available online for free is you
know where to look. there haven't been many changes since it was made
afaik, start with that and just read the code.

On Sat, Feb 20, 2016 at 11:14 PM, Roswell Grey  wrote:
> Hello,
>
> it seems that the online documentation for learning limbo is rather
> outdated. Does anyone know where I could get a more updated version to learn
> limbo coding? Thanks!
>
> -R

[9fans] Go: FP in note handler

[Kenny Lasse Hoff Levinsen]

For those interested in the matter, I have opened 
https://github.com/golang/go/issues/14471

I mention potentially reenabling duffcopy by writing some magic note handler 
code that avoid the regular copy and zero optimizations, but I’m not entirely 
sure if that’s a plausible path. If it is, I think it would bring benefit, both 
in the performance gained by duffcopy/duffzero, as well as the chances of this 
happening again. It is, however, slightly annoying to do, as you cannot use 
copy(), make() or even strings or byte array literals, as these will trip 
duffcopy and duffzero. Any comments to my silly idea?

Best regards,
Kenny Levinsen

> On 22 Feb 2016, at 18:16, Richard Miller  wrote:
> 
>> The trace of goexitsall still contain FP register access (XORPS and duffzero 
>> which contains MOVUPS)
> 
> Sorry, in that case I think my patch is not relevant for your issue
> (but it does prevent a deadlock on multiprocessors which you might
> also run into...)
> 

Re: [9fans] rtl8169 gbe slow

[Skip Tavakkolian]

is the local throughput what you expect to get?  if yes, can you enable
tls? i'm wondering if http traffic is being intercepted in some way
(caches).

On Mon, Feb 22, 2016 at 9:13 AM David du Colombier <0in...@gmail.com> wrote:

> I've uploaded a pcap trace for future reference.
>
> http://9legacy.org/download/pcap/kergis_plan9.pcap
>
> --
> David du Colombier
>
>

Re: [9fans] rtl8169 gbe slow

[David du Colombier]

I've uploaded a pcap trace for future reference.

http://9legacy.org/download/pcap/kergis_plan9.pcap

-- 
David du Colombier

Re: [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow)

[lucio]

> I didn't intend to hijack the thread, just pointed out that it is
> indeed not hget or webfs at fault.

This is 9fans, where the inexcusable is par for the course and
perfectly neutral comments are taken as insults.

Honestly, I was the one that took the hi-jack bait and I don't even
feel guilty about it.

Lucio.

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 04:45:12PM +, r...@hemiola.co.uk wrote:
> >Does plan9 under lguest actually use the linux
> >hardware services? Is plan9 under lguest using "its" implementation
> >except for the low level device driving i.e. the ethernet provided
> >by the Linux host?
> 
> Yes. The lguest plan9 instance has a virtio ethernet driver,
> which is a 'wire' to a tap interface on the host. Packets are routed
> at the ip level from the tap to the linux ethernet interface by
> the linux kernel in the usual way. I'm not sure why plan9 is half
> the speed in this situation, but I feel it might be a red herring,
> and that the combination of lguest/plan9 isn't terribly efficient
> at minimising the context switching that happens when packets are sent
> and received.
> 

If I'm not mistaken, on the server log, even under lguest the string is
still "Plan9/hget" so this seems to rule this out. And if the
performance (minus emulation/switching overhead) is better using,
actually, Linux TCP/IP implementation for the real connection, it will
show that this is the Plan9 implementation that has, under some
circumstances (perhaps with the size of the packets sent by some server)
an unfelicity.
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Lucio: Of course I'll make an issue, I only just noticed it and traced it to 
goexitsall. Don't worry. :)

Richard: Thanks, I'll try that. The trace of goexitsall still contain FP 
register access (XORPS and duffzero which contains MOVUPS), but maybe that 
doesn't matter if the race is fixed?

I didn't intend to hijack the thread, just pointed out that it is indeed not 
hget or webfs at fault.

Best regards,
Kenny Levinsen

On 22. feb. 2016, at 17.40, lu...@proxima.alt.za wrote:

>> Fun sidenote: more floating point code in note handlers, this time 
>> duffzero when calling os.Exit. *sigh*.
> 
> Can you please submit it as an issue, so we at least know it's there?
> 
> Lucio.
> 
> 

Re: [9fans] rtl8169 gbe slow

[rod]

>Does plan9 under lguest actually use the linux
>hardware services? Is plan9 under lguest using "its" implementation
>except for the low level device driving i.e. the ethernet provided
>by the Linux host?

Yes. The lguest plan9 instance has a virtio ethernet driver,
which is a 'wire' to a tap interface on the host. Packets are routed
at the ip level from the tap to the linux ethernet interface by
the linux kernel in the usual way. I'm not sure why plan9 is half
the speed in this situation, but I feel it might be a red herring,
and that the combination of lguest/plan9 isn't terribly efficient
at minimising the context switching that happens when packets are sent
and received.

-rod

Re: [9fans] rtl8169 gbe slow

[lucio]

> Fun sidenote: more floating point code in note handlers, this time 
> duffzero when calling os.Exit. *sigh*.

Can you please submit it as an issue, so we at least know it's there?

Lucio.

Re: [9fans] rtl8169 gbe slow

[Kenny Lasse Hoff Levinsen]

Go http client + go http server on a vps (14.2ms ping) show same issues: 182s 
to download 100MB from remote using a 9front VM, 7s local, vs. 30s and 1s for 
the linux host.

So yeah, hget/webfs has nothing to do with it.

Fun sidenote: more floating point code in note handlers, this time duffzero 
when calling os.Exit. *sigh*.

Best regards,
Kenny Levinsen

On 22. feb. 2016, at 16.46, David du Colombier <0in...@gmail.com> wrote:

>> No. Is it possible to change the string for hget?
> 
> You can change the string in /sys/src/cmd/hget.c.
> But this issue is not related to hget, since it doesn't happen when
> using hget on Linux or 9vx.
> 
> It seems related to the Plan 9 TCP stack, or how the network
> infrastructure behaves with it.
> 
> -- 
> David du Colombier
> 

Re: [9fans] rtl8169 gbe slow

[David du Colombier]

> No. Is it possible to change the string for hget?

You can change the string in /sys/src/cmd/hget.c.
But this issue is not related to hget, since it doesn't happen when
using hget on Linux or 9vx.

It seems related to the Plan 9 TCP stack, or how the network
infrastructure behaves with it.

-- 
David du Colombier

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Mon Feb 22 07:29:56 PST 2016, tlaro...@polynum.com wrote:
> On Mon, Feb 22, 2016 at 10:21:02AM -0500, stanley lieber wrote:
> > Have you tried setting and alternate user agent?
> > 
> 
> No. Is it possible to change the string for hget?

that's been ruled out, i think, by david.

- erik

Re: [9fans] rtl8169 gbe slow

[lucio]

> But I'm out of my depth: I'm not a TCP/IP expert.

I thought I was, but that was a long time ago.  But what you are
looking for might not be difficult to identity.  Probably traffic
holding up for reasons only snooping the link can reveal.

I hate that type of stuff!

Lucio.

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

On Mon Feb 22 05:41:31 PST 2016, 0in...@gmail.com wrote:
> This issue seems more related to Plan 9 than hget.
> 
> On Linux :
> 
> $ time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> real0m1.783s
> user0m0.037s
> sys 0m0.046s
> 
> On 9vx:
> 
> % time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> couldn't set mtime: permission denied
> 0.00u 0.00s 1.93r hget -o /dev/null
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> On Plan 9:
> 
> % time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> couldn't set mtime: permission denied
> 0.02u 0.01s 37.95r hget -o /dev/null
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 

i noticed this message:

tcp: trim: !inwind: seq 3582371632-3582373071 win 3582374512-3582440046 l 1440 
from 213.186.33.4

i'll need to do a detailed analysis of this to figure out what's going on here.
this could be something that tcpdump, or snoopy could make kind of obvious.

- erik

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 05:19:04PM +0200, lu...@proxima.alt.za wrote:
> > I have hence to ask the provider if there is something,
> > in their configuration, that could explain this
> 
> If you can run NetBSD at the same time as Plan 9, you could also use
> tcpdump (whatever its current impersonation) to monitor the link.
> It's been a long time since I last did that, but it may be revealing.
> 

I will have to snoopy and tcpdump as a last resort to try to have a clue.
Just looking at the numbers, it's like Plan9 only assembling packets in
order (1500 bytes every latency time), and reasking for packet n+1 after
receiving packet n, whatever packets being received in the mean time.
But I'm out of my depth: I'm not a TCP/IP expert.
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[stanley lieber]

Have you tried setting and alternate user agent?

sl

Re: [9fans] rtl8169 gbe slow

[lucio]

> I have hence to ask the provider if there is something,
> in their configuration, that could explain this

If you can run NetBSD at the same time as Plan 9, you could also use
tcpdump (whatever its current impersonation) to monitor the link.
It's been a long time since I last did that, but it may be revealing.

Lucio.

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 02:39:20PM +, r...@hemiola.co.uk wrote:
> I get quite consistent results here.
> 
> Downloading http://downloads.kergis.com/kertex/kertex_bundle.tar to /dev/null:
> 
> linux over rtl8169 & ASDL  :  5.4 seconds
> plan 9 native over rtl8169 & ASDL  : 12.4 seconds
> as above, but latest sources tcp.c : 12.4 seconds
> 
> linux on server:  1.2 seconds
> plan9 in lguest on the same server :  2.2 seconds
> 
> Oldish labs kernels in both cases.
> 

The interesting data is the difference between plan9 native and
plan9 under lguest. Does plan9 under lguest actually use the linux
hardware services? Is plan9 under lguest using "its" implementation
except for the low level device driving i.e. the ethernet provided
by the Linux host?

-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 05:20:40AM -0800, erik quanstrom wrote:
> why?  what's the evidence?
> 

If I download from vanilla Plan9 (running on bare metal) data from 
_another http server_, I have correct results.

So the problem is not with Plan9 per se, but downloading from _this_
site (and it is mine!) and under Plan9.

If there was a problem with Plan9, I will have bad speed from whatever
server under Plan9. But it is not the case.

So there is something at the intersection (&&) of Plan9 and this site. 
And it can be Plan9 identifier (client ID) triggering something on
the server side leading to throttling the connection (or my DSL provider
throttling to the server provider; but this doesn't explain why others
have also poor results connecting from Plan9 while I guess they are not
with the same DSL provider as me---SFR here---and this doesn't explain
why with the same connection, downloading under NetBSD doesn't show the
problem---unless, once more, "plan9/hget" is considered a bittorrent
client or a robot and is causing the throttling, but this would seem a
"general" rule then).

Yes, it could be something with Plan9 at some upper IP level. But before
searching the needle in the hay stack, I have to rule out a possible
throttling on the server side (that I don't own or manage; I only
lend room on it; I have hence to ask the provider if there is something,
in their configuration, that could explain this).
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[David du Colombier]

This issue seems more related to Plan 9 than hget.

On Linux :

$ time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar

real0m1.783s
user0m0.037s
sys 0m0.046s

On 9vx:

% time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
couldn't set mtime: permission denied
0.00u 0.00s 1.93r hget -o /dev/null
http://downloads.kergis.com/kertex/kertex_bundle.tar

On Plan 9:

% time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
couldn't set mtime: permission denied
0.02u 0.01s 37.95r hget -o /dev/null
http://downloads.kergis.com/kertex/kertex_bundle.tar

-- 
David du Colombier

Re: [9fans] rtl8169 gbe slow

[lucio]

> FWIW, I have sent a request to my provider asking if Plan9/hget could
> trigger a "robot" rule leading to the throttling of the connection.

It's unlikely, still QoS may be a factor.  But different results here
in South Africa (1300 km apart, granted) suggest otherwise.  More load
related, is my gut feel.  The host or the network.

Still, you did get consistent results on your side, didn't you.  That
was the original complaint, one slow host (adapter).

Lucio.

Re: [9fans] rtl8169 gbe slow

[erik quanstrom]

why?  what's the evidence?

- erik


On Feb 22, 2016 5:02 AM, tlaro...@polynum.com wrote:
>
> On Mon, Feb 22, 2016 at 01:52:48PM +0100, Mark van Atten wrote: 
> > Same 9front under virtualbox: 
> > 
> > term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip 
> > 0.06u 0.24s 8.74r hget -o /dev/null 
> > http://mirrors.ctan.org/macros/latex/base.zip 
>
> Yes, this is the problem. It is this very address: kergis.com that is 
> causing a problem. The question is: is it because of something in the 
> Plan9 implementation; or is it a different behavior from the http server 
> depending on the OS/utility advertised? I suspect more the latter. 
> -- 
>     Thierry Laronde  
>  http://www.kergis.com/ 
>  http://www.arts-po.fr/ 
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>
>

Re: [9fans] rtl8169 gbe slow

[tlaronde]

FWIW, I have sent a request to my provider asking if Plan9/hget could
trigger a "robot" rule leading to the throttling of the connection.

-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 01:52:48PM +0100, Mark van Atten wrote:
> Same 9front under virtualbox:
> 
> term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip
> 0.06u 0.24s 8.74r  hget -o /dev/null
> http://mirrors.ctan.org/macros/latex/base.zip

Yes, this is the problem. It is this very address: kergis.com that is
causing a problem. The question is: is it because of something in the
Plan9 implementation; or is it a different behavior from the http server
depending on the OS/utility advertised? I suspect more the latter.
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

Same 9front under virtualbox:

term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip
0.06u 0.24s 8.74rhget -o /dev/null
http://mirrors.ctan.org/macros/latex/base.zip

Mark.


On 2/22/16, tlaro...@polynum.com  wrote:
> On Mon, Feb 22, 2016 at 12:17:30PM +, Richard Miller wrote:
>> > It seems that Plan9 is not at fault per se
>>
>> I think it probably is.  Here's another data point (same ADSL connection)
>> -
>
> The delicate point is: is plan9 at fault or it is the fact that it is
> advertised as Plan9 that is the source of this throttling down.
>
> Because I have tested retrieving a 10MB file from another server, under
> plan9 (http://mirrors.ctan.org/macros/latex/base.zip) and I have good
> results on par with what I have under NetBSD (same node; dualboot).
>
> So I think the ethernet layer (the rtl8169) is not at fault. Perhaps
> another IP layer is at fault (bad negociation under some circonstances
> leading to very small packets). Or the server is throttling down
> the connection, whether explicitely because it is Plan9/hget (used
> by some? as bittorrent utility, or the string used etc.) or simply
> because there is a rule that everything not recognized/authorized
> (ie, chrome, mozilla, wget, ftp, lftp) is considered a robot, and
> is throttled down...
>
>>
>> #l0: i82579: 1Gbps port 0xFE50 irq 10: 386077f0e800
>> 0.09u 0.08s 182.26r   hget
>> http://downloads.kergis.com/kertex/kertex_bundle.tar
>>
>> But on the same machine, using linux instead:
>>
>> $ time wget -o /dev/null
>> http://downloads.kergis.com/kertex/kertex_bundle.tar
>>
>> real 0m9.134s
>> user 0m0.048s
>> sys  0m0.186s
>>
>
> --
> Thierry Laronde 
>  http://www.kergis.com/
>  http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
>

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 12:17:30PM +, Richard Miller wrote:
> > It seems that Plan9 is not at fault per se
> 
> I think it probably is.  Here's another data point (same ADSL connection) -

The delicate point is: is plan9 at fault or it is the fact that it is
advertised as Plan9 that is the source of this throttling down.

Because I have tested retrieving a 10MB file from another server, under
plan9 (http://mirrors.ctan.org/macros/latex/base.zip) and I have good
results on par with what I have under NetBSD (same node; dualboot).

So I think the ethernet layer (the rtl8169) is not at fault. Perhaps 
another IP layer is at fault (bad negociation under some circonstances
leading to very small packets). Or the server is throttling down
the connection, whether explicitely because it is Plan9/hget (used
by some? as bittorrent utility, or the string used etc.) or simply
because there is a rule that everything not recognized/authorized
(ie, chrome, mozilla, wget, ftp, lftp) is considered a robot, and
is throttled down...

> 
> #l0: i82579: 1Gbps port 0xFE50 irq 10: 386077f0e800
> 0.09u 0.08s 182.26rhget 
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> But on the same machine, using linux instead:
> 
> $ time wget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> real  0m9.134s
> user  0m0.048s
> sys   0m0.186s
> 

-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

I observe the same on Debian 8.3 64 bit (the machine on which I run
9front in a virtualbox, giving the result I reported earlier today):

; time wget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
0.16u 0.57s 8.39r wget -o /dev/null
http://downloads.kergis.com/kertex/kertex_bundle.tar

Mark.

Re: [9fans] rtl8169 gbe slow

[Richard Miller]

> It seems that Plan9 is not at fault per se

I think it probably is.  Here's another data point (same ADSL connection) -

#l0: i82579: 1Gbps port 0xFE50 irq 10: 386077f0e800
0.09u 0.08s 182.26r  hget 
http://downloads.kergis.com/kertex/kertex_bundle.tar

But on the same machine, using linux instead:

$ time wget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar

real0m9.134s
user0m0.048s
sys 0m0.186s

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 02:00:53PM +0200, lu...@proxima.alt.za wrote:
> > It seems that Plan9 is not at fault per se, but the server I'm on has
> > not a tremendous throughput, and since it is shared, varies greatly.
> 
> It could be traffic related in a lot of ways.  Or load related.  Might
> be worth speaking to the service provider to see if they are aware of
> the wild swings?

Yes, I will contact them too!
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[lucio]

> It seems that Plan9 is not at fault per se, but the server I'm on has
> not a tremendous throughput, and since it is shared, varies greatly.

It could be traffic related in a lot of ways.  Or load related.  Might
be worth speaking to the service provider to see if they are aware of
the wild swings?

Lucio.

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 11:06:47AM +, Richard Miller wrote:
> > If someone under Plan9 could try to download with hget(1):
> 
> >From home (ADSL connection) - standard distribution on x86:
> 
> 0.15u 0.16s 183.90rhget 
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> #l0: rtl8169: 1Gbps port 0xDE00 irq 10: 003018a47956
> 

Same configuration for me. Twice the speed but not tremendous...

> >From server room somewhere in Amsterdam - standard distribution on raspberry 
> >pi B+:
> 
> 1.02u 0.86s 87.53r hget 
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 

It seems that Plan9 is not at fault per se, but the server I'm on has
not a tremendous throughput, and since it is shared, varies greatly.

I will try to see if I can get a pattern by comparing the Plan9
connection with the NetBSD one (same amd64, dualboot).

Thanks to all for the data!

-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[Richard Miller]

> If someone under Plan9 could try to download with hget(1):

>From home (ADSL connection) - standard distribution on x86:

0.15u 0.16s 183.90r  hget 
http://downloads.kergis.com/kertex/kertex_bundle.tar
#l0: rtl8169: 1Gbps port 0xDE00 irq 10: 003018a47956

>From server room somewhere in Amsterdam - standard distribution on raspberry 
>pi B+:

1.02u 0.86s 87.53r   hget 
http://downloads.kergis.com/kertex/kertex_bundle.tar

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 12:15:41PM +0200, lu...@proxima.alt.za wrote:
> > 0.10u 0.22s 192.79r   hget -o kertex_bundle.tar
> > http://downloads.kergis.com/kertex/kertex_bundle.tar
> > 
> > This is under 9front under virtualbox 4.3.32.
> 
> I get, from my workstation:
> 
> 0.21u 1.34s 50.52r hget -o /tmp/kertex_bundle.tar 
> http://downloads.kergis.com/kertex/kertex_bundle.tar

Thank you. Is it plain plan9 in this case?

> 
> and
> 
> term% md5sum /tmp/kertex_bundle.tar
> fbf91d2c9fed66604d14c70e4ab84f5a  /tmp/kertex_bundle.tar
> 
> >From my Cape Town server: 
> 
> 0.26u 2.67s 714.38rhget -o /tmp/kertex_bundle.tar 
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> More like what you get, isn't it? Same file:

Yes, on par with what I get. But I'm not under emulation: it's plain
Plan9 on bare metal in my case...


> This one is a VMware ESXi instance with IP address 192.96.32.148 (or
> somesuch).

Thanks for the data.

So with what Mark van Atten and you have, the problem is not local (to
my workstation) and this is why I'd like to now the difference between
the VMware instance and the first with more correct download times. If
it is plain plan9 (not hosted), I'm a bit puzzled...
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[lucio]

> 0.10u 0.22s 192.79r   hget -o kertex_bundle.tar
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> This is under 9front under virtualbox 4.3.32.

I get, from my workstation:

0.21u 1.34s 50.52r   hget -o /tmp/kertex_bundle.tar 
http://downloads.kergis.com/kertex/kertex_bundle.tar

and

term% md5sum /tmp/kertex_bundle.tar
fbf91d2c9fed66604d14c70e4ab84f5a/tmp/kertex_bundle.tar

>From my Cape Town server: 

0.26u 2.67s 714.38r  hget -o /tmp/kertex_bundle.tar 
http://downloads.kergis.com/kertex/kertex_bundle.tar

More like what you get, isn't it? Same file:

fumble# md5sum /tmp/kertex_bundle.tar
fbf91d2c9fed66604d14c70e4ab84f5a/tmp/kertex_bundle.tar

This one is a VMware ESXi instance with IP address 192.96.32.148 (or
somesuch).

Lucio.

Re: [9fans] rtl8169 gbe slow

[tlaronde]

On Mon, Feb 22, 2016 at 10:40:18AM +0100, Mark van Atten wrote:
> Dear Thierry,
> 
> > If someone under Plan9 could try to download with hget(1):
> >
> > http://downloads.kergis.com/kertex/kertex_bundle.tar
> >
> > and give me the time (it is a 10MB file) to do so,
> 
> 0.10u 0.22s 192.79r   hget -o kertex_bundle.tar
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> 
> This is under 9front under virtualbox 4.3.32.

Thank you. It's better than what I get, but it is still poor: ~53KB/s...
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C

Re: [9fans] rtl8169 gbe slow

[Mark van Atten]

Dear Thierry,

> If someone under Plan9 could try to download with hget(1):
>
> http://downloads.kergis.com/kertex/kertex_bundle.tar
>
> and give me the time (it is a 10MB file) to do so,

0.10u 0.22s 192.79r   hget -o kertex_bundle.tar
http://downloads.kergis.com/kertex/kertex_bundle.tar

This is under 9front under virtualbox 4.3.32.

Mark.

Re: [9fans] plan9port for El Capitan(10.11.3)

[kokamoto]

> That's also quite old. There's one called drawterm-elcapitan, take that or 
> compile from the master branch.

My problem caused by the fact I launched the drawterm from Application directory
by GUI, where I replaced the drawterm binary in 
/Applications/darwterm/Contents/MacOS
by the one I compiled from your source.

When I launch the drawterm-cocoa from terminal, it works very fine.

Kenji

Re: [9fans] rtl8169 gbe slow

[tlaronde]

Actually, the sources are up-to-date.

Setting "tcp" for /net/log doesn't produce any message.

Since the problem is with one address (http://downloads.kergis.com/),
I will have to snoopy the interface to have a clue about what is going
on (is the negociation leading to this poor performance? Are the packets
arriving sparsely, meaning that the problem is "before" with the gateway
or the external server? Is "Plan9/hget" considered a bittorrent
application and the external server throttling down on purpose?).

If someone under Plan9 could try to download with hget(1):

http://downloads.kergis.com/kertex/kertex_bundle.tar

and give me the time (it is a 10MB file) to do so, I will have a clue
about whether there is something "generally" going on on the server 
with Plan9 or hget, or if the problem is local to my installation.

TIA
-- 
Thierry Laronde 
 http://www.kergis.com/
 http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C