Re: [9fans] rtl8169 gbe slow

On Tue, Feb 23, 2016 at 08:35:04PM +0100, hiro wrote: > downloads.kergis.com is some http server operated by OVH. > > it would be easier to post a pcap from a transfer where you control > both sides and possibly enable debugging of window sizes, timeouts, > packet loss, etc. in tcp.c like erik

Re: [9fans] rtl8169 gbe slow

downloads.kergis.com is some http server operated by OVH. it would be easier to post a pcap from a transfer where you control both sides and possibly enable debugging of window sizes, timeouts, packet loss, etc. in tcp.c like erik did. On 2/23/16, erik quanstrom wrote: >

Re: [9fans] rtl8169 gbe slow

I saw this. I'm not looking at the pcap file On Feb 23, 2016 10:38 AM, hiro <23h...@gmail.com> wrote: > > i didn't see any out-of-window rx in the pcap. did i look the wrong way? > >

Re: [9fans] rtl8169 gbe slow

i didn't see any out-of-window rx in the pcap. did i look the wrong way?

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 09:52:28 PST 2016, 23h...@gmail.com wrote: > which machine is in the west coast? the one your tracing on? is that > hget or a web server on plan9? is this the same test as posted by > david? > > where do you see out-of-window rxes? what does that even mean? this is from the same

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 09:55:58 PST 2016, kennylevin...@gmail.com wrote: > Just in case you want a another point of reference to eliminate weirdness > with the specific box: http://de.kl.wtf/f/10mburandom > > Linode Arch Linux box in Frankfurt, serving you with a pretty standard usage > of Go’s http

Re: [9fans] rtl8169 gbe slow

Just in case you want a another point of reference to eliminate weirdness with the specific box: http://de.kl.wtf/f/10mburandom Linode Arch Linux box in Frankfurt, serving you with a pretty standard usage of Go’s http server. Should count as a “stock linux box with a non-weird HTTP server”.

Re: [9fans] rtl8169 gbe slow

no, i don't see any routing info in your output. On 2/23/16, lu...@proxima.alt.za wrote: >> i don't get how this pcap got produced. perhaps >> wireshark is also interpreting it wrong, or timestamps are broken... > > I wonder if there isn't some route flapping involved here.

Re: [9fans] rtl8169 gbe slow

which machine is in the west coast? the one your tracing on? is that hget or a web server on plan9? is this the same test as posted by david? where do you see out-of-window rxes? what does that even mean? On 2/23/16, erik quanstrom wrote: > On Tue Feb 23 09:25:53 PST

Re: [9fans] rtl8169 gbe slow

> i don't get how this pcap got produced. perhaps > wireshark is also interpreting it wrong, or timestamps are broken... I wonder if there isn't some route flapping involved here. Is it possible that the hop count is not stable? Or the link gets saturated? Lucio.

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 09:25:53 PST 2016, 23h...@gmail.com wrote: > in the long run the rwin seems much higher (65535) than the number of > bytes in flight (less than 3x1500 bytes). > > i just noticed that the minimum latency numbers seem way low. many > latency samples appear at around 40ms and 100ms, but

Re: [9fans] rtl8169 gbe slow

> 26/status:Established qin 0 qout 0 rq 0.0 srtt 1256 mdev 628 sst 65535 cwin > 4517 swin 5808>>0 rwin 65535>>4 qscale 0 timer.start 10 timer.count 10 > rerecv 0 katimer.start 2400 katimer.count 2400 where did you run this?

Re: [9fans] rtl8169 gbe slow

in the long run the rwin seems much higher (65535) than the number of bytes in flight (less than 3x1500 bytes). i just noticed that the minimum latency numbers seem way low. many latency samples appear at around 40ms and 100ms, but there's also outliers? below 1ms. i don't get how this pcap got

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 04:49:55 PST 2016, 23h...@gmail.com wrote: > i just realized the http *response* packets all have their rwin set to > 5808 only, while the other side has the former described behavior > hovering around 65535. > perhaps the http server does no window scaling?! 26/status:Established

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 04:32:50 PST 2016, 23h...@gmail.com wrote: > erik: I don't think nowadays we need to limit rwin unless we > artificially want to reduce the bandwidth (e.g. in my torrent program, > or an rsync that's running in the background and shouldn't use up the > whole bandwidth of the slow DSL

Re: [9fans] rtl8169 gbe slow

On Tue Feb 23 04:39:42 PST 2016, 23h...@gmail.com wrote: > in any case we seem limited by congestion window, not rwin. can you explain? - erik

Re: [9fans] rtl8169 gbe slow

and obviously a blocking pipe would be a good reason to reduce rwin. the other keyword used often is "flow control". redirecting hget output into /dev/null should be fast enough though, so again, this doesn't matter in our case.

Re: [9fans] rtl8169 gbe slow

in any case we seem limited by congestion window, not rwin.

Re: [9fans] rtl8169 gbe slow

Can you please tell more about your setup here? Is this capture taken only on the client? in a seq number graph you can see that (disregarding the beginning where it obviously first has to catch up some speed) until 5.73s the throughput is quite ok, but then suddenly goes down to approximately

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

>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

Re: [9fans] rtl8169 gbe slow

> 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

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

> 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

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

Have you tried setting and alternate user agent? sl

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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:

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

> 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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

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

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 08:41:01PM +0100, Mark van Atten wrote: > > i think that david has a mirror up, and 9fs sources still works here. > > http://9p.io/ Thanks, Mark! -- Thierry Laronde http://www.kergis.com/ http://www.arts-po.fr/ Key

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 11:26:58AM -0800, erik quanstrom wrote: > > > anyway, please update your tcp. the debugging tools that are most > > > helpful with tcp are > > > /net/tcp/stats > > > /net/tcp/*/status > > > echo tcp>/net/log && tail -f /net/log > > > > To update I need to update the

Re: [9fans] rtl8169 gbe slow

> i think that david has a mirror up, and 9fs sources still works here. http://9p.io/ Mark.

Re: [9fans] rtl8169 gbe slow

> > anyway, please update your tcp. the debugging tools that are most > > helpful with tcp are > > /net/tcp/stats > > /net/tcp/*/status > > echo tcp>/net/log && tail -f /net/log > > To update I need to update the sources. Where are now the "updated" > sources? since Bell Labs site seems to be

Re: [9fans] rtl8169 gbe slow

> > anyway, please update your tcp. the debugging tools that are most > > helpful with tcp are > > /net/tcp/stats > > /net/tcp/*/status > > echo tcp>/net/log && tail -f /net/log > > We have definitively not the same systems ;-) The echo tcp brings an > error for netlog. sorry, it's "echo tcp

Re: [9fans] rtl8169 gbe slow

> anyway, please update your tcp. the debugging tools that are most > helpful with tcp are > /net/tcp/stats > /net/tcp/*/status > echo tcp>/net/log && tail -f /net/log We have definitively not the same systems ;-) The echo tcp brings an error for netlog. But for further puzzling things (for

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 09:20:52AM -0800, erik quanstrom wrote: > On Sat Feb 20 06:04:02 PST 2016, tlaro...@polynum.com wrote: > > On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote: > > > what is the latency on WAN? > > > > When using traceroute, I have 42.6ms for a roundtrip > > (cf. with

Re: [9fans] rtl8169 gbe slow

On Sat Feb 20 06:04:02 PST 2016, tlaro...@polynum.com wrote: > On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote: > > what is the latency on WAN? > > When using traceroute, I have 42.6ms for a roundtrip > (cf. with LAN: 0.23ms). > > But the very same machine, under NetBSD, with the very same

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 04:06:24PM +0200, lu...@proxima.alt.za wrote: > > But the very same machine, under NetBSD, with the very same ip address, > > downloads the very same file from the very same external server > > (downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing > > it. > >

Re: [9fans] rtl8169 gbe slow

> But the very same machine, under NetBSD, with the very same ip address, > downloads the very same file from the very same external server > (downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing > it. Just for one more data point: dump the hget output to /dev/null. That may at

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote: > what is the latency on WAN? When using traceroute, I have 42.6ms for a roundtrip (cf. with LAN: 0.23ms). But the very same machine, under NetBSD, with the very same ip address, downloads the very same file from the very same external

Re: [9fans] rtl8169 gbe slow

what is the latency on WAN?

Re: [9fans] rtl8169 gbe slow

On Sat, Feb 20, 2016 at 12:23:29PM +0100, Kenny Lasse Hoff Levinsen wrote: >> [rtl8169 gbe full speed on LAN; very slow on WAN] > Is your MTU higher that 1500? That might be able to mess things up over the > internet. > Thanks for the suggestion but no: even with -m 1500, speed is still awful.

Re: [9fans] rtl8169 gbe slow

Is your MTU higher that 1500? That might be able to mess things up over the internet. Best regards, Kenny Levinsen > On 20. feb. 2016, at 11.32, tlaro...@polynum.com wrote: > > I have compared downloading a file (via ftpfs) on the LAN, and > downloading it from the WAN. > > On the LAN, I get

Re: [9fans] rtl8169 gbe slow

I have compared downloading a file (via ftpfs) on the LAN, and downloading it from the WAN. On the LAN, I get the 10MB file in less than a 1s (this is normal since the node I download from has only a 100Mb ethernet). On the WAN, it takes 6 minutes (with hget). My conclusion is that the card

Re: [9fans] rtl8169 gbe slow

> Is /dev/irqstat a lapsus? Here are /dev/irqalloc and > /net/ether0/ifstats: [...] > 42 10 ether0 well, boo. the labs version doesn't give enough information. i was expecting something like ; grep ether0 /dev/irqalloc 65.0 11 17224065

Re: [9fans] rtl8169 gbe slow

On Thu, Feb 18, 2016 at 05:22:42AM -0800, erik quanstrom wrote: > the 8169 driver is pretty fast. I've measured it at more than 500mbps. > it sounds like something else is misbehaving. what does > /dev/irqstat say. I bet something is stuck. > Is /dev/irqstat a lapsus? Here are /dev/irqalloc

Re: [9fans] rtl8169 gbe slow

the standard labs driver checks the speed during auto negotiation. so it is often wrong. - erik On Feb 18, 2016 3:41 PM, arisawa wrote: > > hello, > > rtl8169 is popular in cheap MB, so it is installed in my many MBs. > however, cat /dev/kmesg claims: > rtl8169:

Re: [9fans] rtl8169 gbe slow

hello, rtl8169 is popular in cheap MB, so it is installed in my many MBs. however, cat /dev/kmesg claims: rtl8169: oui 0x732 phyno 1, macv = 0x3c00 phyv = 0x0002 #l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891 the “100Mbps" in the message is correct or not? I also feel rtl8169 is

Re: [9fans] rtl8169 gbe slow

the 8169 driver is pretty fast. I've measured it at more than 500mbps. it sounds like something else is misbehaving. what does /dev/irqstat say. I bet something is stuck. - erik On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote: > > Hello, > > I have finally managed to install plan9 on my