09-15-2017 12:25 PM - last edited on 09-15-2017 01:00 PM by RogersZia
Hello,
I'm curious if any other Twitch broadcasters are experiencing this issue with Rogers. I get 250 down / 20 up consistently and my upload to Twitch will start to drop frames/packets if I exceed around 3000 bps, which is not even a 1/4 of my upload.
I've been troubleshooting the connection issues streaming to twitch, for almost a year now with support. Modems have been replaced. Techs have come and replaced wire and tested to the curb etc. Speedtests are fine. The issue persists across multiple machines/cables and every Twitch ingest server that I can reasonably test location wise.
At some point, someone suggested I encapsulate my data by testing with a VPN to the local cities of the ingest servers I was testing. This is when I realized, that Rogers may in fact be throttling my RTMP uploads by payload. When I use a VPN, and test to any of the ingest servers I had issues with, I get no packet loss or dropped frames to Twitch. I can push the Twitch cap of 6000 bps without issue with the VPN enabled. ( testing to Toronto, NY, Chicago ingests primarily)
I did another test. I streamed my feed to restream.io ( which also uses RTMP) to rule out a rule specific to twitch completely. I saw the exact same issue. Without the VPN, I would get frame/packet loss, but with the VPN on, I would have no issue.
I've been running with the VPN for some time now as a workaround, but it's an additional cost of course, and one I shouldn't need to incur. Ater a few months of solid streaming through the VPN, I tested again without it. As expected I immediately started to lose frames/packets intermittently through the broadcast, due to insufficient network when I disabled the VPN.
I'm at the point where I think I'm going to need to change providers. Calling front line support doesn't seem to get me anywhere. They just want to replace a modem or close my ticket the next day without any feedback/consent or resolution.
Is anyone else out there experiencing these types of issues uploading to twitch via rogers? Advice on how I can escalate this to an appropriate resource within the support team who will look at it seriously?
Thanks!
***Edited Labels***
01-28-2018 02:11 PM
@RyzenFX I'm the OP
I've had 3 different modems, the other 2 were CGN modems. That's the stock answer from support. Change the modem. It hasn't worked yet! 😉
01-28-2018 02:39 PM
This is going to take a rather focused investigation by Rogers and Twitch engineers and a willing volunteer, all working together to get to the bottom of the problem. This would be much easier if there was another modem available for test purposes that wasn't an Intel product. That would either clear the Intel modems or place the problem directly in Intel's lap. I'll have to post a question in the DSLReports TPIA forums just to see if TPIA users on Rogers Cable system have any success with Twitch uploads.
01-28-2018 03:29 PM
I streamed on Start with Zero Problems for 2 years with just a minor hitch for a couple of weeks. So ya, this is getting annoying.
01-29-2018 04:17 PM
I hear what you are saying streaming to twitch is very bad I check all my network stuff test all came back A+ good ping good download good upload but stable upload not a chance tested every server goes good then drops to 0 out of no where with no one on the network even with a 3k bitrate of my 30 upload speed searched everywhere and seems like a lot of people having this problem with these chips I switched from bell to get better upload speed Surf & Stream
As Much As You Want! well rip my moneys I got the top package to get better upload speed mainly for streaming to twitch now I'm paying over 100$ for something I can't use for what it was meant for need to find a fix for this problem since streaming is the way of my future this has to be fix one way or another there's people in Canada that can stream to twitch with 9k bitrate with no frame drops network drops please help us fix this problem
01-30-2018 04:30 PM
Hi @abelmacneil,
Welcome to the Community Forums, and thanks for your post.
I completely understand how frustrating it must be to have issues streaming with Twitch.
Can you possibly expand a little on your statement that your network seems great but unstable? Perhaps @Datalink or @gp-se can provide some guidance on how to obtain some clearer data for us to look into?
RogersShaun
01-30-2018 04:36 PM
Although I'm not abel, I'm having the same issues where the stream will be rock solid for a few min, completely go to 0kb/s then recover and go back to rock solid. I'm on the CODA4852 modem and I recently switched over from Start where I had Zero problems streaming.
This is my SNB info:
and this is my Twitch inspector info:
As you can see, it flatlines throughout the entire stream and essentially freezes the stream, but the sound goes through. It's a wired connection with no extra routers or bridges or anything of the sort.
01-30-2018 04:40 PM - edited 01-30-2018 04:41 PM
@Tal3 what modem model were you using with Start? I'm curious at this point to know if it was a Hitron CDA3 or CGN variety or something completely different. And ..... cable or DSL/VDSL? You were on R-cable with Start, correct? If I have that correct then the difference would be the modem and the back-end support as your data should have been routed to Start's servers and then onwards from there.
01-30-2018 04:42 PM
It was a THOMSON DCM476 on Cable.
01-30-2018 04:51 PM
01-30-2018 05:09 PM - edited 01-30-2018 05:29 PM
@RogersShaun nope, this is an engineering issue that will take concerted action by Rogers and Twitch Engineering staff to sort out. From what I can see there's nothing that I or Tech Support can do at this point in time. Using a VPN appears to be a workaround, which points to the fact that as long as the modem doesn't know that the data stream is RTMP based, then its quite satisfied to run it with any VPN data rate restrictions found in the Puma 6 and 7 firmware. As I've indicted before, this will take a test session or two with Rogers and Twitch Engineers, with full access to the modem and network in order to trace the data from the customer's modem, thru the network and finally to the Twitch servers. Even then, it will result in a list of actions that have to be completed to ensure that RTMP streaming works on the Rogers network, not only for Twitch, but also for Youtube and others. That customer will have to be a volunteer, willing to run a test stream and provide any tech details required by the Rogers and Twitch Engineers. Just a guess, this might take a few hours via three way conference call to accomplish.
The one nagging problem here is that no one appears to have details on hand that spell out specific data rates for the various protocols that the modems might encounter. There are known issues with data rates for non-TCP/IP,ICMP or UDP traffic. So, someone in the Engineering Staff needs to take the bull by the horns and sort this out as its an issue not only with streaming RTMP, but also with VPNs and with IPSEC traffic. My personal thought is that these issues might date back to the 2007/2008 timeframe when the Puma 5 was first developed by Texas Instruments. Intel bought the Puma product line from Texas Instruments in 2010, and possibly carried on any limitations by simply porting portions of the firmware to both Puma 6 and 7 modems, both of which have problems with out of the ordinary protocols.
At the end of the day, Rogers will have to make some pronouncement that they are, or are not interested in running protocols other than run of the mill TCP/IP, ICMP and UDP. Users these days expect much more out of their services, from streaming to VPNs to IPSEC and others. I'm sure that TPIAs are more than willing to step in if Rogers prefers to stay out of the game.
01-30-2018 06:06 PM
@Tal3 wrote:
Although I'm not abel, I'm having the same issues where the stream will be rock solid for a few min, completely go to 0kb/s then recover and go back to rock solid. I'm on the CODA4852 modem and I recently switched over from Start where I had Zero problems streaming.
This is my SNB info:
and this is my Twitch inspector info:
As you can see, it flatlines throughout the entire stream and essentially freezes the stream, but the sound goes through. It's a wired connection with no extra routers or bridges or anything of the sort.
as @Datalink mentioned, the issue is in Rogers Routing. However, your signal levels are very weak, and the SNR numbers are low. I would suggest sending a PM to @CommunityHelps asking them to check your signal levels and SNR, then to compare to your neighbours to see if your low levels are neighbourhood wide, or only affecting your modem.
Either way they should send a tech out to improve the SNR levels.
02-01-2018 08:45 PM
So I just wanted to add that I signed up for the trial firmware process and am now on 2.0.10.33T3 firmware and the problem still persists, so unfortunately I may have to drop the service and just pick up another Modem, shame.
02-02-2018 04:56 PM - edited 02-02-2018 04:56 PM
this RTMP issue seems to affect only the coda 4582 and not the CGN3 family of modems despite the fact that they both run intel puma chipsets. i believe a similar issue was experienced in older firmware on intel puma systems where the modem would drop packets on large long running data streams. https://www.theregister.co.uk/2016/12/03/intel_puma_chipset_firmware_fix/
02-02-2018 06:26 PM
Would there be a way to get the CGN line of modems?
02-03-2018 05:53 PM - edited 02-03-2018 06:04 PM
I'm waiting on my new lan card in 2 days since when I look at most people that have this problem most of them got killer network adapters so I'm a rule out that before I go in further details and since I heard of some people changing helped I don't want to waste no ones time you know but here is my levels anyways
02-04-2018 01:04 AM
I decided to check out vpn expressvpn started streaming 0 drop frames after over an hour of streaming disconnect connected to a different server ran for an hour 0 drop frames to twitch wow I can't believe those guys were right vpn fixes all the problem streaming to twitch tested it at 6k bitrate by the way not the 3k bitrate I was doing before when I was dropping metic tons of frames ever min or so
02-04-2018 08:08 AM
Im tired of this issue, not being able to stream as a full time streamer, if anybody else had any suggestions for a different ISP please PM me, new to Canada and don't know much about ISPs.
Was looking at start and bell
02-04-2018 05:54 PM
I don't Twitch or stream RTMP but this thread disturbs me: is this a violation of net neutrality? I know @Datalink says that this topic is inappropriate, but I'd like to try to analyze this.
Are some people with this problem using the modem in Bridge mode? From here on, I'm only going to talk about systems where the modem is in bridge mode.
In bridge mode, the modem should not be examining packets, except for destination address. All packets should take the same fast path. No protocol should have different performance characteristics through the modem. There is no room for microcode bugs here.
If VPNs solve the problem, why? And which kind of VPN? Each type of VPN has different kinds of packets. Most of IPSec traffic is ESP or UDP, if NAT traversal is used. Most of OpenVPN traffic is TLS. Neither of these should be treated specially by a modem in bridge mode. But if Rogers throttles this upstream (doing so would violate net neutrality too, but this is claimed by some posts in this thread), it could prevent the modem from being overwhelmed (an unintended consequence). It could also be that the VPN provider throttles (no net neutrality issue). Overwhelmed modems can behave in mysterious ways.
If this were my problem, I'd look at the characteristics of the RTMP flow and mimic it in some other protocol. I'd need to generate it on something in the cloud with decent bandwidth. I don't even know if Rogers has some fast path to Twitch. Pure guess: the bad behaviour would happen to this mimic stream too. That would imply that network neutrality was maintained.
I wonder if Buffer Bloat is striking somewhere, perhaps in the Rogers network, perhaps in the Modem. https://en.wikipedia.org/wiki/Bufferbloat
If you are using bridge mode, the problem might just be in your router. For purposes of experimentation, consider connecting your gaming machine directly to the modem (make sure that your machine's firewall is appropriately cranked up).
02-04-2018 05:58 PM
I can't speak for anyone else, but I'm not in bridge mode and have my PC directly connected to the modem. It's incredibly annoying and isn't what I'm paying for.
02-04-2018 06:08 PM - edited 02-04-2018 06:09 PM
At this point in time I really, really don't believe that its a case of intentional throttling. All of the evidence that I've seen so far points to a protocol issue with the Puma series modems. Another poster noted that he was on Start, using a non-Puma modem and didn't have any issues, and that was with a service that used the Rogers network. So, this can work, on Rogers network, with a non-Puma modem. Its really unfortunate that Rogers doesn't offer such a modem as that could instantly indicate whether or not the problem is with the Puma series modems or not.
So, I'm not saying that the issue of a possible violation of net neutrality is inappropriate. I just don't believe that its the case here. But, I am absolutely willing to look at any evidence that indicates otherwise.
As I've indicted elsewhere, testing consumer modems is sorely lacking, personal opinion. That includes testing all of the various protocols that are legal for use, as indicated by their respective RFCs. That should be done by Intel before the modem is ever released for manufacturing. That would avoid situations such as this, or, personal opinion, it should avoid situations such as this. Should and would are two completely different concepts here.
Just to note, the days of a simple modem are long passed. These days, DOCSIS modems do a lot more than one would think.
02-04-2018 10:14 PM
Just thought I'd chime in - when I last posted some time ago, the issue had completely vanished. It's back again, and very annoying. Not going to bother with any other details as the symptoms and hardware are identical to so many other cases in this thread.
Not sure why it worked fine for the couple months or so or why it just came back sometime last week. If there were two firmware updates in that time frame it might make sense. Otherwise I'm not sure what's going on. I haven't changed anything on my end.