Uncorrectables on ALL downstream channels. What could be the problem?

The game specifically is Fortnite. EpicGames definitely uses AWS for their servers.

Edit: With regard to the gaming during this period. I do believe I tried a few matches to see if the packet loss issue was remedied (of course, it wasn't).

Double Edit: I cannot believe I am just finding out about this upload packet loss problem between Cox and AWS

How have they not acknowledged that yet?

gjett1In regards to gaming on the AWS servers, in a nutshell, we were able to isolate the problem to the AWS 54.239 (and possibly 52.239) network.  We found that by pinging with a packet size somewhere between 128 bytes and 256 bytes and higher, the packet loss began at the AWS 54.239 (and possibly 52.239) network when the source IP address originated from the Cox network.  When the same test was run using a T-Mobile hotspot, there was no packet loss observed.  The same lack of packet loss was reported by someone else using a VPN over their Cox connection.  This suggests to me that there is a Quality of Service (QoS) issue with the handling of the larger packets by the 54.239 (and possibly 52.239) networks at AWS when the source IP originated on Cox.  When the user connects using a T-Mobile hotspot or even a VPN over their Cox connection, the AWS 54.239 (and possibly 52.239) network sees a source IP address other than Cox and there is no packet loss observed.   The gaming companies are paying AWS to host their gaming applications and therefore AWS should promptly respond to and address demonstrated concerns presented by those companies.  This type of issue would be addressed by a Tier 3 type group or higher at AWS.

Welcome to the internet without net neutrality. 

Problem being: this isn't the gaming companies problem. Epic Games has 10's of millions of customers with no problems. Is it not Cox's responsibility to ensure that their service is the best possible? (Especially since Fortnite is the largest game around right now)

gjett1

Cox isn't responsible for packet loss on the AWS 54.239 (and/or 52.239) networks.  To reiterate, based on the testing I outlined above, this appears to be a QoS issue within the AWS networks when the source IP address is from Cox.  Their 54.239 and 52.239 networks aren't the first AWS networks the packets reach once leaving the Cox network.  There is no packet loss observed between Cox and the first AWS network the packets reach. As an aside, it looks like Cox peers directly with AWS.

Would a defective modem not be ruled out by similar values being shown with the SB6190 on the same system? Is two bad modems more likely than a problem on Cox's end?

gjett1 I see your point.  I may have overlooked that detail you originally included.    I'm now going back to my original thought of that older surfboard having a better RF receiver (i.e. better sensitivity, selectivity, noise floor) or that older surfboard modem didn't run 256 QAM on the downstream channels (i.e. 64 QAM).  Regardless, it sounds like there is some work to be done by Cox.  What model of surfboard did the CM600 replace?

The CM600 is replacing a Motorola SB6121. Thanks for the input, Rob.

gjett1 Oh, I see now.  The Motorola SB6121 was only a 4x4 modem, while the Netgear CM600 is a 24x8 modem and the Arris SB6190 is a 32x8 modem.  In your case, you appear to have gone from 4 downstream channels to 16 downstream channels.  Your connection doesn't appear to be handling the new total of 16 downstream channels very well. 

I think you are correct when you stated that the issue now points at Cox side (facilities, cabling) after having tried 2 newer modems, both running 16 downstream channels, with the same result.  As an aside, I wonder if your SNRs are rather misleading because of the high downstream power levels.

All the best in getting Cox to resolve it quickly during the next visit.

Thank you for that insight! We are thinking in the same vein. I'll have the in-home tech that's coming tomorrow know that and see what he has to say about the issue.