| |||||||||||||
Hardware supportHardware supportPosted Sep 14, 2011 17:19 UTC (Wed) by dmarti (subscriber, #11625)In reply to: Power impact of debufferbloating by russell Parent article: LPC: An update on bufferbloat
Yes, it would be a win to have hardware that can timestamp packets going into its buffers and drop "stale" ones on the way out instead of transmitting them. (relevant thread on timestamps from the bufferbloat list). Right now, hardware assumes that late is better than never, and TCP would prefer never over too late.
(Log in to post comments)
Hardware support Posted Sep 15, 2011 7:58 UTC (Thu) by johill (subscriber, #25196) [Link]
I'm pretty sure that's possible with a bunch of wireless devices, but I don't know how the timestamps are checked etc. off the top of my head.
Hardware support Posted Sep 15, 2011 16:06 UTC (Thu) by dmarti (subscriber, #11625) [Link] That would be useful to see. It looks like the problem of bufferbloat is that packets stay in the buffer until they get stale -- so checking staleness directly, ideally without having to involve the CPU, could be a way to save having to tune the buffer size. (If you run the café in Grand Central Station, you need to bake a bigger "buffer" of muffins than the low-traffic neighborhood place does. But customers at the two places should get the same muffin freshness as long as both have the same policy of dropping day-old muffins.)
|
|||||||||||||