9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] rtl8169 gbe slow
@ 2016-02-18 11:30 tlaronde
  2016-02-18 13:22 ` erik quanstrom
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-18 11:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Hello,

I have finally managed to install plan9 on my new workstation.

By putting back the keyboard on the PS2 connector, I have solved some
unfelicities (with the USB->legacy emulation, the keyboard switched
every other typing to UPPERCASE...).

The mouse, still USB connected and hence "emulated" by the BIOS,
does not react very gracefully but I will see if I can play with
the acceleration and the resolution to have a better terminal. (Or
if I manage to find a long enough cable to have a COM slot back since
there is the bare connector on the motherboard; in this case I will go
back to a com mouse and will be able to probe USB for other
devices---external disks.)

One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but
when testing the compilation of kerTeX (it has been fixed: it works for
the last release; rio to come for METAFONT), the throughput with hget is
abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have
plenty of RAM and the blocks cache for fossil is set to 3000---it could
be obviously higher).

Setting the mtu to jumbo packet does not help.

Is there something to tune or is it simply that the chip is not well
supported?

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-18 11:30 [9fans] rtl8169 gbe slow tlaronde
@ 2016-02-18 13:22 ` erik quanstrom
  2016-02-18 23:41   ` arisawa
  2016-02-19 12:52   ` tlaronde
  0 siblings, 2 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-18 13:22 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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, tlaronde@polynum.com wrote:
>
> Hello, 
>
> I have finally managed to install plan9 on my new workstation. 
>
> By putting back the keyboard on the PS2 connector, I have solved some 
> unfelicities (with the USB->legacy emulation, the keyboard switched 
> every other typing to UPPERCASE...). 
>
> The mouse, still USB connected and hence "emulated" by the BIOS, 
> does not react very gracefully but I will see if I can play with 
> the acceleration and the resolution to have a better terminal. (Or 
> if I manage to find a long enough cable to have a COM slot back since 
> there is the bare connector on the motherboard; in this case I will go 
> back to a com mouse and will be able to probe USB for other 
> devices---external disks.) 
>
> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
> when testing the compilation of kerTeX (it has been fixed: it works for 
> the last release; rio to come for METAFONT), the throughput with hget is 
> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
> be obviously higher). 
>
> Setting the mtu to jumbo packet does not help. 
>
> Is there something to tune or is it simply that the chip is not well 
> supported? 
>
> TIA 
> -- 
>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com> 
>                      http://www.kergis.com/ 
>                      http://www.arts-po.fr/ 
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>
>

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-18 13:22 ` erik quanstrom
@ 2016-02-18 23:41   ` arisawa
  2016-02-19  1:56     ` erik quanstrom
  2016-02-19 15:17     ` erik quanstrom
  2016-02-19 12:52   ` tlaronde
  1 sibling, 2 replies; 83+ messages in thread
From: arisawa @ 2016-02-18 23:41 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 = 0x3c000000 phyv = 0x0002
#l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891

the “100Mbps" in the message is correct or not?

I also feel rtl8169 is slow, so I replace on-board rtl8169 by intel’s card  if possible.



> 2016/02/18 22:22、erik quanstrom <quanstro@quanstro.net> のメール:
> 
> 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, tlaronde@polynum.com wrote:
>> 
>> Hello, 
>> 
>> I have finally managed to install plan9 on my new workstation. 
>> 
>> By putting back the keyboard on the PS2 connector, I have solved some 
>> unfelicities (with the USB->legacy emulation, the keyboard switched 
>> every other typing to UPPERCASE...). 
>> 
>> The mouse, still USB connected and hence "emulated" by the BIOS, 
>> does not react very gracefully but I will see if I can play with 
>> the acceleration and the resolution to have a better terminal. (Or 
>> if I manage to find a long enough cable to have a COM slot back since 
>> there is the bare connector on the motherboard; in this case I will go 
>> back to a com mouse and will be able to probe USB for other 
>> devices---external disks.) 
>> 
>> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
>> when testing the compilation of kerTeX (it has been fixed: it works for 
>> the last release; rio to come for METAFONT), the throughput with hget is 
>> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
>> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
>> be obviously higher). 
>> 
>> Setting the mtu to jumbo packet does not help. 
>> 
>> Is there something to tune or is it simply that the chip is not well 
>> supported? 
>> 
>> TIA 
>> -- 
>>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com> 
>>                      http://www.kergis.com/ 
>>                      http://www.arts-po.fr/ 
>> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>> 
>> 




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-18 23:41   ` arisawa
@ 2016-02-19  1:56     ` erik quanstrom
  2016-02-19 15:17     ` erik quanstrom
  1 sibling, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-19  1:56 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

the standard labs driver checks the speed during auto negotiation.
so it is often wrong.

- erik


On Feb 18, 2016 3:41 PM, arisawa <arisawa@ar.aichi-u.ac.jp> wrote:
>
> 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 = 0x3c000000 phyv = 0x0002 
> #l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891 
>
> the “100Mbps" in the message is correct or not? 
>
> I also feel rtl8169 is slow, so I replace on-board rtl8169 by intel’s card  if possible. 
>
>
>
> > 2016/02/18 22:22、erik quanstrom <quanstro@quanstro.net> のメール: 
> > 
> > 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, tlaronde@polynum.com wrote: 
> >> 
> >> Hello, 
> >> 
> >> I have finally managed to install plan9 on my new workstation. 
> >> 
> >> By putting back the keyboard on the PS2 connector, I have solved some 
> >> unfelicities (with the USB->legacy emulation, the keyboard switched 
> >> every other typing to UPPERCASE...). 
> >> 
> >> The mouse, still USB connected and hence "emulated" by the BIOS, 
> >> does not react very gracefully but I will see if I can play with 
> >> the acceleration and the resolution to have a better terminal. (Or 
> >> if I manage to find a long enough cable to have a COM slot back since 
> >> there is the bare connector on the motherboard; in this case I will go 
> >> back to a com mouse and will be able to probe USB for other 
> >> devices---external disks.) 
> >> 
> >> One thing is inconvenient: I have a rtl8169 gbe pci-e ether card, but 
> >> when testing the compilation of kerTeX (it has been fixed: it works for 
> >> the last release; rio to come for METAFONT), the throughput with hget is 
> >> abysmal: 30kB/s... The disk is not a fault, reacting well enough (I have 
> >> plenty of RAM and the blocks cache for fossil is set to 3000---it could 
> >> be obviously higher). 
> >> 
> >> Setting the mtu to jumbo packet does not help. 
> >> 
> >> Is there something to tune or is it simply that the chip is not well 
> >> supported? 
> >> 
> >> TIA 
> >> -- 
> >>         Thierry Laronde <tlaronde +AT+ polynum +dot+ com> 
> >>                      http://www.kergis.com/ 
> >>                      http://www.arts-po.fr/ 
> >> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
> >> 
> >> 
>
>
>

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-18 13:22 ` erik quanstrom
  2016-02-18 23:41   ` arisawa
