Hi Toke,
On May 6, 2015, at 22:43 , Toke Høiland-Jørgensen t...@toke.dk wrote:
Jonathan Morton chromati...@gmail.com writes:
Compare these totals to twice the ITU benchmark figures, rate
accordingly, and plot on a map.
A nice way of visualising this can be 'radius of reach within n
Hi Jonathan,
On May 6, 2015, at 22:25 , Jonathan Morton chromati...@gmail.com wrote:
So, as a proposed methodology, how does this sound:
Determine a reasonable ballpark figure for typical codec and jitter-buffer
delay (one way). Fix this as a constant value for the benchmark.
But
It may depend on the application's tolerance to packet loss. A packet
delayed further than the jitter buffer's tolerance counts as lost, so *IF*
jitter is randomly distributed, jitter can be traded off against loss. For
those purposes, standard deviation may be a valid metric.
However the more
On Thu, May 7, 2015 at 3:27 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, May 7, 2015 at 7:45 AM, Simon Barber si...@superduper.net wrote:
The key figure for VoIP is maximum latency, or perhaps somewhere around 99th
percentile. Voice packets cannot be played out if they are late, so how late
I am working on a multi-location jitter test (sorry PDV!) and it is showing
a lot of promise.
For the purposes of reporting jitter, what kind of time measurement horizon
is acceptable
and what is the +/- output actually based on, statistically ?
For example - is one minute or more of jitter
Hi jb,
On May 7, 2015, at 12:44 , jb jus...@dslr.net wrote:
There is a web socket based jitter tester now. It is very early stage but
works ok.
http://www.dslreports.com/speedtest?radar=1
Looks great.
So the latency displayed is the mean latency from a rolling 60 sample
On Thu, 7 May 2015, jb wrote:
There is a web socket based jitter tester now. It is very early stage but
works ok.
http://www.dslreports.com/speedtest?radar=1
So the latency displayed is the mean latency from a rolling 60 sample
buffer, Minimum latency is also displayed. and the +/- PDV value
What I don't know is how rapidly VOIP applications will adjust their
latency + jitter window (the operating point that they choose for their
operation). They can't adjust it instantly, as if they do, the transitions
from one operating point to another will cause problems, and you certainly
won't
I've made some changes and now this test displays the PDV column as
simply the recent average increase on the best latency seen, as usually the
best latency seen is pretty stable. (It also should work in firefox too
now).
In addition, every 30 seconds, a grade is printed next to a timestamp.
I
On Thu, 7 May 2015, Jim Gettys wrote:
Ideally, we need to get someone involved in WebRTC to help with this, to
present statistics that may be useful to end users to predict the
behavior of their service.
If nothing else, I would really like to be able to expose the realtime
application and
The key figure for VoIP is maximum latency, or perhaps somewhere around
99th percentile. Voice packets cannot be played out if they are late, so
how late they are is the only thing that matters. If many packets are early
but more than a very small number are late, then the jitter buffer has to
On Thu, May 7, 2015 at 7:45 AM, Simon Barber si...@superduper.net wrote:
The key figure for VoIP is maximum latency, or perhaps somewhere around 99th
percentile. Voice packets cannot be played out if they are late, so how late
they are is the only thing that matters. If many packets are early
On Thu, May 7, 2015 at 3:27 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, May 7, 2015 at 7:45 AM, Simon Barber si...@superduper.net wrote:
The key figure for VoIP is maximum latency, or perhaps somewhere around 99th
percentile. Voice packets cannot be played out if they are late, so how late
Hi Simon,
On May 6, 2015, at 07:08 , Simon Barber si...@superduper.net wrote:
Hi Sebastian,
My numbers are what I've personally come up with after working for many years
with VoIP - they have no other basis.
I did not intend to be-little such numbers at all, I just wanted to
So, as a proposed methodology, how does this sound:
Determine a reasonable ballpark figure for typical codec and jitter-buffer
delay (one way). Fix this as a constant value for the benchmark.
Measure the baseline network delays (round trip) to various reference
points worldwide.
Measure the
Hi Jim, hi List,
On May 6, 2015, at 17:30 , Jim Gettys j...@freedesktop.org wrote:
On Wed, May 6, 2015 at 4:50 AM, Sebastian Moeller moell...@gmx.de wrote:
Hi Simon,
On May 6, 2015, at 07:08 , Simon Barber si...@superduper.net wrote:
Hi Sebastian,
My numbers are what I've
Hi Sebastian,
My numbers are what I've personally come up with after working for many
years with VoIP - they have no other basis. One thing is that you have
to compare apples to apples - the ITU numbers are for acoustic one way
delay. The poor state of jitter buffer implementations that
Hi Mikhail,
On Apr 28, 2015, at 13:04 , Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 28 Apr 2015, David Lang wrote:
Voice is actually remarkably tolerant of pure latency. While 60ms of jitter
makes a connection almost unusalbe, a few hundred ms of consistant latency
isn't a
On Tue, 28 Apr 2015, David Lang wrote:
Voice is actually remarkably tolerant of pure latency. While 60ms of jitter
makes a connection almost unusalbe, a few hundred ms of consistant latency
isn't a problem. IIRC (from my college days when ATM was the new, hot
technology) you have to get up to
On Tue, Apr 28, 2015 at 12:18 AM, Sebastian Moeller moell...@gmx.de wrote:
Hi Dave,
On Apr 27, 2015, at 18:39 , Dave Taht dave.t...@gmail.com wrote:
On Fri, Apr 24, 2015 at 11:03 PM, Sebastian Moeller moell...@gmx.de wrote:
Hi Simon, hi List
On Apr 25, 2015, at 06:26 , Simon Barber
On Apr 28, 2015, at 4:38 AM, Sebastian Moeller moell...@gmx.de wrote:
Well, what I want to see is a study, preferably psychophysics not
modeling ;), showing the different latency “tolerances” of humans. I am
certain that humans can adjust to even dozens of seconds de;ays if need be,
On Tue, 28 Apr 2015, Sebastian Moeller wrote:
From Table 4.1 Delay Specifications” of that link we basically
have a recapitulation of the ITU-T G.114 source, one-way mouth to ear
latency thresholds for acceptable voip performance. The rest of the link
discusses additional sources of latency
On Tue, Apr 28, 2015 at 4:04 AM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Tue, 28 Apr 2015, David Lang wrote:
Voice is actually remarkably tolerant of pure latency. While 60ms of
jitter makes a connection almost unusalbe, a few hundred ms of consistant
latency isn't a problem. IIRC (from
On Tue, 28 Apr 2015, Toke Høiland-Jørgensen wrote:
David Lang da...@lang.hm writes:
Voice is actually remarkably tolerant of pure latency. While 60ms of
jitter makes a connection almost unusalbe, a few hundred ms of
consistant latency isn't a problem. IIRC (from my college days when
ATM was
On Tue, 28 Apr 2015, Rich Brown wrote:
On Apr 28, 2015, at 4:38 AM, Sebastian Moeller moell...@gmx.de wrote:
Well, what I want to see is a study, preferably psychophysics not
modeling ;), showing the different latency “tolerances” of humans. I am certain
that humans can adjust to
On Tue, 28 Apr 2015, Sebastian Moeller wrote:
Hi David,
On Apr 28, 2015, at 10:01 , David Lang da...@lang.hm wrote:
On Tue, 28 Apr 2015, Sebastian Moeller wrote:
I consider induced latencies of 30ms as a green band because that is
the outer limit of the range modern aqm technologies can
On Tue, 28 Apr 2015, Sebastian Moeller wrote:
I consider induced latencies of 30ms as a green band because that is
the outer limit of the range modern aqm technologies can achieve (fq
can get closer to 0). There was a lot of debate about 20ms being the
right figure for induced latency and/or
Hi Dave,
On Apr 27, 2015, at 18:39 , Dave Taht dave.t...@gmail.com wrote:
On Fri, Apr 24, 2015 at 11:03 PM, Sebastian Moeller moell...@gmx.de wrote:
Hi Simon, hi List
On Apr 25, 2015, at 06:26 , Simon Barber si...@superduper.net wrote:
Certainly the VoIP numbers are for peak total
David Lang da...@lang.hm writes:
Voice is actually remarkably tolerant of pure latency. While 60ms of
jitter makes a connection almost unusalbe, a few hundred ms of
consistant latency isn't a problem. IIRC (from my college days when
ATM was the new, hot technology) you have to get up to
On Thu, Apr 23, 2015 at 10:00 PM, jb jus...@dslr.net wrote:
The problem with metronome pinging is when there is a stall, they all pile
up then when they are released, you get this illusion of a 45 degree slope
of diminishing pings They all came back at the same instant (the 30 second
mark),
On Fri, Apr 24, 2015 at 11:03 PM, Sebastian Moeller moell...@gmx.de wrote:
Hi Simon, hi List
On Apr 25, 2015, at 06:26 , Simon Barber si...@superduper.net wrote:
Certainly the VoIP numbers are for peak total latency, and while Justin is
measuring total latency because he is only taking a
Hi Simon, hi List
On Apr 25, 2015, at 06:26 , Simon Barber si...@superduper.net wrote:
Certainly the VoIP numbers are for peak total latency, and while Justin is
measuring total latency because he is only taking a few samples the peak
values will be a little higher.
If your voip
Sebastian Moeller moell...@gmx.de writes:
I know this is not perfect and the numbers will probably require
severe bike-shedding”
Since you're literally asking for it... ;)
In this case we're talking about *added* latency. So the ambition should
be zero, or so close to it as to be
Sebastian Moeller moell...@gmx.de writes:
Oh, I can get behind that easily, I just thought basing the
limits on externally relevant total latency thresholds would directly
tell the user which applications might run well on his link. Sure this
means that people on a satellite link most
Hi jb,
this looks great!
On Apr 23, 2015, at 12:08 , jb jus...@dslr.net wrote:
This is how I've changed the graph of latency under load per input from you
guys.
Taken away log axis.
Put in two bands. Yellow starts at double the idle latency, and goes to 4x
the idle latency
red
On Fri, Apr 24, 2015 at 3:58 AM, Rich Brown richb.hano...@gmail.com wrote:
On Apr 23, 2015, at 6:22 PM, Dave Taht dave.t...@gmail.com wrote:
We had/have a lot of this problem in netperf-wrapper - a lot of data
tends to accumulate at the end of the test(s) and pollute the last few
data
On 04/23/2015 08:39 PM, Dave Taht wrote:
I have also sent mail and tweets to no effect.
I hereby donate 1k to the bufferbloat testing vs gogo-in-flight legal
defense fund. Anyone that gets busted by testing for bufferbloat on
an airplane using these new tools or the rrul test can tap me for
Perhaps where the green is should depend on the customer's access type. For
instance someone on fiber should have a much better ping than someone on
3G. But I agree this should be a fixed scale, not dependent on idle ping
time. Although VoIP might be good up to 100ms, gamers would want lower
Certainly the VoIP numbers are for peak total latency, and while Justin is
measuring total latency because he is only taking a few samples the peak
values will be a little higher.
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On April 24, 2015 9:04:45 PM Dave Taht
I think it might be useful to have a 'latency guide' for users. It would
say things like
100ms - VoIP applications work well
250ms - VoIP applications - conversation is not as natural as it could
be, although users may not notice this.
500ms - VoIP applications begin to have awkward pauses in
On 4/24/2015 1:55 AM, Sebastian Moeller wrote:
Okay so this would turn into: base latency to base latency + 30 ms:
green base latency + 31 ms to base latency + 100 ms: yellow base
latency + 101 ms to base latency + 200 ms: orange? base latency + 201
ms to base latency + 500 ms: red base
simon all your numbers are too large by at least a factor of 2. I
think also you are thinking about total latency, rather than induced
latency and jitter.
Please see my earlier email laying out the bands. And gettys' manifesto.
If you are thinking in terms of voip, less than 30ms *jitter* is
On Fri, 24 Apr 2015, jb wrote:
Don't you want to accuse the size of the buffer, rather than the latency?
The size of the buffer really doesn't matter. The latency is what hurts.
in theory, you could have a massive buffer for some low-priority non-TCP bulk
protocol (non-TCP so that it can do
Good question. I don't know.
However, it seems to me that if the receiver starts accepting and acking data
out of order, all sorts of other issues come up (what does this do to sequence
number randomization and the ability for an attacker to spew random data that
will show up somewhere in the
Selective ACKnowledgement in TCP does not change the in-order semantics
of TCP as seen by applications using it. Data is always presented to
the receiving application in order. What SACK does is make it more
likely that holes in the sequence of data will be filled-in sooner via
I just updated the Quick Test for Bufferbloat page to list DSLReports first
(and call it the Easy Test for Bufferbloat). See
http://www.bufferbloat.net/projects/cerowrt/wiki/Quick_Test_for_Bufferbloat
The page still describes the ping speed test procedure if people want to use
the old/harder
On Thu, 2015-04-23 at 12:17 +0200, renaud sallantin wrote:
Hi,
...
We did an extensive work on the Pacing in slow start and notably
during a large IW transmission.
Benefits are really outstanding! Our last implementation is just a
slight modification of FQ/pacing
* Sallantin,
By curiosity, what is now responsible for the drops if not the congestion?
I think the point was not that observed drops are not caused by congestion,
but that congestion doesn't reliably cause drops. Correlation is not
causation.
There are also cases when drops are in fact caused by something
Probably un-bloated only because it's old, and now running close to its
design speed. A newer modem will be designed to cope with higher future
speeds, so...
- Jonathan Morton
___
Bloat mailing list
Bloat@lists.bufferbloat.net
justin:
thx for nuking the log scale. that makes the bloat much more visible
here (typical cablemodem)
http://www.dslreports.com/speedtest/322800
I am puzzled as to my post fq_codel result here at T+40 and will have
to repeat...
http://www.dslreports.com/speedtest/322992
On Sun, Apr 19, 2015
Same thing applies for WiFi - oftentimes WiFi with poor signal levels
will cause drops, without congestion. This is something I'm working to
fix from the WiFi / L2 side. What are the solutions in L3? Some kind of
hybrid delay drop based CC?
Simon
On 4/23/2015 8:52 AM, Jonathan Morton wrote:
On Thu, Apr 23, 2015 at 1:19 PM, jb jus...@dslr.net wrote:
It's actually remarkably un-bloated...
I have seen a number of remarkably unbloated comcast tests
including this one at gigabit symmetric:
http://www.dslreports.com/speedtest/348305
which I know is someone testing their future
On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown richb.hano...@gmail.com wrote:
Hi Justin,
The newest Speed Test is great! It is more convincing than I even thought it
would be. These comments are focused on the theater of the measurements, so
that they are unambiguous, and that people can
Justifications for the gradations of color and thresholds I just
suggested you can find in the real time applications section of:
https://gettys.wordpress.com/2013/07/10/low-latency-requires-smart-queuing-traditional-aqm-is-not-enough/
This might be a good set of phrases to insert lines on the
Summary result from my hotel, with 11 seconds of bloat.
http://www.dslreports.com/speedtest/353034
On Thu, Apr 23, 2015 at 8:39 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, Apr 23, 2015 at 8:20 PM, Jim Gettys j...@freedesktop.org wrote:
I love the test, and thanks for the video!
There is
On Thu, 23 Apr 2015, Mikael Abrahamsson wrote:
It's actually remarkably un-bloated...
I re-did the test again at 6 in the morning,
http://www.dslreports.com/speedtest/353094 , and it's still not bloated.
I'm actually very happy for my connection from a bloat point of view, I
can do an scp
On Thu, Apr 23, 2015 at 9:16 PM, Mikael Abrahamsson swm...@swm.pp.se wrote:
On Thu, 23 Apr 2015, Mikael Abrahamsson wrote:
It's actually remarkably un-bloated...
I re-did the test again at 6 in the morning,
http://www.dslreports.com/speedtest/353094 , and it's still not bloated.
I'm
Hi,
2015-04-23 8:48 GMT+02:00 Eric Dumazet eric.duma...@gmail.com:
Wait, this is a 15 years old experiment using Reno and a single test
bed, using ns simulator.
Naive TCP pacing implementations were tried, and probably failed.
Pacing individual packet is quite bad, this is the first lesson
On 04/23/2015 08:48 AM, Eric Dumazet wrote:
Wait, this is a 15 years old experiment using Reno and a single test
bed, using ns simulator.
from that paper to nowadays several other studies have been made
and confirmed those first results. I did not check all the literature
though.
Naive
The problem with metronome pinging is when there is a stall, they all pile
up then when they are released, you get this illusion of a 45 degree slope
of diminishing pings They all came back at the same instant (the 30 second
mark), but were all sent at the ticks along the X-Axis. So from 15 to 30
On Thu, Apr 23, 2015 at 6:58 PM, Rich Brown richb.hano...@gmail.com wrote:
On Apr 23, 2015, at 6:22 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, Apr 23, 2015 at 2:44 PM, Rich Brown richb.hano...@gmail.com wrote:
Hi Justin,
The newest Speed Test is great! It is more convincing than I
I love the test, and thanks for the video!
There is an interesting problem: some paths have for all intents and
purposes infinite buffering, so you can end up with not just seconds, but
even minutes of bloat. The current interplanetary record for bufferbloat
is GoGo inflight is 760(!) seconds
The bumps are due to packet loss causing head of line blocking. Until the
lost packet is retransmitted the receiver can't release any subsequent
received packets to the application due to the requirement for in order
delivery. If you counted received bytes with a packet counter rather than
On Wed, Apr 22, 2015 at 06:50:57AM -0700, Eric Dumazet wrote:
You know, 'usual servers' used to run pfifo_fast, they now run sch_fq.
(All Google fleet at least)
I think Google is a bit ahead of the curve here :-) Does any distribution
ship sch_fq by default yet?
/* Steinar */
--
Homepage:
On Wed, 2015-04-22 at 08:51 +, luca.muscarie...@orange.com wrote:
cons: large BDP in general would be negatively affected.
A Gbps access vs a DSL access to the same server would require very
different tuning.
Yep. This is what I mentioned with 'long rtt'. This was relative to BDP.
On Wed, 2015-04-22 at 15:26 +, luca.muscarie...@orange.com wrote:
Do I need to read this as all Google servers == all servers :)
Read again what I wrote. Don't play with my words.
BTW if a paced flow from Google shares a bloated buffer with a non
paced flow from a non Google server,
On 04/22/2015 07:16 PM, Eric Dumazet wrote:
On Wed, 2015-04-22 at 18:35 +0200, MUSCARIELLO Luca IMT/OLN wrote:
FQ gives you flow isolation.
So does fq_codel.
yes, the FQ part of fq_codel. that's what I meant. Not the FQ part of
sch_fq.
sch_fq adds *pacing*, which in itself has
On Wed, 2015-04-22 at 18:35 +0200, MUSCARIELLO Luca IMT/OLN wrote:
FQ gives you flow isolation.
So does fq_codel.
sch_fq adds *pacing*, which in itself has benefits, regardless of fair
queues : Smaller bursts, less self inflicted drops.
If flows are competing, this is the role of Congestion
On Wed, Apr 22, 2015 at 10:16:19AM -0700, Eric Dumazet wrote:
sch_fq adds *pacing*, which in itself has benefits, regardless of fair
queues : Smaller bursts, less self inflicted drops.
Somehow I think sch_fq should just have been named sch_pacing :-)
/* Steinar */
--
Homepage:
On Wed, 2015-04-22 at 19:28 +0200, MUSCARIELLO Luca IMT/OLN wrote:
On 04/22/2015 07:16 PM, Eric Dumazet wrote:
sch_fq adds *pacing*, which in itself has benefits, regardless of fair
queues : Smaller bursts, less self inflicted drops.
This I understand. But it can't protect from non self
Does this happen even with Sack?
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On April 22, 2015 10:36:11 AM David Lang da...@lang.hm wrote:
Data that's received and not used doesn't really matter (a tree falls in the
woods type of thing).
The head of line blocking can
I would explain it a bit differently to David. There are a lot of
interrelated components and concepts in TCP, and its sometimes hard to see
which ones are relevant in a given situation.
The key insight though is that there are two windows which are maintained
by the sender and receiver
On Tue, Apr 21, 2015 at 05:35:32PM +1000, jb wrote:
And I can't offer an option, because the server receive window (I think)
cannot be set on a case by case basis. You set it for all TCP and forget it.
You can set both send and receive buffers using a setsockopt() call
(SO_SNDBUF, SO_RCVBUF). I
On Tue, 21 Apr 2015, jb wrote:
the receiver advertizes a large receive window, so the sender doesn't
pause until there is that much data outstanding, or they get a timeout of
a packet as a signal to slow down.
and because you have a gig-E link locally, your machine generates traffic
\
On Tue, 21 Apr 2015, David Lang wrote:
I suspect you guys are going to say the server should be left with a large
max receive window.. and let people complain to find out what their issue
is.
what is your customer base? how important is it to provide faster service to
teh fiber users? Are
If you set the window only a little bit larger than the actual BDP of the
link then there will only be a little bit of data to fill buffer, so given
large buffers it will take many connections to overflow the buffer.
Simon
Sent with AquaMail for Android
http://www.aqua-mail.com
On April 21,
That makes sense. Ok.
On Wed, Apr 22, 2015 at 12:14 PM, Simon Barber si...@superduper.net wrote:
If you set the window only a little bit larger than the actual BDP of
the link then there will only be a little bit of data to fill buffer, so
given large buffers it will take many connections
On Wed, 2015-04-22 at 06:04 +0200, Steinar H. Gunderson wrote:
On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive.
I haven't
On Tue, Apr 21, 2015 at 08:35:21PM +1000, jb wrote:
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive.
I haven't gone into the code and checked, but from practical experience I
On Tue, Apr 21, 2015 at 3:13 PM, jb jus...@dslr.net wrote:
Today I've switched it back to large receive window max.
The customer base is everything from GPRS to gigabit. But I know from
experience that if a test doesn't flatten someones gigabit connection they
will immediately assume oh
Regarding the low TCP RWIN max setting, and smoothness.
One remark up-thread still bothers me. It was pointed out (and it makes
sense to me) that if you set a low TCP max rwin it is per stream, but if
you do multiple streams you are still going to rush the soho buffer.
However my observation
As I understand it (I thought) SO_SNDBUF and SO_RCVBUF are socket buffers
for the application layer, they do not change the TCP window size either
send or receive. Which is perhaps why they aren't used much. They don't do
much good in iperf that's for sure! Might be wrong, but I agree with the
One thing users understand is slow web access. Perhaps translating the
latency measurement into 'a typical web page will take X seconds longer to
load', or even stating the impact as 'this latency causes a typical web
page to load slower, as if your connection was only YY% of the measured
I've discovered something perhaps you guys can explain it better or shed
some light.
It isn't specifically to do with buffer bloat but it is to do with TCP
tuning.
Attached is two pictures of my upload to New York speed test server with 1
stream.
It doesn't make any difference if it is 1 stream
Whoops I better set that z-index correctly thanks.
It is interesting you mentioned gaming because 10 of the servers are from a
place that rents clan servers. They have to be in top quality data centres
and not congest anything because their customers abandon them immediately
and they're always
1) I have 7 dual stack linode vm servers around the world you could
use - they are in england, japan, newark, atlanta, california, and one
other place. They are configured to use sch_fq (but I don't know what
is on the bare metal), and have other analysis tools on them, but you
would be welcome to
IPv6 is now available as an option, you just select it in the preferences
pane.
Unfortunately only one of the test servers (in Michigan) is native dual
stack so the test is then fixed to that location. In addition the latency
pinging during test is stays as ipv4 traffic, until I setup a web
/320230 (and now you see my pathetic link)
David Lang
On Sun, 19 Apr 2015, jb wrote:
Date: Sun, 19 Apr 2015 15:26:51 +1000
From: jb jus...@dslr.net
To: Dave Taht dave.t...@gmail.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built
jb jus...@dslr.net writes:
The graph below the upload and download is what is new. (unfortunately
you do have to be logged into the site to see this) it shows the
latency during the upload and download, color coded. (see attached
image).
So where is that graph? I only see the regular up- and
On Sun, Apr 19, 2015 at 9:57 AM, Rich Brown richb.hano...@gmail.com wrote:
Folks,
I am delighted to pass along the news that Justin has added latency
measurements into the Speed Test at DSLReports.com.
Go to: https://www.dslreports.com/speedtest and click the button for your
Internet
Hi Justin,
On Apr 19, 2015, at 07:26 , jb jus...@dslr.net wrote:
The graph below the upload and download is what is new.
(unfortunately you do have to be logged into the site to see this)
it shows the latency during the upload and download, color coded. (see
attached image).
This
On 19 Apr, 2015, at 13:20, Sebastian Moeller moell...@gmx.de wrote:
Reporting the latency under load as frequency (inverse of delay time) would
be nice in that higher numbers denote a better” link, but has the issue that
it is going to be hard to quickly add different latency
Oh my apologies, I see from your log you are using firefox+linux.
To cut a long story short, the measurement of latency while the test is
running is suppressed for firefox+linux because originally it was
associated with a graphics gauge, and firefox has terrible canvas
performance on linux.
jb jus...@dslr.net writes:
Oh my apologies, I see from your log you are using firefox+linux.
Nope, chromium. The first of the two links is mine. The other one I
pasted from one of the previous mails on the list; and that *does* show
the under-load latency measurements.
-Toke
: Re: [Bloat] DSLReports Speed Test has latency measurement built-in
The graph below the upload and download is what is new.(unfortunately you do
have to be logged into the site to see this)it shows the latency during the
upload and download, color coded. (see attached image).
In your case
This test was taken on linux, about 20 feet and one room away from the
access point:
http://www.dslreports.com/speedtest/320328
This was taken on the same box, about 10 feet and one room from the
access point.
http://www.dslreports.com/speedtest/320340
In all cases, the uplink is a comcast box
Apr 2015 15:26:51 +1000
From: jb jus...@dslr.net
To: Dave Taht dave.t...@gmail.com, bloat@lists.bufferbloat.net
Subject: Re: [Bloat] DSLReports Speed Test has latency measurement built-in
The graph below the upload and download is what is new.
(unfortunately you do have to be logged into the site
On Sun, 19 Apr 2015, jb wrote:
Hey there is nothing wrong with Megapath ! they were my second ISP after
Northpoint went bust.
If I had a time machine, and went back to 2001, I'd be very happy with
Megapath.. :)
nothing's wrong with megapath, just with the phone lines in the area limiting
Sorry its midnight here and I've got to that stage where my mistake ratio
rises above 50%. In the log it says 0.81s Forcing lo-fi mode due to slow
CPU
which actually meant no animated graphs because platform is _linux_
(forget Firefox), as often linux has a tenuous connection between gpu and
This was a test taken *during* a 2 minute rrul_be test.
http://www.dslreports.com/speedtest/320377
Flient (formerly netperf-wrapper) data here:
http://snapon.lab.bufferbloat.net/~d/lorna-wifi.tgz
Puzzle over this!
http://snapon.lab.bufferbloat.net/~d/lorna-wifi/reconcile_this.png and
the rawer
1 - 100 of 124 matches
Mail list logo
