Re: [Bloat] fixing netem to be more useful

[Emmanuel Lochin <emmanuel.lochin@isae.fr>]

Another issue, I think, is the way burst of lost packets are computed. The scheme implemented is not a two state Markov chain that would allow to set an average burst size and I failed to find an explanation concerning this point.
If somebody has information ...

Emmanuel

--
Emmanuel Lochin 
Professeur ISAE - OSSI 
Institut Supérieur de l'Aéronautique et de l'Espace (ISAE) 
Issu du rapprochement SUPAERO et ENSICA 
10 avenue Edouard Belin - BP 54032 - 31055 Toulouse cedex 4 
Tel : 05 61 33 91 85 - Fax : 05 61 33 91 88 
Web : http://personnel.isae.fr/emmanuel-lochin/ 
--- 
"This email and any attachments are confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed" Le 25 mars 2015 18:32, Dave Taht <dave.taht@gmail.com> a écrit :
>
> On of my big issues with netem (a network emulator for linux that lets
> you do delay, loss, etc) is that there is no way to setup multiple RTT
> emulations without having a separate maximum number of packets limit
> for each, which can really skew the results. I would like to see a
> netem that had a multi-queue implementation with a shared limit, among
> other things.
>
> Is there anyone working on making netem better? is there someone
> willing to work on it that someone could fund?
>
> This comment arose from the code facebook for their shaper implementation here:
>
> https://github.com/facebook/augmented-traffic-control/tree/master/atc/atcd#shaping-packets
>
> and the comments on this bug:
>
> https://github.com/facebook/augmented-traffic-control/issues/60
>
> -- 
> Dave Täht
> Let's make wifi fast, less jittery and reliable again!
>
> https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
> _______________________________________________
> Bloat-devel mailing list
> Bloat-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat-devel