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
> That's also quite old. There's one called drawterm-elcapitan, take that or
> compile from the master branch.
My problem caused by the fact I launched the drawterm from Application directory
by GUI, where I replaced the drawterm binary in
/Applications/darwterm/Contents/MacOS
by the one I compi
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
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 -
> 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 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
> 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 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
> 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 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
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
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
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
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 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
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
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.
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
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
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
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
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
>
> 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
Have you tried setting and alternate user agent?
sl
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
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 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
> 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 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
> 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
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
> 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.
>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
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
> 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
I've uploaded a pcap trace for future reference.
http://9legacy.org/download/pcap/kergis_plan9.pcap
--
David du Colombier
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.
For those interested in the matter, I have opened
https://github.com/golang/go/issues/14471
I mention potentially reenabling duffcopy by writing some magic note handler
code that avoid the regular copy and zero optimizations, but I’m not entirely
sure if that’s a plausible path. If it is, I thi
the programming with limbo book is available online for free is you
know where to look. there haven't been many changes since it was made
afaik, start with that and just read the code.
On Sat, Feb 20, 2016 at 11:14 PM, Roswell Grey wrote:
> Hello,
>
> it seems that the online documentation for le
40 matches
Mail list logo
