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 simult
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 wrote:
> Netalyzr is great for network geeks, hardly consumer-friendly, and even so
> the "network buffer measurements" part is buried in 150 other statistics.
The b
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 meas
Hi David,
On Mar 20, 2015, at 14:31 , David P. Reed 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 giving a bas
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" wrote:
>
> >On Thu, Mar 19, 2015 at 6:53 AM, wrote:
> >> How many years has it been since Comcast said they were going to fix
> >>bufferbloat in their network within
On Mar 19, 2015, at 7:18 PM, 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 simultaneous "ping" test to their throughput
> test? When was the la
>*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 influe
I don't know.
From my personal experience, I feel like the "expert" wearing ties
watch the speed meter and the needle moving across the red bar.
We just need to be sure about the colors: when the latency goes into the
crazy region
the needle has to cross a RED bar! GREEN is good, RED is bad (exc
SamKnows is carefully constructed politically to claim that everyone has great
service and no problems are detected. They were constructed by opponents of
government supervision - the corporate FCC lobby.
Don't believe they have any incentive to measure customer relevant measures
M-Lab is bette
On 3/20/15, 9:48 AM, "Jim Gettys"
mailto: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 intervened: buggy i
FYI, we have this in France.
http://www.arcep.fr/index.php?id=8571&tx_gsactualite_pi1[uid]=1701&tx_gsactualite_pi1[annee]=&tx_gsactualite_pi1[theme]=&tx_gsactualite_pi1[motscle]=&tx_gsactualite_pi1[backID]=26&cHash=f558832b5af1b8e505a77860f9d555f5&L=1
ARCEP is the equivalent of FCC in France.
U
Section 7.2 of
https://tools.ietf.org/html/draft-ietf-ippm-model-based-metrics-04 includes
a bufferbloat test. It is however somewhat underspecified.
Thanks,
--MM--
The best way to predict the future is to create it. - Alan Kay
Privacy matters! We know from recent events that people are using
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
On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl 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 to believe
Sent from my iPhone
> On 20. mars 2015, at 16:31, Jim Gettys wrote:
>
>
>
>> On Fri, Mar 20, 2015 at 10:54 AM, Michael Welzl 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 hav
> On 20 Mar, 2015, at 16:54, Michael Welzl 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 delay exceeds t
> On 20 Mar, 2015, at 16:11, Livingood, Jason
> wrote:
>
>> Even when you get to engineers in the organizations who build the equipment,
>> it's hard. First you have to explain that "more is not better", and "some
>> packet loss is good for you".
>
> That’s right, Jim. The “some packet loss
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 und
> On 20 Mar, 2015, at 22:08, Bill Ver Steeg (versteb) 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 I’ve fl
> On 20. mar. 2015, at 17.31, Jonathan Morton wrote:
>
>
>> On 20 Mar, 2015, at 16:54, Michael Welzl 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 t
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
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 encountered a
lost frame. That is: the dropped or marked packets are not ha
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl 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 w
> On 21. mar. 2015, at 00.47, David P. Reed 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 encountered
>
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 pac
> On 21. mar. 2015, at 01.03, David Lang wrote:
>
> On Fri, 20 Mar 2015, Michael Welzl wrote:
>
>>> On 20. mar. 2015, at 17.31, Jonathan Morton wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl wrote:
I'd like people to understand that packet loss often also comes with delay
- f
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 limi
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 advantag
On Sat, 21 Mar 2015, Michael Welzl wrote:
On 21. mar. 2015, at 01.03, David Lang wrote:
On Fri, 20 Mar 2015, Michael Welzl wrote:
On 20. mar. 2015, at 17.31, Jonathan Morton wrote:
On 20 Mar, 2015, at 16:54, Michael Welzl wrote:
I'd like people to understand that packet loss often also co
> On 21 Mar, 2015, at 02:25, David Lang 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: if you
On Sat, 21 Mar 2015, Jonathan Morton wrote:
On 21 Mar, 2015, at 02:25, David Lang 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 ad
> On 21 Mar, 2015, at 02:38, David Lang wrote:
>
> On Sat, 21 Mar 2015, Jonathan Morton wrote:
>
>>> On 21 Mar, 2015, at 02:25, David Lang wrote:
>>>
>>> As I said, there are two possibilities
>>>
>>> 1. if you mark packets sooner than you would drop them, advantage non-ECN
>>>
>>> 2. if yo
32 matches
Mail list logo
