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"
said:
>
>> On 4 Dec, 2016, at 10:25, Matt Taggart 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@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>
___
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel
