I agree. Having that ping included in Ookla would help a lot more
Luca
On 03/20/2015 12:18 AM, Greg White wrote:
Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the network buffer measurements part is buried in 150 other statistics.
Why couldn't Ookla* add a
Hi All,
I guess I have nothing to say that most of you don’t know already, but...
On Mar 20, 2015, at 00:18 , Greg White g.wh...@cablelabs.com wrote:
Netalyzr is great for network geeks, hardly consumer-friendly, and even so
the network buffer measurements part is buried in 150 other
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.
Or,
On 21. mar. 2015, at 01.03, David Lang da...@lang.hm wrote:
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss
On Sat, 21 Mar 2015, Jonathan Morton wrote:
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm wrote:
As I said, there are two possibilities
1. if you mark packets sooner than you would drop them, advantage non-ECN
2. if you mark packets and don't drop them until higher levels, advantage
On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:
1. If you mark packets as congested if they have ECN and drop them
if they don't, programmers will mark everything ECN (and not slow
transmission) because doing so gives them an advantage over
applications that don't mark their
On Sat, 21 Mar 2015, Steinar H. Gunderson wrote:
On Fri, Mar 20, 2015 at 05:03:16PM -0700, David Lang wrote:
1. If you mark packets as congested if they have ECN and drop them
if they don't, programmers will mark everything ECN (and not slow
transmission) because doing so gives them an
On 21. mar. 2015, at 00.47, David P. Reed dpr...@reed.com wrote:
I think this is because there are a lot of packets in flight from end to end
meaning that the window is wide open and has way overshot the mark. This can
happen if the receiving end keeps opening it's window and has not
Drag is an fluid dynamic term that suggests a meaning close to this... flow
rate dependent friction.
But what you really want to suggest is a flow rate dependent *delay* that
people are familiar with quantifying.
Fq_codel limits the delay as flow rate increases and is fair.
The max buffer
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm wrote:
As I said, there are two possibilities
1. if you mark packets sooner than you would drop them, advantage non-ECN
2. if you mark packets and don't drop them until higher levels, advantage
ECN, and big advantage to fake ECN
3:
On 21 Mar, 2015, at 02:38, David Lang da...@lang.hm wrote:
On Sat, 21 Mar 2015, Jonathan Morton wrote:
On 21 Mar, 2015, at 02:25, David Lang da...@lang.hm wrote:
As I said, there are two possibilities
1. if you mark packets sooner than you would drop them, advantage non-ECN
2. if
FYI, we have this in France.
http://www.arcep.fr/index.php?id=8571tx_gsactualite_pi1[uid]=1701tx_gsactualite_pi1[annee]=tx_gsactualite_pi1[theme]=tx_gsactualite_pi1[motscle]=tx_gsactualite_pi1[backID]=26cHash=f558832b5af1b8e505a77860f9d555f5L=1
ARCEP is the equivalent of FCC in France.
User
*I realize not everyone likes the Ookla tool, but it is popular and about
as sexy as you are going to get with a network performance tool.
Ookla has recently been acquired by Ziff-Davis
(http://finance.yahoo.com/news/ziff-davis-acquires-ookla-120100454.html).
I am not sure have that may influence
The mystery in most users' minds is that ping at a time when there is no load
does tell them anything at all about why the network connection will such when
their kid is uploading to youtube.
So giving them ping time is meaningless.
I think most network engineers think ping time is a useful
On Thu, Mar 19, 2015 at 3:58 PM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
On 3/19/15, 1:11 PM, Dave Taht dave.t...@gmail.com wrote:
On Thu, Mar 19, 2015 at 6:53 AM, dpr...@reed.com wrote:
How many years has it been since Comcast said they were going to fix
bufferbloat in
On 3/20/15, 9:48 AM, Jim Gettys
j...@freedesktop.orgmailto:j...@freedesktop.org wrote:
I think this was the hope that the buffer size control feature in Docsis could
at least be used to cut bufferbloat down to the traditional 100ms level, as I
remember the sequence of events. But reality
Hi David,
On Mar 20, 2015, at 14:31 , David P. Reed dpr...@reed.com wrote:
The mystery in most users' minds is that ping at a time when there is no load
does tell them anything at all about why the network connection will such
when their kid is uploading to youtube.
But it does, by
Folks,
I think I have just seen this statement a little too often:
That’s right, Jim. The “some packet loss is good” part is from what I have
seen the hardest thing for people to understand. People have been trained to
believe that any packet loss is terrible (..)
I understand the wrong
Sent from my iPhone
On 20. mars 2015, at 16:31, Jim Gettys j...@freedesktop.org wrote:
On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl mich...@ifi.uio.no wrote:
Folks,
I think I have just seen this statement a little too often:
That’s right, Jim. The “some packet loss is good”
On 20. mar. 2015, at 17.31, Jonathan Morton chromati...@gmail.com wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.
Or, turning it upside down, it’s always
I was kidding about sucks-less, and forgot the smiley in my initial note.
We do need a metric with an end-user-friendly name, though. Most people
understand lag, and understand that lower numbers are better. You could
probably explain lag-while-loaded to most users (particularly people who
On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl mich...@ifi.uio.no wrote:
Folks,
I think I have just seen this statement a little too often:
That’s right, Jim. The “some packet loss is good” part is from what I
have seen the hardest thing for people to understand. People have been
trained
On 20 Mar, 2015, at 16:54, Michael Welzl mich...@ifi.uio.no wrote:
I'd like people to understand that packet loss often also comes with delay -
for having to retransmit.
Or, turning it upside down, it’s always a win to drop packets (in the service
of signalling congestion) if the induced
On 20 Mar, 2015, at 22:08, Bill Ver Steeg (versteb) vers...@cisco.com wrote:
We should call the metric sucks-less. As in Box A sucks less than Box B,
or Box C scored a 17 on the sucks less test.
I suspect real marketing drones would get nervous at a negative-sounding name.
My idea - which
We should call the metric sucks-less. As in Box A sucks less than Box B, or
Box C scored a 17 on the sucks less test.
The actual measurement would be the number of milliseconds of additional
queueing delay when the system is congested, but most people will not take the
time to look under
25 matches
Mail list logo
