@scratchieepants, your comments really point out the perplexing issue, streaming at 12,500 kb/s, and then being unable to stream later on. Yesterday was Sunday, which can see a much lower or higher load at the CMTS depending on what time you were streaming. It makes me wonder if some of these issues are caused by the CMTS load? Level II Tech Support would have access to the CMTS load data.
Out of curiosity, can you load an application called Core Temp, which shows the CPU core temps and the CPU core load in %. I'm curious as to what the difference in CPU core load happens to be between something like a 1500 kb/s stream versus a 12500 kb/s stream. Can you run Core Temp when you run a stream and let me know what the numbers look like. Core Temp can be found here:
https://www.alcpu.com/CoreTemp/
Are you a twitch partner? I understand that allows you to run higher upload rates.
Are you running the 4582 modem in Gateway mode with a direct connection to the modem or in Bridge mode with a router behind it?
One question that needs answering is whether or not Rogers peer directly with Twitch and if so, what the throughput rate, or, does Rogers peer with Torix, who then peers with Twitch. That might be part of the problem as well.
I absolutely understand the frustration. I'm not a twitch user or uploader, but, these complaints have been posted in the forum for months now and there doesn't seem to be any impetus to resolve the problem. I'd like to do more to help, but, as a site volunteer, REs don't have any system access or the knowledge to use it, even if we had system access.
Can you try one thing when you have time. Run a short test stream to youtube at a high rate, maybe at 12,500 kb/s if that works, then turn around and run a short test stream to twitch. I'd like to see what happens at 3kb/s and 6 kb/s. Then turn back around and run another stream to youtube, just to confirm that you're still in a time window where high rate streams will run. Its good to know that streaming to youtube can work, I'm just wondering what you will see with near simultaneous streams. Is twitch always a problem is the question that I'm wondering?
From what I understand, both twitch and youtube use RTMP for uploading. The fact that streaming to youtube can work very well blows my theory of modem protocol incompatibility out of the water. So, this points to some issue at the CMTS or beyond. It may be a path issue from your modem to the ingress server. Ergo the question on peering between Rogers and Twitch.
Just as a follow-up to this..
I've been streaming on Twitch everyday @ 6k with ~0.5% dropped frames on Twitch for about three weeks now. I didn't want to ruin it and speak too soon. Occasionally, I have seen the dropped frames jumps to 2-4% dropped frames (maybe once a week or less), and very rarely the dropped frames reaches absurd amounts (20%+) for a short amount of time (has only happened twice very briefly).
I still have no idea what fixed it (for the most part).
I talked to a technical support supervisor and they sent a technician out because they saw that my upstream channels were "degraded". When I asked the technician what he did, he told me that my upstream was failing the test on his mobile tester thing, and that he changed "all" the lines. I also installed wifi drivers around the same time (was advised to do so by another streamer on Rogers network), but I doubt that's what fixed it..
In any case, slight derail, but is it normal to see higher pings and spikes to my modem than the other Rogers hops? The last couple of servers are in Dallas, and yet the spikes are still higher.
My modem is a CGNM 3552, and I noticed this way before signing up for trial firmware. I've been having latency problems in TCP games since I've been with Rogers (I used to have the same issues on CGN2ROG).
Thanks
Just ran this myself to see what I would get on my CODA modem on the latest trial firmware.
@scratchieepants, personal opinion, your modem is fine. If you can stream at 12.5kb/s with next to nil losses, then the modem doesn't have an issue. It was interesting to see the switch from youtube to twitch. Beyond the CMTS you would have a different path to the ingress servers. Its possible that the same path is used beyond the CMTS, to some point before they branch off.
In any event, the fact that you can stream to youtube with OBS shows that the modem and CMTS can support streaming at higher rates. The question is, what happens beyond the CMTS?
Are you able to tell if OBS is using IPV6 at all? Looking online it would appear that OBS is IPV6 capable by now, just wondering if its used in both cases, Youtube and Twitch?
So, when you see that streaming doesn't work, that tells me that there is either a noise issue with the upstream channels when they arrive at the CMTS, or, the CMTS or upstream server suffers from congestion.
Here's something that you can do, when streaming works and when it doesn't:
1. Call tech support and ask the Customer Service Rep what the upstream channel Signal to Noise ratios and Signal levels are? You can see those as they aren't reported back to the modem. The CSR can see both sides. So, the question is, is there a large difference in those values from periods where streaming doesn't work, to periods where streaming works? Noise in the cable system could be an issue. Usually that also shows up in the downstream channels as well, but, its worth determining if there is a large difference at the CMTS.
2. Ask the CSR to pass you onto a Level II tech. The question for that tech is what it the current load on the CMTS in terms of a % load? Once again, the question is, is there a large difference in those same time periods? Is the CMTS highly loaded when streaming doesn't work? That would point to a need to spit the CMTS load among two or more CMTS systems.
So, if the answers are that there isn't a noise issue, and that the CMTS isn't carrying a large load, then the answer lies further upstream, either within Rogers network, or wherever Rogers connects to Youtube and/or Twitch. That might be a multi ISP path.
So, the hunt continues .... little by little.
@dtx1, @Makaveli99, the second hop outbound is problematic, either in the case where the modem is running in Gateway mode, or where its running in Bridge mode with a router behind it. In this last case, the modem acts as an invisible bridge to the CMTS. The second hop in both cases is the Casa Systems CMTS.
In both cases, an IPV4 or IPV6 ICMP ping will result in ping spikes, usually up into the 80 to 90 ms range. That's an internal modem issue that applies to more than one modem of Hitron modem. I've asked to have that corrected as it once was with the CGN3ACSMR or CGNM-3552, don't remember the details now. So, it was corrected in another modem, it shouldn't be hard to carry out that same correction for current modem firmware, personal opinion. You will also see false packet loss indications from the modem and CMTS if you carry out a ping test beyond the CMTS with Pingplotter. A command line ping test will confirm or dispel the false packet loss indications from the modem or the CMTS.
The end result is that you can't rely on a ping test to the CMTS to look at response times and latency between the modem and CMTS. You can still use a ping test to the CMTS IP address to check for packet loss, and if you let that run for a 24 hour period, you should only see somewhere around 10 to 20 packets lost throughout that time period.
From my own testing, that indicated ping spike from the CMTS doesn't have any effect on results to targets beyond the CMTS.
@dtx1, in terms of the TCP issues that you indicated, Hitron and Rogers started to issue firmware updates to resolve latency issues with the Puma 6 modems in Sept 2016. That was an IPV4 ICMP fix only. Since that time, there have been further updates to reduce other protocol latency, but, no one, including Intel, Hitron or Rogers has come out with any proof in the form of multi-protocol ping plots which indicate that Intel has finally put the Puma 6 latency issue to bed. I've been running the Puma 7 CODA-4582 since Dec 2016, so, I haven't had any opportunity to determine if the Puma 6 latency that I noticed much earlier that year has finally been resolved.
I can say that the 4582 does not suffer from the latency issues that the Puma 6 modems had. The one exception is the rather annoying ping latency to the CMTS. That was introduced in version 2.0.10.27, and its been there ever since.
To determine if there are issues remaining with latency thru the Puma 6 modem, that would require someone to run the following in both IPV4 and IPV6 for both Gateway and Bridge modes:
1. ICMP ping test to the Rogers DNS
2. TCP/IP ping test to the Rogers DNS
3. DNS query to the Rogers DNS to generate UDP responses which can be clocked and plotted.
That's another discussion, with a set of instructions that I need to post for anyone to carry out.....
@aeroteq may I refer you to the following thread:
https://communityforums.rogers.com/t5/Internet/Rogers-Gaming-amp-Streaming-Lab/m-p/440211#M56121
Please post a brief synopsis in that thread so that @RogersAndy can respond to your post.
@delos, can I draw your attention to the following thread:
https://communityforums.rogers.com/t5/Internet/Rogers-Gaming-amp-Streaming-Lab/m-p/440211#M56121
Could you post your circumstances in a post within that thread so that @RogersAndy can have a loot at it.
Thanks so much for sending us a PM, we'll be happy to assist and continue there in identifying the issue. Feel free to post your traceroute results that show the issue in effect here though when able. (Be sure to remove any personal information such as IP or MAC address). This way others who may have the same issue can have a stepping stone for identifying their latency.
-
48411 views
-
21 Likes
-
-
