[Cerowrt-devel] Intel latency issue

[dpreed at reed.com]

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.






On Sunday, December 4, 2016 3:27am, "Jonathan Morton" <chromatix99 at gmail.com> said:

> 
>> On 4 Dec, 2016, at 10:25, Matt Taggart <matt at lackof.org> wrote:
>>
>> "Modems powered by Intel's Puma 6 chipset that suffer from bursts of
>> game-killing latency include the Arris Surfboard SB6190, the Hitron
>> CGNV4, and the Compal CH7465-LG, and Puma 6-based modems rebadged by
>> ISPs, such as Virgin Media's Superhub 3 and Comcast's top-end Xfinity
>> boxes. There are other brands, such as Linksys and Cisco, that use the
>> system-on-chip that may also be affected."
> 
> I do have to ask: the Atom isn’t very powerful, but WTF is it doing for
> 200ms every few seconds?
> 
>  - Jonathan Morton
> 
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>