@ 2016-02-19 12:52   ` tlaronde
  2016-02-19 15:13     ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-19 12:52 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 and
/net/ether0/ifstats:

          3           0 debugpt
          7           0 mathemu
          8           0 doublefault
          9           0 mathover
         14           0 fault386
         15           0 unexpected
         16           0 matherror
         32           0 clock
         33           1 kbd
         35           3 sdE (iahci)
         38           6 floppy
         39           7 lpt
         42          10 ether0
         44          12 kbdaux

ifstats:

TxOk: 4483
RxOk: 7520
TxEr: 0
RxEr: 0
MissPkt: 0
FAE: 0
Tx1Col: 0
TxMCol: 0
RxOkPh: 7482
RxOkBrd: 28
RxOkMu: 10
TxAbt: 0
TxUndrn: 0
txdu: 0
tcpf: 0
udpf: 0
ipf: 0
fovf: 0
ierrs: 0
rer: 0
rdu: 0
punlc: 0
fovw: 0
tcr: 0x2f200700
rcr: 0x0000e70e
multicast: 10
phy:    1000 796d 001c c914 01e1 c5e1 000d 2801
        4e2e 0300 3800 0000 0000 0000 0000 3000
        01ee ac9c 0000 0000 8040 0006 4100 2100
        0000 8c00 0040 0106 217c 8fbc 0123 0000
rcv descrs processed at once:	highwater 2/255 curr 1 hitmax 0
xmit descr queue len:	highwater 0/31 curr 0 hitmax 0

Note: _this_ card is a PCIe supplementary one. There is another rtl
embedded in the motherboard that Plan9 does not recognize:

rtl8169: unknown mac 8168 4c000000
oui 0x732 phyno 1, macv = 0x2c000000 phyv = 0x0004
#l0: rtl8169: 1Gbps port 0xC000 irq 10: e8de2701f455

I have tried by disabling the embedded ether controller, the result is
the same.

Another kernel message for what is worth (since I don't know what it
means, I don't know if it's relevant):

i8042: fe returned to the ea command

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-19 12:52   ` tlaronde
@ 2016-02-19 15:13     ` erik quanstrom
  2016-02-19 17:11       ` tlaronde
  2016-02-20 10:32       ` tlaronde
  0 siblings, 2 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-19 15:13 UTC (permalink / raw)
  To: 9fans

> 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         190397006374 msi-x    ether0
which gives vector.processor, bus irq, number of interrupts, total fastticks taken, type, and driver.
with this info, one can calculate ns/interrupt and interrupts/sec.

> TxOk: 4483
> RxOk: 7520
[..]
> xmit descr queue len:	highwater 0/31 curr 0 hitmax 0

this doesn't look like very much traffic.  how did you test?  are you using
the latest tcp?  what is the ping latency?  older labs kernels did a poor job
with moderate latency, and any packet loss.  newer versions should be ok,
but i haven't tested myself.

> rtl8169: unknown mac 8168 4c000000

my version of the driver handles this hardware

> i8042: fe returned to the ea command

you don't have a ps2 mouse, but the system is configured to expect one.
0xea -> set streaming.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-18 23:41   ` arisawa
  2016-02-19  1:56     ` erik quanstrom
@ 2016-02-19 15:17     ` erik quanstrom
  1 sibling, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-19 15:17 UTC (permalink / raw)
  To: 9fans

>> Setting the mtu to jumbo packet does not help.

8169 chips can send 4096-byte packets without losing performance, but
anything larger performs worse than standard frame sizes.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-19 15:13     ` erik quanstrom
@ 2016-02-19 17:11       ` tlaronde
  2016-02-20 10:32       ` tlaronde
  1 sibling, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-19 17:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Fri, Feb 19, 2016 at 07:13:23AM -0800, erik quanstrom wrote:
> 
> > TxOk: 4483
> > RxOk: 7520
> [..]
> > xmit descr queue len:	highwater 0/31 curr 0 hitmax 0
> 
> this doesn't look like very much traffic.  how did you test?  are you using
> the latest tcp?  what is the ping latency?  older labs kernels did a poor job
> with moderate latency, and any packet loss.  newer versions should be ok,
> but i haven't tested myself.
> 

sending 32 64 byte messages 1000 ms apart to icmp!192.168.1.1!1
0: rtt 310 µs, avg rtt 310 µs, ttl = 64
1: rtt 314 µs, avg rtt 312 µs, ttl = 64
2: rtt 295 µs, avg rtt 306 µs, ttl = 64
3: rtt 269 µs, avg rtt 297 µs, ttl = 64
4: rtt 325 µs, avg rtt 302 µs, ttl = 64
5: rtt 267 µs, avg rtt 296 µs, ttl = 64
6: rtt 279 µs, avg rtt 294 µs, ttl = 64
7: rtt 270 µs, avg rtt 291 µs, ttl = 64
8: rtt 272 µs, avg rtt 289 µs, ttl = 64
9: rtt 259 µs, avg rtt 286 µs, ttl = 64

For the test, I simply hget'ed the kertex tarball. This is always
28kB/s... So even downloading 10MB takes more than 6 minutes.

For the version, i don't know: I downloaded the iso distrib from the 
Bell Labs web site, some weeks ago, when the site was still online.

The problem is that I tried 3 versions of the distrib: USB and iso from
9atom (but the kernels panic'ed with my hardware); and the Bell Labs iso
(the kernel booted, but there were further problems with USB so I ended
up making the install "by hand", but with the files from the Bell Labs
iso).

> > rtl8169: unknown mac 8168 4c000000
> 
> my version of the driver handles this hardware

Unfortunately see above: the 9atom kernels crashed for my hardware
(bicore Intel Pentium G3220).

> 
> > i8042: fe returned to the ea command
> 
> you don't have a ps2 mouse, but the system is configured to expect one.
> 0xea -> set streaming.

Thanks for the explanation.

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-19 15:13     ` erik quanstrom
  2016-02-19 17:11       ` tlaronde
@ 2016-02-20 10:32       ` tlaronde
  2016-02-20 11:23         ` Kenny Lasse Hoff Levinsen
  1 sibling, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-20 10:32 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 device (driver) is not at fault but that
something is wrong along the path when I get through the gateway.

Has somebody an idea about what I may do wrong or what could cause such
a cost on the gateway.

I have set IPv6 on the gateway: no difference. I have tried to disable
IPv6 on the ether: no difference.

ip/traceroute to the outside server shows results that are on par
with what I get from NetBSD on this very node where I run also
plan9.

"Something" is obviously wrong. But "what" is less obvious (at least to
me).

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 10:32       ` tlaronde
@ 2016-02-20 11:23         ` Kenny Lasse Hoff Levinsen
  2016-02-20 12:11           ` tlaronde
  0 siblings, 1 reply; 83+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-02-20 11:23 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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, tlaronde@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 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 device (driver) is not at fault but that
> something is wrong along the path when I get through the gateway.
> 
> Has somebody an idea about what I may do wrong or what could cause such
> a cost on the gateway.
> 
> I have set IPv6 on the gateway: no difference. I have tried to disable
> IPv6 on the ether: no difference. 
> 
> ip/traceroute to the outside server shows results that are on par
> with what I get from NetBSD on this very node where I run also
> plan9.
> 
> "Something" is obviously wrong. But "what" is less obvious (at least to
> me).
> 
> -- 
>        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
>                     http://www.kergis.com/
>                     http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
> 



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 11:23         ` Kenny Lasse Hoff Levinsen
@ 2016-02-20 12:11           ` tlaronde
  2016-02-20 13:31             ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-20 12:11 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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.

Best,
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 12:11           ` tlaronde
@ 2016-02-20 13:31             ` hiro
  2016-02-20 14:01               ` tlaronde
  0 siblings, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-20 13:31 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

what is the latency on WAN?



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 13:31             ` hiro
@ 2016-02-20 14:01               ` tlaronde
  2016-02-20 14:06                 ` lucio
  2016-02-20 17:20                 ` erik quanstrom
  0 siblings, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-20 14:01 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 server
(downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing
it.

I wondered if the unsupported same chip integrated network card would
be a problem. But disabling it via the BIOS doesn't change anything.

Is there a way to trace what hget is doing/calling so that I can have a
clue about the bottleneck? There is no transmission errors on the
interface, so the problem is in the upper levels of TCP/IP.
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 14:01               ` tlaronde
@ 2016-02-20 14:06                 ` lucio
  2016-02-20 14:22                   ` tlaronde
  2016-02-20 17:20                 ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-20 14:06 UTC (permalink / raw)
  To: 9fans

> 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 least exclude the disks and fossil from the equation.

Lucio.




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 14:06                 ` lucio
@ 2016-02-20 14:22                   ` tlaronde
  0 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-20 14:22 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Sat, Feb 20, 2016 at 04:06:24PM +0200, lucio@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.
>
> Just for one more data point: dump the hget output to /dev/null.  That
> may at least exclude the disks and fossil from the equation.

I have already ruled this out: copying the file in the very same place
from mounted ftpfs (LAN), no speed problem. Copying in /tmp served by
ramfs, no difference for hget...
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 14:01               ` tlaronde
  2016-02-20 14:06                 ` lucio
@ 2016-02-20 17:20                 ` erik quanstrom
  2016-02-20 17:45                   ` tlaronde
  2016-02-20 19:07                   ` tlaronde
  1 sibling, 2 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-20 17:20 UTC (permalink / raw)
  To: 9fans

On Sat Feb 20 06:04:02 PST 2016, tlaronde@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 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.
>
> I wondered if the unsupported same chip integrated network card would
> be a problem. But disabling it via the BIOS doesn't change anything.
>
> Is there a way to trace what hget is doing/calling so that I can have a
> clue about the bottleneck? There is no transmission errors on the
> interface, so the problem is in the upper levels of TCP/IP.

yes.  i believe this was suggested before.  from the evidence, the best
guess is that you are using an old kernel with an old tcp.

the old tcp had abysmal performance starting at a latency of ~10ms.  this
was due to a flawed implementation of tcp reno.  plan 9 used to commit
the cardinal sin of tcp, and move the left edge of the window.

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

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 17:20                 ` erik quanstrom
@ 2016-02-20 17:45                   ` tlaronde
  2016-02-20 19:26                     ` erik quanstrom
  2016-02-20 19:07                   ` tlaronde
  1 sibling, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-20 17:45 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Sat, Feb 20, 2016 at 09:20:52AM -0800, erik quanstrom wrote:
> On Sat Feb 20 06:04:02 PST 2016, tlaronde@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 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.
> >
> > I wondered if the unsupported same chip integrated network card would
> > be a problem. But disabling it via the BIOS doesn't change anything.
> >
> > Is there a way to trace what hget is doing/calling so that I can have a
> > clue about the bottleneck? There is no transmission errors on the
> > interface, so the problem is in the upper levels of TCP/IP.
>
> yes.  i believe this was suggested before.  from the evidence, the best
> guess is that you are using an old kernel with an old tcp.

Does it explain the difference between LAN and WAN? ftp is TCP; and on
LAN there is no visible problem (connecting to a host running NetBSD)---
well, since the latency on LAN is the 1/300 of the latency of WAN, the
problem could be masked...

>
> the old tcp had abysmal performance starting at a latency of ~10ms.  this
> was due to a flawed implementation of tcp reno.  plan 9 used to commit
> the cardinal sin of tcp, and move the left edge of the window.
>
> 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 definitively down... Is there
somewhere the "latest" sources, at least with the TCP corrections?
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 17:20                 ` erik quanstrom
  2016-02-20 17:45                   ` tlaronde
@ 2016-02-20 19:07                   ` tlaronde
  2016-02-20 19:21                     ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-20 19:07 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

