search for: bufferbloat

...ound a packaged solution and I'm wondering what others do to configure this kind of thing. Apparently the new modules are available in many appliance router products (eg. OpenWrt and Streamboost). Perhaps someone here knows of an RPM that wraps this up for RH-based distros? <https://www.bufferbloat.net/projects/cerowrt/wiki/Smart_Queue_Management/> Here's an article arguing why Wondershaper was great in its day but is now bad for modern traffic flows. <https://www.bufferbloat.net/projects/bloat/wiki/Wondershaper_Must_Die/>

Hi all, What is Bufferbloat? http://gettys.wordpress.com/bufferbloat-faq/ Maybe this kind of discussion will bring out the John Todds of this world, I can only hope and dream: Bufferbloat: http://www.voipusersconference.org/2011/bufferbloat/ Call in and talk to Jim Gettys, who co-developed X Window System and was a part of...

I came across this on the Fedora devel list. I added /etc/sysctl.d/51-bufferbloat.conf containing the suggested line and it installs the new codel qdisc as desired. There's probably more knobs that might be useful to tweak but this makes a good start. More reading on the bufferbloat site suggests that the later "cake" module will be even better, but it requires...

On 15/12/17 07:05, Kenneth Porter wrote: > I came across this on the Fedora devel list. I added > /etc/sysctl.d/51-bufferbloat.conf containing the suggested line and it > installs the new codel qdisc as desired. There's probably more knobs > that might be useful to tweak but this makes a good start. More reading > on the bufferbloat site suggests that the later "cake" module will be > even better,...

...otify GRO that it should start dropping packets > > of this flow. > > > > What do you think? > > > > I think we disagree a lot on memory management on networking stacks. > > We did a lot of work in TCP stack and Qdisc layers to lower memory > pressure (and bufferbloat), an you seem to try hard to introduce yet > another layer of buffer bloat in virtio_net. > > So add whatever you want to proudly state to your management : > > "Look how smart we are : we drop no packets in our layer" > Hmm some kind of disconnect here. I got you rm...

...otify GRO that it should start dropping packets > > of this flow. > > > > What do you think? > > > > I think we disagree a lot on memory management on networking stacks. > > We did a lot of work in TCP stack and Qdisc layers to lower memory > pressure (and bufferbloat), an you seem to try hard to introduce yet > another layer of buffer bloat in virtio_net. > > So add whatever you want to proudly state to your management : > > "Look how smart we are : we drop no packets in our layer" > Hmm some kind of disconnect here. I got you rm...

...ork also, but: A) encapsulation of ecn capable marked packets, and availability in the outer header, without correct decapsulationm doesn't work well. The outer packet gets marked, but by default the marking doesn't make it back into the inner packet when decoded. see: http://snapon.lab.bufferbloat.net/~d/tinc/ecn.png # packets get marked but not decapsulated - and never dropped so they just keep accumulating delay over this path.... vs http://snapon.lab.bufferbloat.net/~d/tinc/noecn.png So communicating somehow that a path can take ecn (and/or diffserv markings) is needed between tinc dae...

...msg part? >> >> Not my call. It is a linux only thing, so far as I know. > > ATM yes. I wouldn't be surprised that other OSes adopt it, though. Given how slow other OSes are evolving, I would not hold my breath, and retain code paths that worked with them. [1] https://lists.bufferbloat.net/pipermail/cake/2015-November/000846.html [2] http://www.bufferbloat.net/projects/codel/wiki/CakeTechnical [3] http://netoptimizer.blogspot.se/2014/10/unlocked-10gbps-tx-wirespeed-smallest.html

...kind of bad, because all of the separate encapsulated flows sharing the singular TCP/IP link will suffer (ECN would help here). This situation is rather unfortunate as the good active queue management algorithms drop packets (when ECN is not available). A better summary of tor's flow control/bufferbloat woes is given in: DefenestraTor: Throwing out Windows in Tor http://www.cypherpunks.ca/~iang/pubs/defenestrator.pdf The N23 algorithm suggested in the paper did not end up getting implemented into Tor, but I do not remember the reason off the top of my head." > > > > On D...

