| |||||||||||||
Quotes of the weekQuotes of the weekPosted Dec 13, 2012 20:31 UTC (Thu) by intgr (subscriber, #39733)In reply to: Quotes of the week by BenHutchings Parent article: Quotes of the week
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.
(Log in to post comments)
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.
|
|||||||||||||