[Cerowrt-devel] Intel latency issue

[Cerowrt-devel] Intel latency issue

[Matt Taggart]

http://www.theregister.co.uk/2016/12/03/intel_puma_chipset_firmware_fix/

"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."

-- 
Matt Taggart
matt@lackof.org

Re: [Cerowrt-devel] Intel latency issue

[Jonathan Morton]

> On 4 Dec, 2016, at 10:25, Matt Taggart <matt@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

Re: [Cerowrt-devel] Intel latency issue

[dpreed]

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@gmail.com> said:

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

Re: [Cerowrt-devel] Intel latency issue

[Stephen Hemminger]

On Sun, 4 Dec 2016 14:41:05 -0500 (EST)
dpreed@reed.com 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. 

Re: [Cerowrt-devel] Intel latency issue

[Mikael Abrahamsson]

On Mon, 5 Dec 2016, Stephen Hemminger wrote:

> 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.

The Arris Surfboard SB6190 is listed as affected in that article.

PUMA6 has a network packet processor in it. I doubt the problem is with 
the Atom processor itself. Flows are offloaded onto the packet processor 
and most of the packets are never seen by the host CPU in normal 
operation.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se