[Bloat] Check out www.speedof.me - no Flash

[Sebastian Moeller]

Hi Neil,


On Jul 25, 2014, at 16:27 , Neil Davies <neil.davies at pnsol.com> wrote:

> Sebastian
> 
> On 25 Jul 2014, at 15:17, Sebastian Moeller <moeller0 at gmx.de> wrote:
> 
>> 	But how do you propose to measure the (bottleneck) link capacity then? It turns out for current CPE and CMTS/DSLAM equipment one typically can not relay on good QoE out of the box, since typically these devices do not use their (largish) buffers wisely. Instead the current remedy is to take back control over the bottleneck link by shaping the actually sent traffic to stay below the hardware link capacity thereby avoiding feeling the consequences of the over-buffering. But to do this is is quite helpful to get an educated guess what the bottleneck links capacity actually is. And for that purpose a speediest seems useful.
> 
> 
> I totally agree that what you are trying to do is to take control "back" for the upstream delay and loss (which is the network level activity that directly influences QoE). Observationally the "constraining link" is the point at which the delay and loss start to grow as the the offered load is increased (there are interesting interactions with the scheduling in the CMTS/3GPP node B - but they are tractable) if we don't have direct access to the constraint (which in the CPE, for ADSL you have) we track that "quality attenuation" inflection point. Saturating the path is a bit of a sledgehammer (and has nasty cost/scaling implications).

	What else can I do to make sure that my network still works satisfactory in the “worst case” than to test and tune it for the worst case? Also, coming from a biology background, I like systems that operate well in the capacity limited state ;)

> 
> I see, as I was replying, Martin has sent you some links to the background.

	Interesting read, do you have a pointer on how to calculate deltaQ though?

best regards
	Sebastian

> 
> Cheers
> 
> Neil