If I try to download the kertex tarball from "my" site (I just pay for
some space on a remote server; it is not my machine) the performance are
abysmal.

I tried another site, with http, in this case:

http://mirrors.ctan.org/macros/latex/base.zip

since the file for the base LaTeX is the same size as the tarball for
the whole kerTeX.

In this case, I have the following:

first ": 1024
second ": 34k
afterward: 1.7M!

So there is "something" about the "negociation" between hget and
"my" site that is not good---note: "my" site uses cookies (I don't;
this is the Apache running on the server that does; my pages don't
use cookies at all and I have no hand on that). I wonder if some
"persistent" (cookie) information could cause this misbehavior
(since I have a multiboot PC, this very same IP address is depending
on the moment whether NetBSD, Plan9 or, more rarely, Windows 8.1).

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 19:07                   ` tlaronde
@ 2016-02-20 19:21                     ` erik quanstrom
  0 siblings, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-20 19:21 UTC (permalink / raw)
  To: 9fans

> > 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 set>/net/log && tail -f /net/log".

chasing the performance of different sites is what lead to the tcp improvements.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 17:45                   ` tlaronde
@ 2016-02-20 19:26                     ` erik quanstrom
  2016-02-20 19:41                       ` Mark van Atten
                                         ` (2 more replies)
  0 siblings, 3 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-20 19:26 UTC (permalink / raw)
  To: 9fans

> > 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 definitively down... Is there
> somewhere the "latest" sources, at least with the TCP corrections?

i think that david has a mirror up, and 9fs sources still works here.

you can also grab the 9atom version @ http://sources.9atom.org/sys/src/9/ip/tcp.c
contact me off-list about any compile issues.  a few greps don't show any of
the usual suspects, but i haven't tried myself.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 19:26                     ` erik quanstrom
@ 2016-02-20 19:41                       ` Mark van Atten
  2016-02-20 20:18                         ` tlaronde
  2016-02-20 20:18                       ` tlaronde
  2016-02-22  9:14                       ` tlaronde
  2 siblings, 1 reply; 83+ messages in thread
From: Mark van Atten @ 2016-02-20 19:41 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> i think that david has a mirror up, and 9fs sources still works here.

http://9p.io/

Mark.



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 19:26                     ` erik quanstrom
  2016-02-20 19:41                       ` Mark van Atten
@ 2016-02-20 20:18                       ` tlaronde
  2016-02-22  9:14                       ` tlaronde
  2 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-20 20:18 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 sources. Where are now the "updated"
> > sources? since Bell Labs site seems to be definitively down... Is there
> > somewhere the "latest" sources, at least with the TCP corrections?
>
> i think that david has a mirror up, and 9fs sources still works here.
>
> you can also grab the 9atom version @ http://sources.9atom.org/sys/src/9/ip/tcp.c
> contact me off-list about any compile issues.  a few greps don't show any of
> the usual suspects, but i haven't tried myself.

Thanks. I will try the Bell Labs mirror and fall back to the 9atom
version in case of problem (just to try to avoid mixing sources with the
inability finally to be able to say exactly what version I run...).
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 19:41                       ` Mark van Atten
@ 2016-02-20 20:18                         ` tlaronde
  0 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-20 20:18 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-20 19:26                     ` erik quanstrom
  2016-02-20 19:41                       ` Mark van Atten
  2016-02-20 20:18                       ` tlaronde
@ 2016-02-22  9:14                       ` tlaronde
  2016-02-22  9:40                         ` Mark van Atten
  2016-02-22 11:06                         ` Richard Miller
  2 siblings, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22  9:14 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22  9:14                       ` tlaronde
@ 2016-02-22  9:40                         ` Mark van Atten
  2016-02-22 10:10                           ` tlaronde
  2016-02-22 10:15                           ` lucio
  2016-02-22 11:06                         ` Richard Miller
  1 sibling, 2 replies; 83+ messages in thread
From: Mark van Atten @ 2016-02-22  9:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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.



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22  9:40                         ` Mark van Atten
@ 2016-02-22 10:10                           ` tlaronde
  2016-02-22 10:15                           ` lucio
  1 sibling, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 10:10 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22  9:40                         ` Mark van Atten
  2016-02-22 10:10                           ` tlaronde
@ 2016-02-22 10:15                           ` lucio
  2016-02-22 11:05                             ` tlaronde
  1 sibling, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 10:15 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 10:15                           ` lucio
@ 2016-02-22 11:05                             ` tlaronde
  0 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 11:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 12:15:41PM +0200, lucio@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.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:

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22  9:14                       ` tlaronde
  2016-02-22  9:40                         ` Mark van Atten
@ 2016-02-22 11:06                         ` Richard Miller
  2016-02-22 11:40                           ` tlaronde
  1 sibling, 1 reply; 83+ messages in thread
From: Richard Miller @ 2016-02-22 11:06 UTC (permalink / raw)
  To: 9fans

> 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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 11:06                         ` Richard Miller
@ 2016-02-22 11:40                           ` tlaronde
  2016-02-22 12:00                             ` lucio
  2016-02-22 12:17                             ` Richard Miller
  0 siblings, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 11:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 11:06:47AM +0000, 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.90r 	 hget 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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 11:40                           ` tlaronde
@ 2016-02-22 12:00                             ` lucio
  2016-02-22 12:16                               ` tlaronde
  2016-02-22 12:17                             ` Richard Miller
  1 sibling, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 12:00 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:00                             ` lucio
@ 2016-02-22 12:16                               ` tlaronde
  0 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 12:16 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 02:00:53PM +0200, lucio@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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 11:40                           ` tlaronde
  2016-02-22 12:00                             ` lucio
@ 2016-02-22 12:17                             ` Richard Miller
  2016-02-22 12:29                               ` Mark van Atten
  2016-02-22 12:47                               ` tlaronde
  1 sibling, 2 replies; 83+ messages in thread
From: Richard Miller @ 2016-02-22 12:17 UTC (permalink / raw)
  To: 9fans

> 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 0xFE500000 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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:17                             ` Richard Miller
@ 2016-02-22 12:29                               ` Mark van Atten
  2016-02-22 12:47                               ` tlaronde
  1 sibling, 0 replies; 83+ messages in thread
From: Mark van Atten @ 2016-02-22 12:29 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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.



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:17                             ` Richard Miller
  2016-02-22 12:29                               ` Mark van Atten
@ 2016-02-22 12:47                               ` tlaronde
  2016-02-22 12:52                                 ` Mark van Atten
  2016-02-22 13:13                                 ` tlaronde
  1 sibling, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 12:47 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 12:17:30PM +0000, 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 0xFE500000 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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:47                               ` tlaronde
@ 2016-02-22 12:52                                 ` Mark van Atten
  2016-02-22 13:02                                   ` tlaronde
  2016-02-22 13:13                                 ` tlaronde
  1 sibling, 1 reply; 83+ messages in thread
From: Mark van Atten @ 2016-02-22 12:52 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Mark.


On 2/22/16, tlaronde@polynum.com <tlaronde@polynum.com> wrote:
> On Mon, Feb 22, 2016 at 12:17:30PM +0000, 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 0xFE500000 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 <tlaronde +AT+ polynum +dot+ com>
>                      http://www.kergis.com/
>                      http://www.arts-po.fr/
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C
>
>



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:52                                 ` Mark van Atten
@ 2016-02-22 13:02                                   ` tlaronde
  2016-02-22 13:20                                     ` erik quanstrom
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-22 13:02 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 12:47                               ` tlaronde
  2016-02-22 12:52                                 ` Mark van Atten
@ 2016-02-22 13:13                                 ` tlaronde
  2016-02-22 13:29                                   ` lucio
  1 sibling, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-22 13:13 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:02                                   ` tlaronde
@ 2016-02-22 13:20                                     ` erik quanstrom
  2016-02-22 15:05                                       ` tlaronde
  0 siblings, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-22 13:20 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

why?  what's the evidence?

- erik


On Feb 22, 2016 5:02 AM, tlaronde@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 <tlaronde +AT+ polynum +dot+ com> 
>                      http://www.kergis.com/ 
>                      http://www.arts-po.fr/ 
> Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C 
>
>

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:13                                 ` tlaronde
@ 2016-02-22 13:29                                   ` lucio
  2016-02-22 13:39                                     ` David du Colombier
  0 siblings, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 13:29 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:29                                   ` lucio
@ 2016-02-22 13:39                                     ` David du Colombier
  2016-02-22 14:39                                       ` rod
  2016-02-22 15:44                                       ` erik quanstrom
  0 siblings, 2 replies; 83+ messages in thread
From: David du Colombier @ 2016-02-22 13:39 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

real    0m1.783s
user    0m0.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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:39                                     ` David du Colombier
@ 2016-02-22 14:39                                       ` rod
  2016-02-22 15:12                                         ` tlaronde
  2016-02-22 15:44                                       ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: rod @ 2016-02-22 14:39 UTC (permalink / raw)
  To: 9fans

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.

-rod



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:20                                     ` erik quanstrom
@ 2016-02-22 15:05                                       ` tlaronde
  2016-02-22 15:19                                         ` lucio
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-22 15:05 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 14:39                                       ` rod
@ 2016-02-22 15:12                                         ` tlaronde
  2016-02-22 15:21                                           ` stanley lieber
  2016-02-22 16:45                                           ` [9fans] rtl8169 gbe slow rod
  0 siblings, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 15:12 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 02:39:20PM +0000, rod@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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:05                                       ` tlaronde
@ 2016-02-22 15:19                                         ` lucio
  2016-02-22 15:34                                           ` tlaronde
  0 siblings, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 15:19 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:12                                         ` tlaronde
@ 2016-02-22 15:21                                           ` stanley lieber
  2016-02-22 15:27                                             ` tlaronde
  2016-02-22 16:45                                           ` [9fans] rtl8169 gbe slow rod
  1 sibling, 1 reply; 83+ messages in thread
From: stanley lieber @ 2016-02-22 15:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

Have you tried setting and alternate user agent?

sl




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:21                                           ` stanley lieber
@ 2016-02-22 15:27                                             ` tlaronde
  2016-02-22 15:45                                               ` erik quanstrom
  2016-02-22 15:46                                               ` David du Colombier
  0 siblings, 2 replies; 83+ messages in thread
From: tlaronde @ 2016-02-22 15:27 UTC (permalink / raw)
  To: sl, Fans of the OS Plan 9 from Bell Labs

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?
--
        Thierry Laronde <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:19                                         ` lucio
@ 2016-02-22 15:34                                           ` tlaronde
  2016-02-22 15:43                                             ` lucio
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-22 15:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 05:19:04PM +0200, lucio@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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:34                                           ` tlaronde
@ 2016-02-22 15:43                                             ` lucio
  0 siblings, 0 replies; 83+ messages in thread
From: lucio @ 2016-02-22 15:43 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 13:39                                     ` David du Colombier
  2016-02-22 14:39                                       ` rod
@ 2016-02-22 15:44                                       ` erik quanstrom
  1 sibling, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-22 15:44 UTC (permalink / raw)
  To: 9fans

On Mon Feb 22 05:41:31 PST 2016, 0intro@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
>
> real    0m1.783s
> user    0m0.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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:27                                             ` tlaronde
@ 2016-02-22 15:45                                               ` erik quanstrom
  2016-02-22 15:46                                               ` David du Colombier
  1 sibling, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-22 15:45 UTC (permalink / raw)
  To: 9fans

On Mon Feb 22 07:29:56 PST 2016, tlaronde@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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:27                                             ` tlaronde
  2016-02-22 15:45                                               ` erik quanstrom
@ 2016-02-22 15:46                                               ` David du Colombier
  2016-02-22 16:28                                                 ` Kenny Lasse Hoff Levinsen
  1 sibling, 1 reply; 83+ messages in thread
From: David du Colombier @ 2016-02-22 15:46 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

> 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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:46                                               ` David du Colombier
@ 2016-02-22 16:28                                                 ` Kenny Lasse Hoff Levinsen
  2016-02-22 16:40                                                   ` lucio
  0 siblings, 1 reply; 83+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-02-22 16:28 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <0intro@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
> 



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 16:28                                                 ` Kenny Lasse Hoff Levinsen
@ 2016-02-22 16:40                                                   ` lucio
  2016-02-22 16:57                                                     ` Kenny Lasse Hoff Levinsen
  0 siblings, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 16:40 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 15:12                                         ` tlaronde
  2016-02-22 15:21                                           ` stanley lieber
@ 2016-02-22 16:45                                           ` rod
  2016-02-22 16:57                                             ` tlaronde
  1 sibling, 1 reply; 83+ messages in thread
From: rod @ 2016-02-22 16:45 UTC (permalink / raw)
  To: 9fans

>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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 16:45                                           ` [9fans] rtl8169 gbe slow rod
@ 2016-02-22 16:57                                             ` tlaronde
  2016-02-22 17:13                                               ` David du Colombier
  0 siblings, 1 reply; 83+ messages in thread
From: tlaronde @ 2016-02-22 16:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

On Mon, Feb 22, 2016 at 04:45:12PM +0000, rod@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 <tlaronde +AT+ polynum +dot+ com>
                     http://www.kergis.com/
                     http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89  250D 52B1 AE95 6006 F40C



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 16:40                                                   ` lucio
@ 2016-02-22 16:57                                                     ` Kenny Lasse Hoff Levinsen
  2016-02-22 17:03                                                       ` [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow) lucio
  0 siblings, 1 reply; 83+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-02-22 16:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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, lucio@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.
> 
> 



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow)
  2016-02-22 16:57                                                     ` Kenny Lasse Hoff Levinsen
@ 2016-02-22 17:03                                                       ` lucio
  2016-02-23 10:36                                                         ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-22 17:03 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 16:57                                             ` tlaronde
@ 2016-02-22 17:13                                               ` David du Colombier
  2016-02-22 17:57                                                 ` Skip Tavakkolian
  2016-02-23 10:34                                                 ` hiro
  0 siblings, 2 replies; 83+ messages in thread
From: David du Colombier @ 2016-02-22 17:13 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I've uploaded a pcap trace for future reference.

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

--
David du Colombier



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 17:13                                               ` David du Colombier
@ 2016-02-22 17:57                                                 ` Skip Tavakkolian
  2016-02-23 10:34                                                 ` hiro
  1 sibling, 0 replies; 83+ messages in thread
From: Skip Tavakkolian @ 2016-02-22 17:57 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

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 <0intro@gmail.com> wrote:

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

[-- Attachment #2: Type: text/html, Size: 734 bytes --]

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-22 17:13                                               ` David du Colombier
  2016-02-22 17:57                                                 ` Skip Tavakkolian
@ 2016-02-23 10:34                                                 ` hiro
  2016-02-23 12:24                                                   ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 10:34 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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
half without recovery till the end: http://176.31.253.70/tcp/

The receive window from hget seems to be *nearly* fully open, but is
changing (slightly) all the time. This I didn't expect, but I doubt
it's to be blamed for the bandwidth degradation you're seeing.

On 2/22/16, David du Colombier <0intro@gmail.com> wrote:
> I've uploaded a pcap trace for future reference.
>
> http://9legacy.org/download/pcap/kergis_plan9.pcap
>
> --
> David du Colombier
>
>



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow)
  2016-02-22 17:03                                                       ` [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow) lucio
@ 2016-02-23 10:36                                                         ` hiro
  0 siblings, 0 replies; 83+ messages in thread
From: hiro @ 2016-02-23 10:36 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

hj-ack ?



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 10:34                                                 ` hiro
@ 2016-02-23 12:24                                                   ` erik quanstrom
  2016-02-23 12:30                                                     ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 12:24 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

why wouldn't you expect the receive window to change?

- erik


On Feb 23, 2016 2:34 AM, hiro <23hiro@gmail.com> wrote:
>
> 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 
> half without recovery till the end: http://176.31.253.70/tcp/ 
>
> The receive window from hget seems to be *nearly* fully open, but is 
> changing (slightly) all the time. This I didn't expect, but I doubt 
> it's to be blamed for the bandwidth degradation you're seeing. 
>
> On 2/22/16, David du Colombier <0intro@gmail.com> wrote: 
> > I've uploaded a pcap trace for future reference. 
> > 
> > http://9legacy.org/download/pcap/kergis_plan9.pcap 
> > 
> > -- 
> > David du Colombier 
> > 
> > 
>
>

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:24                                                   ` erik quanstrom
@ 2016-02-23 12:30                                                     ` hiro
  2016-02-23 12:37                                                       ` hiro
  2016-02-23 15:18                                                       ` erik quanstrom
  0 siblings, 2 replies; 83+ messages in thread
From: hiro @ 2016-02-23 12:30 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 uplink).
in the past it seems to have been used to combat memory limitations of
the receiver. but nowadays we have enough memory, so in normal
operation rwin should always be fully open.



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:30                                                     ` hiro
@ 2016-02-23 12:37                                                       ` hiro
  2016-02-23 12:40                                                         ` hiro
  2016-02-23 15:17                                                         ` erik quanstrom
  2016-02-23 15:18                                                       ` erik quanstrom
  1 sibling, 2 replies; 83+ messages in thread
From: hiro @ 2016-02-23 12:37 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:37                                                       ` hiro
@ 2016-02-23 12:40                                                         ` hiro
  2016-02-23 12:48                                                           ` hiro
  2016-02-23 15:17                                                         ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 12:40 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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.



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:40                                                         ` hiro
@ 2016-02-23 12:48                                                           ` hiro
  2016-02-23 15:16                                                             ` erik quanstrom
  0 siblings, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 12:48 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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?!



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:48                                                           ` hiro
@ 2016-02-23 15:16                                                             ` erik quanstrom
  2016-02-23 17:27                                                               ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 15:16 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 04:49:55 PST 2016, 23hiro@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 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

yes.  but as we're sending nothing, we can ack into an empty window.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:37                                                       ` hiro
  2016-02-23 12:40                                                         ` hiro
@ 2016-02-23 15:17                                                         ` erik quanstrom
  2016-02-23 17:24                                                           ` hiro
  1 sibling, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 15:17 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 04:39:42 PST 2016, 23hiro@gmail.com wrote:
> in any case we seem limited by congestion window, not rwin.

can you explain?

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 12:30                                                     ` hiro
  2016-02-23 12:37                                                       ` hiro
@ 2016-02-23 15:18                                                       ` erik quanstrom
  1 sibling, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 15:18 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 04:32:50 PST 2016, 23hiro@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 uplink).
> in the past it seems to have been used to combat memory limitations of
> the receiver. but nowadays we have enough memory, so in normal
> operation rwin should always be fully open.

we're not.  we're advertizing 65535<<4, as noted earlier.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 15:17                                                         ` erik quanstrom
@ 2016-02-23 17:24                                                           ` hiro
  2016-02-23 17:38                                                             ` erik quanstrom
  2016-02-23 17:48                                                             ` lucio
  0 siblings, 2 replies; 83+ messages in thread
From: hiro @ 2016-02-23 17:24 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 produced. perhaps
wireshark is also interpreting it wrong, or timestamps are broken...

On 2/23/16, erik quanstrom <quanstro@quanstro.net> wrote:
> On Tue Feb 23 04:39:42 PST 2016, 23hiro@gmail.com wrote:
>> in any case we seem limited by congestion window, not rwin.
>
> can you explain?
>
> - erik
>
>



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 15:16                                                             ` erik quanstrom
@ 2016-02-23 17:27                                                               ` hiro
  0 siblings, 0 replies; 83+ messages in thread
From: hiro @ 2016-02-23 17:27 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:24                                                           ` hiro
@ 2016-02-23 17:38                                                             ` erik quanstrom
  2016-02-23 17:50                                                               ` hiro
  2016-02-23 17:54                                                               ` Kenny Lasse Hoff Levinsen
  2016-02-23 17:48                                                             ` lucio
  1 sibling, 2 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 17:38 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 09:25:53 PST 2016, 23hiro@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 there's also
> outliers? below 1ms. i don't get how this pcap got produced. perhaps
> wireshark is also interpreting it wrong, or timestamps are broken...

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

machine on the us west coast.  clearly we are prevoking some sort of odd behavior
in this machine, but it's not clear to me what we're doing.

the only clue we have is the out-of-window rxes.  perhaps the sender is scaling.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:24                                                           ` hiro
  2016-02-23 17:38                                                             ` erik quanstrom
@ 2016-02-23 17:48                                                             ` lucio
  2016-02-23 17:52                                                               ` hiro
  1 sibling, 1 reply; 83+ messages in thread
From: lucio @ 2016-02-23 17:48 UTC (permalink / raw)
  To: 9fans

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




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:38                                                             ` erik quanstrom
@ 2016-02-23 17:50                                                               ` hiro
  2016-02-23 18:16                                                                 ` erik quanstrom
  2016-02-23 17:54                                                               ` Kenny Lasse Hoff Levinsen
  1 sibling, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 17:50 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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 <quanstro@quanstro.net> wrote:
> On Tue Feb 23 09:25:53 PST 2016, 23hiro@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 there's also
>> outliers? below 1ms. i don't get how this pcap got produced. perhaps
>> wireshark is also interpreting it wrong, or timestamps are broken...
>
>> > 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?
>
> machine on the us west coast.  clearly we are prevoking some sort of odd
> behavior
> in this machine, but it's not clear to me what we're doing.
>
> the only clue we have is the out-of-window rxes.  perhaps the sender is
> scaling.
>
> - erik
>
>



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:48                                                             ` lucio
@ 2016-02-23 17:52                                                               ` hiro
  0 siblings, 0 replies; 83+ messages in thread
From: hiro @ 2016-02-23 17:52 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

no, i don't see any routing info in your output.

On 2/23/16, lucio@proxima.alt.za <lucio@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.  Is it
> possible that the hop count is not stable?  Or the link gets
> saturated?
>
> Lucio.
>
>
>



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:38                                                             ` erik quanstrom
  2016-02-23 17:50                                                               ` hiro
@ 2016-02-23 17:54                                                               ` Kenny Lasse Hoff Levinsen
  2016-02-23 18:08                                                                 ` erik quanstrom
  1 sibling, 1 reply; 83+ messages in thread
From: Kenny Lasse Hoff Levinsen @ 2016-02-23 17:54 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

if you add an “s”, you get TLS. If you add a “0”, you get 100MB. If you remove a country code, it goes through Cloudflare. You’ll have to guess where to insert and remove those characters yourself, though!

Best regards,
Kenny Levinsen

> On 23 Feb 2016, at 18:38, erik quanstrom <quanstro@quanstro.net> wrote:
> 
> On Tue Feb 23 09:25:53 PST 2016, 23hiro@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 there's also
>> outliers? below 1ms. i don't get how this pcap got produced. perhaps
>> wireshark is also interpreting it wrong, or timestamps are broken...
> 
>>> 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?
> 
> machine on the us west coast.  clearly we are prevoking some sort of odd behavior
> in this machine, but it's not clear to me what we're doing.
> 
> the only clue we have is the out-of-window rxes.  perhaps the sender is scaling.
> 
> - erik
> 




^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:54                                                               ` Kenny Lasse Hoff Levinsen
@ 2016-02-23 18:08                                                                 ` erik quanstrom
  0 siblings, 0 replies; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 18:08 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 09:55:58 PST 2016, kennylevinsen@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 server. Should count as a “stock linux box with a non-weird HTTP server”.
> 
> if you add an “s”, you get TLS. If you add a “0”, you get 100MB. If you remove a country code, it goes through Cloudflare. You’ll have to guess where to insert and remove those characters yourself, though!

10x better performance than kergis.com

0.094u 0.641s 48.016r 	 hget -v http://de.kl.wtf/f/10mburandom

from the east coast with a non-residential uplink i get this very odd little wiggle

 ; time hget -v http://de.kl.wtf/f/10mburandom>/dev/null
1024 10485760
908553 10485760
2502873 10485760
2517473 10485760

unfortunately i don't have time to do more than putter today.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 17:50                                                               ` hiro
@ 2016-02-23 18:16                                                                 ` erik quanstrom
  2016-02-23 18:38                                                                   ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 18:16 UTC (permalink / raw)
  To: 9fans

On Tue Feb 23 09:52:28 PST 2016, 23hiro@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 http://downloads.kergis.com/kertex/kertex_bundle.tar download as before.

an out-of-window rx is a rx packet that has no byte in the current window.
this can happen for legitimate reasons, but generally it does not.

- erik



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 18:16                                                                 ` erik quanstrom
@ 2016-02-23 18:38                                                                   ` hiro
  2016-02-23 19:19                                                                     ` erik quanstrom
  0 siblings, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 18:38 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 18:38                                                                   ` hiro
@ 2016-02-23 19:19                                                                     ` erik quanstrom
  2016-02-23 19:35                                                                       ` hiro
  0 siblings, 1 reply; 83+ messages in thread
From: erik quanstrom @ 2016-02-23 19:19 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

I saw this.  I'm not looking at the pcap file

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

^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 19:19                                                                     ` erik quanstrom
@ 2016-02-23 19:35                                                                       ` hiro
  2016-02-23 20:21                                                                         ` tlaronde
  0 siblings, 1 reply; 83+ messages in thread
