On Sun, 4 Dec 2016 14:41:05 -0500 (EST) [email protected] wrote: > The language used in the article seems confused. However, since firmware > sometimes means software (the OS kernel, for example) and this is "lag under > load", it's barely possible that this is bufferbloat of a sort, it seems. > Would we be surprised? > > 200 ms. can also be due to interrupt mishandling, recovered by a watchdog. > It's common for performance to reduce interrupt overhead by switching from > interrupt driven to polled while packets are arriving at full rate and then > back again when the traffic has a gap. If you don't turn interrupts back on > correctly (there's a race between turning on interrupts and packet arrival > after you decide and before you succeed in turning on interrupts), then you > end up waiting for some "watchdog" (every 200 ms?) to handle the incoming > packets. > > The idea that something actually runs for 200 ms. blocking everything seems > to be the least likely situation - of course someone might have written code > that held a lock while waiting for something or masked interrupts while > waiting for something. But actually executing code for 200 ms.? Probably not.
I have some recent experience with this hw. At my new location, the ISP provided modem was a Hitron CGNv4 which earned an F on bufferbloat. New hardware is Arris Surboard SB6190 and Linksys AC3200 which now gets all A's for bandwith, latency, and bufferbloat. The wireless is also much better. _______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
