- Joined
- Aug 20, 2007
- Messages
- 21,535 (3.40/day)
System Name | Pioneer |
---|---|
Processor | Ryzen R9 9950X |
Motherboard | GIGABYTE Aorus Elite X670 AX |
Cooling | Noctua NH-D15 + A whole lotta Sunon and Corsair Maglev blower fans... |
Memory | 64GB (4x 16GB) G.Skill Flare X5 @ DDR5-6000 CL30 |
Video Card(s) | XFX RX 7900 XTX Speedster Merc 310 |
Storage | Intel 905p Optane 960GB boot, +2x Crucial P5 Plus 2TB PCIe 4.0 NVMe SSDs |
Display(s) | 55" LG 55" B9 OLED 4K Display |
Case | Thermaltake Core X31 |
Audio Device(s) | TOSLINK->Schiit Modi MB->Asgard 2 DAC Amp->AKG Pro K712 Headphones or HDMI->B9 OLED |
Power Supply | FSP Hydro Ti Pro 850W |
Mouse | Logitech G305 Lightspeed Wireless |
Keyboard | WASD Code v3 with Cherry Green keyswitches + PBT DS keycaps |
Software | Gentoo Linux x64 / Windows 11 Enterprise IoT 2024 |
Sometimes as a news reporter, a story drops right into your lap. That was the case with me and my latest experience with my ISP rented modem, which I recently upgraded to support higher speeds.
The modem I got was based on the Puma 6 chipset, which is an Atom based chipset from Intel. I immediately noticed a more sluggish web experience, despite the bandwidth nearly doubling (going from 8 downstream pipes to 24 will do that). I began to google this issue, and came up with a much-underreported issue from a thread on dslreports.com where the dedicated members there have extensively documented the issues with the Puma 6 chipset, and Intel's apparent inability to patch them.
The issue appears to be Intel's insistence on doing on the data processing of the mathematical channel separation (Full Spectrum Frequency Capture, which this modem utilizes, is a very mathematically intense operation) on a weak Atom CPU. The CPU bogs down under load, resulting in frequent latency spikes up to 250ms (that's like going around the globe twice, for reference). Intel for its part has put out firmware patches, but two fixes later and they are apparently unable to correct this issue beyond making ICMP work. TCP/UDP is still a mess, and guess what? That's what everyone uses.
One would hope they are still looking at firmware fixes, but the situation seems dire. There is talk of class-action lawsuits brewing all over the dslreports.com forums, and this does not seem to be idle chatter given the fact that a major modem manufacturer, Arris, has invested heavily in this chipset (Arris for its part, has already filed a lawsuit).
This chipset is a very widely used chipset in cable modems, so if you've been noticing latency in your connection, you'd best test if it uses the Puma 6 chipset. Ironically, the best way to test it is via a performance test cooked up at dslreports.com: It's performance is so consistently bad you can actually detect the chipset via its performance metrics. It is worth noting, nearly all >8 downstream pipe modems rented from comcast with voice function (something they push heavily), and many even without the voice function include the Puma 6 chipset.
As for my personal experience, I exchanged for a customer owned-modem: A Netgear CM600 (Broadcom Chipset). About darn time.
See the test at this link, and stay tuned for more on this developing story. Your local TPU-newsposter is on it.
UPDATE: It would seem the atom-core is not the issue, as the arm core does the packet processing as some users pointed out. Regardless, the chipset as a whole appears to be faulty, and it is all Intel IP.
http://www.dslreports.com/tools/puma6
View at TechPowerUp Main Site
The modem I got was based on the Puma 6 chipset, which is an Atom based chipset from Intel. I immediately noticed a more sluggish web experience, despite the bandwidth nearly doubling (going from 8 downstream pipes to 24 will do that). I began to google this issue, and came up with a much-underreported issue from a thread on dslreports.com where the dedicated members there have extensively documented the issues with the Puma 6 chipset, and Intel's apparent inability to patch them.
The issue appears to be Intel's insistence on doing on the data processing of the mathematical channel separation (Full Spectrum Frequency Capture, which this modem utilizes, is a very mathematically intense operation) on a weak Atom CPU. The CPU bogs down under load, resulting in frequent latency spikes up to 250ms (that's like going around the globe twice, for reference). Intel for its part has put out firmware patches, but two fixes later and they are apparently unable to correct this issue beyond making ICMP work. TCP/UDP is still a mess, and guess what? That's what everyone uses.
One would hope they are still looking at firmware fixes, but the situation seems dire. There is talk of class-action lawsuits brewing all over the dslreports.com forums, and this does not seem to be idle chatter given the fact that a major modem manufacturer, Arris, has invested heavily in this chipset (Arris for its part, has already filed a lawsuit).
This chipset is a very widely used chipset in cable modems, so if you've been noticing latency in your connection, you'd best test if it uses the Puma 6 chipset. Ironically, the best way to test it is via a performance test cooked up at dslreports.com: It's performance is so consistently bad you can actually detect the chipset via its performance metrics. It is worth noting, nearly all >8 downstream pipe modems rented from comcast with voice function (something they push heavily), and many even without the voice function include the Puma 6 chipset.
As for my personal experience, I exchanged for a customer owned-modem: A Netgear CM600 (Broadcom Chipset). About darn time.
See the test at this link, and stay tuned for more on this developing story. Your local TPU-newsposter is on it.
UPDATE: It would seem the atom-core is not the issue, as the arm core does the packet processing as some users pointed out. Regardless, the chipset as a whole appears to be faulty, and it is all Intel IP.
http://www.dslreports.com/tools/puma6
View at TechPowerUp Main Site
Last edited: