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
downloads.kergis.com is some http server operated by OVH.
it would be easier to post a pcap from a transfer where you control
both sides and possibly enable debugging of window sizes, timeouts,
packet loss, etc. in tcp.c like erik did.
On 2/23/16, erik quanstrom wrote:
> I saw this. I'm not loo
I saw this. I'm not looking at the pcap file
On Feb 23, 2016 10:38 AM, hiro <23h...@gmail.com> wrote:
>
> i didn't see any out-of-window rx in the pcap. did i look the wrong way?
>
>
i didn't see any out-of-window rx in the pcap. did i look the wrong way?
On Tue Feb 23 09:52:28 PST 2016, 23h...@gmail.com wrote:
> which machine is in the west coast? the one your tracing on? is that
> hget or a web server on plan9? is this the same test as posted by
> david?
>
> where do you see out-of-window rxes? what does that even mean?
this is from the same htt
On Tue Feb 23 09:55:58 PST 2016, kennylevin...@gmail.com wrote:
> Just in case you want a another point of reference to eliminate weirdness
> with the specific box: http://de.kl.wtf/f/10mburandom
>
> Linode Arch Linux box in Frankfurt, serving you with a pretty standard usage
> of Go’s http serv
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
no, i don't see any routing info in your output.
On 2/23/16, lu...@proxima.alt.za wrote:
>> i don't get how this pcap got produced. perhaps
>> wireshark is also interpreting it wrong, or timestamps are broken...
>
> I wonder if there isn't some route flapping involved here. Is it
> possible that
which machine is in the west coast? the one your tracing on? is that
hget or a web server on plan9? is this the same test as posted by
david?
where do you see out-of-window rxes? what does that even mean?
On 2/23/16, erik quanstrom wrote:
> On Tue Feb 23 09:25:53 PST 2016, 23h...@gmail.com 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.
On Tue Feb 23 09:25:53 PST 2016, 23h...@gmail.com wrote:
> in the long run the rwin seems much higher (65535) than the number of
> bytes in flight (less than 3x1500 bytes).
>
> i just noticed that the minimum latency numbers seem way low. many
> latency samples appear at around 40ms and 100ms, but
> 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?
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 pr
On Tue Feb 23 04:49:55 PST 2016, 23h...@gmail.com wrote:
> i just realized the http *response* packets all have their rwin set to
> 5808 only, while the other side has the former described behavior
> hovering around 65535.
> perhaps the http server does no window scaling?!
26/status:Established qi
On Tue Feb 23 04:32:50 PST 2016, 23h...@gmail.com wrote:
> erik: I don't think nowadays we need to limit rwin unless we
> artificially want to reduce the bandwidth (e.g. in my torrent program,
> or an rsync that's running in the background and shouldn't use up the
> whole bandwidth of the slow DSL
On Tue Feb 23 04:39:42 PST 2016, 23h...@gmail.com wrote:
> in any case we seem limited by congestion window, not rwin.
can you explain?
- erik
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?!
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.
in any case we seem limited by congestion window, not rwin.
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
why wouldn't you expect the receive window to change?
- erik
On Feb 23, 2016 2:34 AM, hiro <23h...@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 i
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
hal
is the local throughput what you expect to get? if yes, can you enable
tls? i'm wondering if http traffic is being intercepted in some way
(caches).
On Mon, Feb 22, 2016 at 9:13 AM David du Colombier <0in...@gmail.com> wrote:
> I've uploaded a pcap trace for future reference.
>
> http://9legacy.
I've uploaded a pcap trace for future reference.
http://9legacy.org/download/pcap/kergis_plan9.pcap
--
David du Colombier
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 di
On Mon, Feb 22, 2016 at 04:45:12PM +, r...@hemiola.co.uk wrote:
> >Does plan9 under lguest actually use the linux
> >hardware services? Is plan9 under lguest using "its" implementation
> >except for the low level device driving i.e. the ethernet provided
> >by the Linux host?
>
> Yes. The lgue
>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 inter
> 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.
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
> 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.
--
D
On Mon Feb 22 07:29:56 PST 2016, tlaro...@polynum.com wrote:
> On Mon, Feb 22, 2016 at 10:21:02AM -0500, stanley lieber wrote:
> > Have you tried setting and alternate user agent?
> >
>
> No. Is it possible to change the string for hget?
that's been ruled out, i think, by david.
- erik
> 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.
On Mon Feb 22 05:41:31 PST 2016, 0in...@gmail.com wrote:
> This issue seems more related to Plan 9 than hget.
>
> On Linux :
>
> $ time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
>
> real0m1.783s
> user0m0.037s
> sys 0m0.046s
>
> On 9vx:
>
> % time hget
On Mon, Feb 22, 2016 at 05:19:04PM +0200, lu...@proxima.alt.za wrote:
> > I have hence to ask the provider if there is something,
> > in their configuration, that could explain this
>
> If you can run NetBSD at the same time as Plan 9, you could also use
> tcpdump (whatever its current impersonati
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
http://www.kergis.com/
http://www.arts-po.fr/
Key fingerpri
Have you tried setting and alternate user agent?
sl
> 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
On Mon, Feb 22, 2016 at 02:39:20PM +, r...@hemiola.co.uk wrote:
> I get quite consistent results here.
>
> Downloading http://downloads.kergis.com/kertex/kertex_bundle.tar to /dev/null:
>
> linux over rtl8169 & ASDL : 5.4 seconds
> plan 9 native over rtl8169 & ASDL : 12.4 seconds
>
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 m
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
This issue seems more related to Plan 9 than hget.
On Linux :
$ time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
real0m1.783s
user0m0.037s
sys 0m0.046s
On 9vx:
% time hget -o /dev/null http://downloads.kergis.com/kertex/kertex_bundle.tar
couldn't set mtim
> 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
why? what's the evidence?
- erik
On Feb 22, 2016 5:02 AM, tlaro...@polynum.com wrote:
>
> On Mon, Feb 22, 2016 at 01:52:48PM +0100, Mark van Atten wrote:
> > Same 9front under virtualbox:
> >
> > term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip
> > 0.06u 0.24s 8.74
FWIW, I have sent a request to my provider asking if Plan9/hget could
trigger a "robot" rule leading to the throttling of the connection.
--
Thierry Laronde
http://www.kergis.com/
http://www.arts-po.fr/
Key fingerprint = 0FF7 E906 FBAF FE95 FD89
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
Same 9front under virtualbox:
term% time hget -o /dev/null http://mirrors.ctan.org/macros/latex/base.zip
0.06u 0.24s 8.74rhget -o /dev/null
http://mirrors.ctan.org/macros/latex/base.zip
Mark.
On 2/22/16, tlaro...@polynum.com wrote:
> On Mon, Feb 22, 2016 at 12:17:30PM +, Richard Mi
On Mon, Feb 22, 2016 at 12:17:30PM +, Richard Miller wrote:
> > It seems that Plan9 is not at fault per se
>
> I think it probably is. Here's another data point (same ADSL connection) -
The delicate point is: is plan9 at fault or it is the fact that it is
advertised as Plan9 that is the sour
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_bundl
> It seems that Plan9 is not at fault per se
I think it probably is. Here's another data point (same ADSL connection) -
#l0: i82579: 1Gbps port 0xFE50 irq 10: 386077f0e800
0.09u 0.08s 182.26r hget
http://downloads.kergis.com/kertex/kertex_bundle.tar
But on the same machine, using linu
On Mon, Feb 22, 2016 at 02:00:53PM +0200, lu...@proxima.alt.za wrote:
> > It seems that Plan9 is not at fault per se, but the server I'm on has
> > not a tremendous throughput, and since it is shared, varies greatly.
>
> It could be traffic related in a lot of ways. Or load related. Might
> be w
> 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 swing
On Mon, Feb 22, 2016 at 11:06:47AM +, Richard Miller wrote:
> > If someone under Plan9 could try to download with hget(1):
>
> >From home (ADSL connection) - standard distribution on x86:
>
> 0.15u 0.16s 183.90rhget
> http://downloads.kergis.com/kertex/kertex_bundle.tar
> #l0: rtl8169: 1
> 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 Amster
On Mon, Feb 22, 2016 at 12:15:41PM +0200, lu...@proxima.alt.za wrote:
> > 0.10u 0.22s 192.79r hget -o kertex_bundle.tar
> > http://downloads.kergis.com/kertex/kertex_bundle.tar
> >
> > This is under 9front under virtualbox 4.3.32.
>
> I get, from my workstation:
>
> 0.21u 1.34s 50.52r hget
> 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
an
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 -
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
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 t
On Sat, Feb 20, 2016 at 08:41:01PM +0100, Mark van Atten wrote:
> > i think that david has a mirror up, and 9fs sources still works here.
>
> http://9p.io/
Thanks, Mark!
--
Thierry Laronde
http://www.kergis.com/
http://www.arts-po.fr/
Key finge
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 source
> i think that david has a mirror up, and 9fs sources still works here.
http://9p.io/
Mark.
> > 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 def
> > 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
> 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).
On Sat, Feb 20, 2016 at 09:20:52AM -0800, erik quanstrom wrote:
> On Sat Feb 20 06:04:02 PST 2016, tlaro...@polynum.com wrote:
> > On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote:
> > > what is the latency on WAN?
> >
> > When using traceroute, I have 42.6ms for a roundtrip
> > (cf. with LAN
On Sat Feb 20 06:04:02 PST 2016, tlaro...@polynum.com wrote:
> On Sat, Feb 20, 2016 at 02:31:54PM +0100, hiro wrote:
> > what is the latency on WAN?
>
> When using traceroute, I have 42.6ms for a roundtrip
> (cf. with LAN: 0.23ms).
>
> But the very same machine, under NetBSD, with the very same
On Sat, Feb 20, 2016 at 04:06:24PM +0200, lu...@proxima.alt.za wrote:
> > But the very same machine, under NetBSD, with the very same ip address,
> > downloads the very same file from the very same external server
> > (downloads.kergis.com) in 17s, while hget(1) spends 6 minutes doing
> > it.
>
>
> 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 leas
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
what is the latency on WAN?
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.
Is your MTU higher that 1500? That might be able to mess things up over the
internet.
Best regards,
Kenny Levinsen
> On 20. feb. 2016, at 11.32, tlaro...@polynum.com wrote:
>
> I have compared downloading a file (via ftpfs) on the LAN, and
> downloading it from the WAN.
>
> On the LAN, I get t
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 devi
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
>> 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
> 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 190397
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 an
the standard labs driver checks the speed during auto negotiation.
so it is often wrong.
- erik
On Feb 18, 2016 3:41 PM, arisawa wrote:
>
> hello,
>
> rtl8169 is popular in cheap MB, so it is installed in my many MBs.
> however, cat /dev/kmesg claims:
> rtl8169: oui 0x732 phyno 1, macv = 0x3
hello,
rtl8169 is popular in cheap MB, so it is installed in my many MBs.
however, cat /dev/kmesg claims:
rtl8169: oui 0x732 phyno 1, macv = 0x3c00 phyv = 0x0002
#l0: rtl8169: 100Mbps port 0xD000 irq 10: 001fd0169891
the “100Mbps" in the message is correct or not?
I also feel rtl8169 is slow
the 8169 driver is pretty fast. I've measured it at more than 500mbps.
it sounds like something else is misbehaving. what does
/dev/irqstat say. I bet something is stuck.
- erik
On Feb 18, 2016 3:30 AM, tlaro...@polynum.com wrote:
>
> Hello,
>
> I have finally managed to install plan9 on my
80 matches
Mail list logo
