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] Go: FP in note handler

> On 23 Feb 2016, at 18:31, lu...@proxima.alt.za wrote: > >> A proper duffcopy/duffzero/memmove is also an option. > > The adjective "proper" is revealing. I vote for that. > > Lucio. > > It’s a bit out of my usual area of expertise, however. I have no idea what benchmark they have been

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] Go: FP in note handler

> A proper duffcopy/duffzero/memmove is also an option. The adjective "proper" is revealing. I vote for that. Lucio.

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] Go: FP in note handler

A proper duffcopy/duffzero/memmove is also an option. Best regards, Kenny Levinsen > On 23. feb. 2016, at 18.02, erik quanstrom wrote: > >> On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote: >> A benchmark was supposedly made of the new duffcopy/duffzero

Re: [9fans] Go: FP in note handler

On Tue Feb 23 07:55:26 PST 2016, kennylevin...@gmail.com wrote: > A benchmark was supposedly made of the new duffcopy/duffzero which claimed > significant speedup for larger copies: > https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da > > I have no clue whether this

Re: [9fans] Go: FP in note handler

A benchmark was supposedly made of the new duffcopy/duffzero which claimed significant speedup for larger copies: https://github.com/golang/go/commit/5cf281a9b791f0f10efd1574934cbb19ea1b33da I have no clue whether this holds true or not. My intention to reenable duffcopy and continue to use

Re: [9fans] Go: FP in note handler

On Tue Feb 23 02:36:41 PST 2016, kennylevin...@gmail.com wrote: > Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 > specific runtime.sighandler implementation and everything called by it > directly. Notes that don't exit the process are queued and should run outside >

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] Go: FP in note handler

Ah, no - it is not a system-wide adjustment, but adjustment of the plan9 specific runtime.sighandler implementation and everything called by it directly. Notes that don't exit the process are queued and should run outside the actual note handler. I think the "magic" code will be isolated, and

Re: [9fans] Go: FP in note handler

Well, avoiding XMM registers in duffcopy/duffzero is one solution, but I was thinking of working around them entirely in code called from the note handler, so that duffcopy/duffzero can operate as intended on plan9, rather than littering the compiler with OS conditionals. It puts some