Quotes of the week [LWN.net]

Quotes of the week

Posted Dec 13, 2012 16:22 UTC (Thu) by BenHutchings (subscriber, #37955)
Parent article: Quotes of the week

Modern network hardware has often sprouted various "offload" engines, unfortunately now often enabled by default, ... Start by turning them off.

Yes, I really hate the bloat introduced by checksum offload, what a terrible idea that was! Seriously, I suspect the writer is mostly thinking of TSO, which is supported and enabled on most Ethernet hardware but only applied as requested by the kernel. It is up to the TCP implementation, not the hardware, to decide how it is used. (Some hardware (particularly 10G) also has LRO, and that does introduce buffering in hardware outside of the kernel's control.)

The implementors of this "smart" hardware are less "smart" than they think they are.

The writer of this document is less helpful than he thinks he is.

(Log in to post comments)

Quotes of the week

Posted Dec 13, 2012 20:31 UTC (Thu) by intgr (subscriber, #39733) [Link]

Agreed. Bufferbloat might be an important problem, but it really bothers me how the bufferbloat crowd seems to think it's the only problem that needs to be solved in computing.

By reducing buffering, you make the CPU wake up more frequently, thus consume more power. By disabling TSO, you make the CPU do more work to transmit the same amount of data.

They should be looking for the sweet spot between power efficiency, CPU load and latency, but I have never seen that kind of thinking in any of their public communication.

I also haven't seen any reasoning for why they're dismissing delay-based congestion control algorithms like TCP Vegas, which can inherently detect bufferbloat and scale back before filling the buffers.

Quotes of the week

Posted Dec 13, 2012 22:37 UTC (Thu) by samlh (subscriber, #56788) [Link]

> They should be looking for the sweet spot between power efficiency, CPU load and latency, but I have never seen that kind of thinking in any of their public communication.

All of the benchmarks I have seen from them validating various techniques also measure bandwidth as well. While they are focused on one particular problem, I feel they do care about not breaking things in the process.

> I also haven't seen any reasoning for why they're dismissing delay-based congestion control algorithms like TCP Vegas, which can inherently detect bufferbloat and scale back before filling the buffers.

That only works if every stream is using Vegas - otherwise, the Vegas streams will be penalized against the other streams. For inherently background stuff, this is ok; indeed, uTP for bittorrent works on this principle. However, for everything else it is not a viable option.