Food for thought ..... this might not be a matter of Rogers throttling RTMP, or intentionally throttling RTMP. There are a number of factors that are thrown into the mix for any protocol and destination. @AhmedAskar's comments earlier today that he had "0 frame drops on 8-10 hour streams on Ashburn server." is rather interesting. So, that shows that it can be done over the Rogers network, the question is, what's different between your pc, video resolution, stream settings, modem and path to the same server versus those for @AhmedAskar. Somewhere in those details will be the answer, or one of many answers.
Just to point out, a similar situation exists for ESP/IPSEC traffic. From the feedback thread and @RogersDave's continuing post for the version updates:
- Non TCP/UDP/ICMP traffic (such as ESP/IPSec without NAT-T) is slowed down below 25 Mbps
So, thats a firmware issue that goes way back and is something that Intel will have to address. Are there similar issues with any other protocols, including RTMP? Thats a question that needs to be addressed.
I think the first thing I would look at are the differences in the pc, video resolution and streaming settings with OBS, just to see if anything stands out as an item that could be tested by using different settings. After that its on to the modem model and firmware and route to the server.
Edit: You indicated that you saw a couple of Rogers techs earlier today. Are you in a condo/townhouse/highrise type of building? If so, then that building could have a Multiple-Dwelling Unit (MDU) that provides data services to the building. If the building is big enough, there could be more than one MDU. These are similar to the Cable Modem Termination Systems that service neighborhoods. There is always the possibility that you could be connected to an MDU that has a technical problem.
Now that you have switched modems, can you try pinging the MDU/CMTS, 99.230.32.1 again. Let that run for 10 or 30 minutes and ensure that the focus time in pingplotter is set for Auto. I'd like to see the average time to the MDU/CMTS, which was variable in the previous slides.
@RedLir the point that I would really like to stress is that this isn't necessarily a case of "Rogers is throttling" any given data type. Any statement of that type will cause a never ending stream of comments and criticism from a number of people who rightfully oppose that idea in any form, but who are more than willing to add their thoughts on the situation without looking at any of the details in this discussion. Simply put, I'm not interested in getting into that type of argument.
What I am trying to point out is the technical details here. You indicated that encapsulating the data appears to solve the issue and the suggestion from that is the fact that users have to hide the data from Rogers so that it goes out at an acceptable rate. I would suggest that this is not the case at all. What it points to is yet another possible processing issue with the Puma 6 and 7 chipsets, designed by Intel and running on Intel provided firmware. Somewhere in the past, in the 2010 to 2012 timeframe, some engineer at Intel, or maybe a group of engineers at Intel determined how the Puma 6 (CGN3xxxx) would process various types of protocols and how fast those protocols would run thru the modem. That information doesn't appear to have trickled down thru the manufacture, to the ISP, to the end user. End result, you have users trying to determine what the "problem" is for any given protocol, pointing fingers at the ISP, and by ISP I mean more than just Rogers. My guess would be that at some point in the Puma 7 (CODA-4582) development, the same protocol priority and data rate constraints used in the Puma 6 chipset were possibly ported over to the Puma 7 chipset. Why screw with success, right? And here we are, arguing over the possibility of intentional throttling by Rogers, "this is still a (illegal?) problem" versus recognizing the limits embedded in the hardware and firmware which is designed by Intel and provided to numerous manufacturers.
The one item that has become evident over the last two to three years is that there isn't sufficient testing at any level, from Intel, to the manufacturers, to the ISPs that would result in exact details outlining the protocol capabilities. That should start with Intel, not the end user, personal opinion. If this had been done, my guess is that we wouldn't be having this conversation. At some point in time, the manufacturers and ISPs would have looked at the results for all of the protocols, determined that there was a problem due to the throughput rates and kicked the issues back to Intel long before the users had caught them. This type of conversation shouldn't be happening.
Having said that, testing takes resources, in specialized equipment in some cases, and more importantly in manpower, designing the tests and reviewing the results to confirm that they are correct and that the final results are reasonable. That takes network engineers with very specific knowledge of the protocols who can instantly recognize a problem when they see it. That takes a lot of experience and at the end of the day, it comes down to company budgets. Personal opinion, the engineers who can run those tests and analyze the results are probably worth their weight in gold as they can save any company huge amounts of manpower in terms of tech support that doesn't have to be provided if the equipment works as it should. Once again, that should start with Intel, during the development cycle. If that testing was done correctly by Intel, we shouldn't be seeing any of these issues.
All personal opinion of course ....... fwiw.
Edit: Just to point out, during the Puma 6 latency debacle which is still ongoing, it was pointed out that Cablelabs should be doing performance testing on modems. Cablelabs runs interoperability testing to certify modems for DOCSIS compliance on the cable modem side. Cablelabs response to the Puma 6 situation was "we don't do performance testing." So, there is no central body that looks at the LAN side of the modem and any throughput issues , WAN to LAN or vice versa, that might exist. Too bad because they are probably ideally placed to run performance testing. They have CMTS equipment, the modems and the engineers who understand how the modems operate and probably the intricacies of the protocols.
Edit 2: You were wondering why a VPN makes a difference. Let me try to answer that one although @RogersDave could provide the full explanation. The modem examines every packet or group of packets to determine the applicable transmit/receive/processing rules and to determine if the packet(s) should be processed by the CPU or by the Hardware Accelerator/Processor. As is seen in the case of ESP/IPSEC, the packets are handled by the CPU if I remember this correctly and are only processed at a 25 Mb/s rate or less. Is there a CPU limitation that restricts that rate, or was it selected by a the flip of a coin many years ago? Don’t know, but, the situation exists.
In the case of the VPN, there is an initial inspection, the VPN is set up and handed over to the Hardware Accelerator/Processor. The tunnel keeps running but there are no more inspections of the data. The data transits through the modem at the VPN rate instead of the rate predetermined for a given protocol. There is of course the Host VPN provider limits and the limit of the pc's encryption rate that would affect the final data rate.
So, that is the way that Intel designed the firmware many years ago, and now, the limitations, if they exist, are bubbling to the surface so to speak as the overlooked protocols are now being put to use.
The Rogers engineer that can do something about these issues is @RogersDave. You may have noticed his posts in the forum already and I suspect that he's already seen your posts on this issue. Responding to user posts is not his primary job but he takes time, when he can, to address specific issues such as this.
From your previous post:
A. Its very possible that there is a limit on the data rate through the modem for RTMP. Dave would be the engineer on staff who can send this issue to Hitron for further investigation. ESP/IPSEC is one example where there is a definite limit on the data rate through modem. The question is, are there other protocols that are limited for any reason, technical or otherwise? That is something that Hitron and Intel would have to determine.
B. There is no modem that you can buy to use on the network. Rogers supplies the modems at the present time and will only allow approved modems onto the network. At the present time, there is no other non-Intel modem available. Now having said that, are you running a business? If so, I wonder if the business division might have access to other modems? I've never had any interactions with that group so I don't know what access to enterprise equipment they have that would be more suitable for businesses and large organizations. I would think they would.
C. There is always a possibility of congestion issues with the Cable Modem Termination System, which the modem is connected to, and, there is an issue with the CODA-4582 (Intel Puma 7) and large TCP retransmissions. Are the problems you are experiencing a side-effect of congestion or the TCP issue, or is this simply a matter of a capped data rate for RTMP? That is something that Dave, Hitron and Intel will have to sort out.
On another note, have a look at the following post by @J04DAN1 which will be of interest as it details his experience of successfully streaming via wifi instead of ethernet to get around the dropped frame problems that he had while connected thru ethernet to the modem:
http://communityforums.rogers.com/t5/Internet/Rogers-Online-Gaming-Thread/m-p/403570#M48120
- last edited on by
RogersMoin
Uploading to Twitch
I'm not sure exactly what information I need to provide, but I've been having an issue with live streaming to twitch. I'm on the Gigabit plan, and while uploading at 4500 bitrate I'll occasionally have my internet speed drop to less than 1mb/s and drop a metric ton of frames.
Examples of this happening:
After countless times of being told that everything seemed fine on Rogers end, I had them send a tech who found that there was indeed an issue with my upload, and he told me that he had fixed it.
Later that night, I did a test and the issue persisted. Here is a picture of about a 2 hours stream I did showing it dropping still.
Here is a Twitch Bandwidth test I did. I typically stream to either the Ashburn, VA server, or the New York, NY server as I've found the Chicago server is always either really good, or really bad and I find the Toronto server is very random as well.
Speedtest.net also shows me about what I'd expect I should be getting, which should be way more than enough for me to be streaming at the 4.5Mb/s that I'm typically at.
If anyone has any insight in what could be wrong, what I can do, or anything like that, please, please help me. I've been struggling with this issue pretty much since the day I upgraded to gigabit, and I've been on the phone with rogers for what feels like 3 weeks now trying to get it fixed just being told that everything seems fine from what they can see.
But if I'm being told everything seems good on their side, and the Tech told me that everything should now be good on my end, but the issue is still happening, obviously something is wrong still and I'm just completely lost at this point.
-
45921 views
-
21 Likes
-
-