On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote: > On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote: > > > Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a > > it didn't drop packets received from host as far as I can tell. > > virtio is more like a pipe than a real NIC in this respect. > > Prior/after to this patch,

On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote: > On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote: > > > Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a > > it didn't drop packets received from host as far as I can tell. > > virtio is more like a pipe than a real NIC in this respect. > > Prior/after to this patch,

Dave Taht, on Wed 02 Dec 2015 14:13:27 +0100, wrote: > More recently Tom Herbert was working on udp encapsulation methods in > the kernel "foo over udp" > > https://www.netdev01.org/docs/herbert-UDP-Encapsulation-Linux.pdf > > https://lwn.net/Articles/614348/ > > which preserve things important at high rates like GRO/GSO. Yes, FOU will probably get the highest

...es not, unless you have admin privs. Don't know about other OSes. The comment there: tos = origpkt->tos & ~0x3 ; // chicken out on passing ecn for now was due to seeing this happen otherwise (talking to a tinc not yet modified to decapsulate ecn markings correctly) http://snapon.lab.bufferbloat.net/~d/tinc/ecn.png and was awaiting some thought on a truth table derived from the relevant rfc (which I think is slightly wrong, btw), and further thought on determining if ecn could be used on that path. certainly I could deploy a tinc modified to assume ecn was in use, (and may, shortly!) wi...

On Thu, Dec 26, 2013 at 02:00:58PM -0800, Eric Dumazet wrote: > On Thu, 2013-12-26 at 23:37 +0200, Michael S. Tsirkin wrote: > > > Interesting. But if we can't allocate a buffer how can we > > do network processing? > > How typical NIC drivers handle this case ? > > Answer : nothing special should happen, we drop incoming traffic, > and make sure the driver

On Thu, Dec 26, 2013 at 02:00:58PM -0800, Eric Dumazet wrote: > On Thu, 2013-12-26 at 23:37 +0200, Michael S. Tsirkin wrote: > > > Interesting. But if we can't allocate a buffer how can we > > do network processing? > > How typical NIC drivers handle this case ? > > Answer : nothing special should happen, we drop incoming traffic, > and make sure the driver

Dave Taht, on Wed 02 Dec 2015 14:41:35 +0100, wrote: > I guess my meta point is driven by my headaches. Getting per packet > processing to scale up past 100Mbit is hard without offloads even on > embedded hardware considered "high end". In my tests I was getting 800Mbps with common laptop Gb ethernet devices. > >> > At least for now we could commit the recvmmsg

...rack.com > > -- > Please use reply-all for most replies to avoid omitting the mailing list. > To unsubscribe or change options: > https://lists.samba.org/mailman/listinfo/rsync > Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html -- Dave T?ht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks

...y. Ideally, your system should send data upstream at a rate which never "bursts" up to, or above your link's sustained data transmission rate. You want the buffers in the "upstream" equipment to remain as empty as possible. For background reading on this, look up the "Bufferbloat" problem and project, and the "Linux ultimate traffic shaper" scripts. They may not be directly applicable to your problem but may explain some of what you are seeing.

On Wed, 2013-11-20 at 18:06 +0200, Michael S. Tsirkin wrote: > Hmm some kind of disconnect here. > I got you rmanagement about bufferbloat. > > What I am saying is that maybe we should drop packets more > aggressively: when we drop one packet of a flow, why not > drop everything that's queued and is for the same flow? I really hope your TCP flows use SACK ;) Please read the rfc 2018 introduction for details. If a p...

...diately > once GFP_ATOMIC allocations fail and repost the buffer to host, > and hope memory is available by the time we get the next interrupt. > But we wanted host to have visibility into the fact that > we are out of memory and packets are dropped, so we did not want to > repost. bufferbloat alert :) > If we don't repost how do we know memory is finally available? > We went for a timer based workqueue thing. > What do you suggest? In normal networking land, when a host A sends frames to host B, nothing prevents A to pause the traffic to B if B is dropping packets under...