From: hiro @ 2016-02-23 19:35 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

* Re: [9fans] rtl8169 gbe slow
  2016-02-23 19:35                                                                       ` hiro
@ 2016-02-23 20:21                                                                         ` tlaronde
  0 siblings, 0 replies; 83+ messages in thread
From: tlaronde @ 2016-02-23 20:21 UTC (permalink / raw)
  To: Fans of the OS Plan 9 from Bell Labs

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

Both sides won't be possible (at least for me). What I plan to do is
tcpdump/snoopy the interface under NetBSD and Plan9 (from the very same
workstation), when downloading the "test" file, and look, separately
the two pcap and then compare the processing (I might even go as far as
compare the plan9 implementation with the 4.4BSD-lite).

But for the moment, I have taken down from the shelf Stevens TCP/IP
illustrated, since my knowledge needs both to be refreshed and to be
enhanced... (This means that it will take some time.)

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

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



^ permalink raw reply	[flat|nested] 83+ messages in thread

end of thread, other threads:[~2016-02-23 20:21 UTC | newest]

Thread overview: 83+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-18 11:30 [9fans] rtl8169 gbe slow tlaronde
2016-02-18 13:22 ` erik quanstrom
2016-02-18 23:41   ` arisawa
2016-02-19  1:56     ` erik quanstrom
2016-02-19 15:17     ` erik quanstrom
2016-02-19 12:52   ` tlaronde
2016-02-19 15:13     ` erik quanstrom
2016-02-19 17:11       ` tlaronde
2016-02-20 10:32       ` tlaronde
2016-02-20 11:23         ` Kenny Lasse Hoff Levinsen
2016-02-20 12:11           ` tlaronde
2016-02-20 13:31             ` hiro
2016-02-20 14:01               ` tlaronde
2016-02-20 14:06                 ` lucio
2016-02-20 14:22                   ` tlaronde
2016-02-20 17:20                 ` erik quanstrom
2016-02-20 17:45                   ` tlaronde
2016-02-20 19:26                     ` erik quanstrom
2016-02-20 19:41                       ` Mark van Atten
2016-02-20 20:18                         ` tlaronde
2016-02-20 20:18                       ` tlaronde
2016-02-22  9:14                       ` tlaronde
2016-02-22  9:40                         ` Mark van Atten
2016-02-22 10:10                           ` tlaronde
2016-02-22 10:15                           ` lucio
2016-02-22 11:05                             ` tlaronde
2016-02-22 11:06                         ` Richard Miller
2016-02-22 11:40                           ` tlaronde
2016-02-22 12:00                             ` lucio
2016-02-22 12:16                               ` tlaronde
2016-02-22 12:17                             ` Richard Miller
2016-02-22 12:29                               ` Mark van Atten
2016-02-22 12:47                               ` tlaronde
2016-02-22 12:52                                 ` Mark van Atten
2016-02-22 13:02                                   ` tlaronde
2016-02-22 13:20                                     ` erik quanstrom
2016-02-22 15:05                                       ` tlaronde
2016-02-22 15:19                                         ` lucio
2016-02-22 15:34                                           ` tlaronde
2016-02-22 15:43                                             ` lucio
2016-02-22 13:13                                 ` tlaronde
2016-02-22 13:29                                   ` lucio
2016-02-22 13:39                                     ` David du Colombier
2016-02-22 14:39                                       ` rod
2016-02-22 15:12                                         ` tlaronde
2016-02-22 15:21                                           ` stanley lieber
2016-02-22 15:27                                             ` tlaronde
2016-02-22 15:45                                               ` erik quanstrom
2016-02-22 15:46                                               ` David du Colombier
2016-02-22 16:28                                                 ` Kenny Lasse Hoff Levinsen
2016-02-22 16:40                                                   ` lucio
2016-02-22 16:57                                                     ` Kenny Lasse Hoff Levinsen
2016-02-22 17:03                                                       ` [9fans] FP instructions in note handlers (Was: rtl8169 gbe slow) lucio
2016-02-23 10:36                                                         ` hiro
2016-02-22 16:45                                           ` [9fans] rtl8169 gbe slow rod
2016-02-22 16:57                                             ` tlaronde
2016-02-22 17:13                                               ` David du Colombier
2016-02-22 17:57                                                 ` Skip Tavakkolian
2016-02-23 10:34                                                 ` hiro
2016-02-23 12:24                                                   ` erik quanstrom
2016-02-23 12:30                                                     ` hiro
2016-02-23 12:37                                                       ` hiro
2016-02-23 12:40                                                         ` hiro
2016-02-23 12:48                                                           ` hiro
2016-02-23 15:16                                                             ` erik quanstrom
2016-02-23 17:27                                                               ` hiro
2016-02-23 15:17                                                         ` erik quanstrom
2016-02-23 17:24                                                           ` hiro
2016-02-23 17:38                                                             ` erik quanstrom
2016-02-23 17:50                                                               ` hiro
2016-02-23 18:16                                                                 ` erik quanstrom
2016-02-23 18:38                                                                   ` hiro
2016-02-23 19:19                                                                     ` erik quanstrom
2016-02-23 19:35                                                                       ` hiro
2016-02-23 20:21                                                                         ` tlaronde
2016-02-23 17:54                                                               ` Kenny Lasse Hoff Levinsen
2016-02-23 18:08                                                                 ` erik quanstrom
2016-02-23 17:48                                                             ` lucio
2016-02-23 17:52                                                               ` hiro
2016-02-23 15:18                                                       ` erik quanstrom
2016-02-22 15:44                                       ` erik quanstrom
2016-02-20 19:07                   ` tlaronde
2016-02-20 19:21                     ` erik quanstrom

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