Question I desperately need help with this strange behaviour ?

Oct 5, 2024
11
0
10
Quick backstory - I stream games for a living, and I'm heavily, heavily dependent on my networking speed, specifically my upload speed.

I have Xfinity. It's been mostly fine for 3+years. About a month ago, I started having issues where my stream's broadcasting software (OBS) would start losing a strong network signal, which in turn causes the stream to drop frames = lag. In the beginning, it would happen every 3-4 minutes, and last about 10 seconds or so. This would be rinse/repeat for literally hours, all stream long. I would do test streams and find that these connection issues would still happen during the day and morning, but were MUCH more prolific at night (when I'm streaming).
As you can imagine, this is detrimental to my stream and therefore my livelihood.

I feel like I've tried literally everything and I just don't know what to do/what I might be missing at a certain point.
So far I've:
  • Had 4 Xfinity techs come out, including a supervisor. They all said they saw no problems. Thing is, they usually come around the afternoon, latest 4PM. That's not when the problems usually start happening. They even put a monitor on my modem to "ping" it every 10 minutes for a week. They saw no issues.
  • Recreated the problem on:
    • Two different PCs
    • Two different streaming software
    • A fresh install of said streaming software
    • Two different ethernet cables
    • Wifi AND wired connection
    • Two different modem/router setups. One was the the one Xfinity gave me, the other setup was my own with an S33 modem.
I've ordered a new coax cable to see if maybe that might be it, but I'm not hopeful.

Does anyone have any ideas? I'm willing to try absolutely anything at this point.

PS: For those of you unfamiliar with the streaming space/software - I use OBS and dropped frames essentially are ONLY network related issues. So actual encoding issues (eg lack of resources) are not the problem here, as that would show up as a separate issue within OBS. Quote from OBS's site below.

OBS Studio is unlikely to be the cause​

It is nearly impossible for OBS Studio to cause dropped frames. Bear this in mind if you have recently updated OBS Studio and believe it is the cause of your dropped frames.

For a detailed, technical explanation on what dropped frames are, please check this post written by Lain.
 
The ISP was very proactive if they did a ping test. That is pretty much the best way to detect packet loss.

Not sure if every 10 minutes is enough since you would have to get lucky to hit a outage.

Pretty standard testing. I would start simple open a cmd window and leave a constant ping run to some common IP like 8.8.8.8. When OBS sees issues I would quickly swap over and see if there is any packet loss.

If you see no loss then it is either something because OBS is a much more complex software than a simple ping command or there is something different in the path to google dns (8.8.8.8) and the server OBS talks to. You really don't want the second case because it is likely far outside your ISP control and ability to fix.

If you do see loss then you need to run tracert 8.8.8.8 and try to ping nodes in the path to find the problem. Really you can only do stuff with hop 1 and hop 2 so I would concentrate on those.
 
Oct 5, 2024
11
0
10
If this is happening at, or very close to the same time every day (especially the evenings) then it's caused by network congestion that you can not do anything about.
I hear you, and that may very well be what it is. Only thing that troubles me with that is:
  • I stream late into the nights (usually 4AM). I've had this happening until 3AM. At 3AM, there's still congestion?
  • This was not a problem for 3+ years. Obviously something could've changed in that time, but strange.
 
Oct 5, 2024
11
0
10
The ISP was very proactive if they did a ping test. That is pretty much the best way to detect packet loss.

Not sure if every 10 minutes is enough since you would have to get lucky to hit a outage.

Pretty standard testing. I would start simple open a cmd window and leave a constant ping run to some common IP like 8.8.8.8. When OBS sees issues I would quickly swap over and see if there is any packet loss.

If you see no loss then it is either something because OBS is a much more complex software than a simple ping command or there is something different in the path to google dns (8.8.8.8) and the server OBS talks to. You really don't want the second case because it is likely far outside your ISP control and ability to fix.

If you do see loss then you need to run tracert 8.8.8.8 and try to ping nodes in the path to find the problem. Really you can only do stuff with hop 1 and hop 2 so I would concentrate on those.
Should've mentioned this, but I did this. (had a friend much more apt to this help me)
Even when it lagged on OBS's end - 0% packet loss on a ping to 8.8.8.8.

He then had me setup a tracert to I believe a twitch server I need to connect to to actually stream. We found, at times, what looked like a hop would timeout, but then at times (even when lagging on stream), the tracert was flawless. No timeouts, and no latency more than 40ms.
 

lantis3

Distinguished
Nov 5, 2015
856
146
19,070
Scheduled cloud backup by people or huge chunks of file transfers can be happening in the midnight or anytime during the day which causes congestion. No one have control over it.
 
Oct 5, 2024
11
0
10
Here was my tracert results pinging to live.twitch.tv (this is exactly when I was experiencing the lag on OBS).

Blocked out some info that I'm not sure could've been personal.

tracert.png
 
Oct 5, 2024
11
0
10
Scheduled cloud backup by a lot of people can be happening in the midnight or anytime during the day which causes congestion.
Hmm. I have 1000/250 speeds. Could that kind of activity drop my connection down so low that it lags an 8,000kbps (so 8mbs) stream?
 

lantis3

Distinguished
Nov 5, 2015
856
146
19,070
Hmm. I have 1000/250 speeds. Could that kind of activity drop my connection down so low that it lags an 8,000kbps (so 8mbs) stream?
Of course. Eventually everyone share the same internet pipe provided by your ISP. Just like highway. The number claimed by the isp is the upper limit only in perfect condition.

ISP will only look at the problem seriously if a lot of people start to complain.

Try a few VPN (which can change routes) to see if matter improves.
 
Last edited:
You have to be careful about reading too much into packet loss on intermediate routers in a trace.

Routers are designed to use their processor power to pass traffic first and respond to test traffic second. In many cases routers also have limit on how much test traffic they respond to and some do not respond at all. Idiot childern will use ping commands to do denial of service attacks against routers.

Loss in a intermediate node would cause loss in nodes past it. It is like traffic lights on the way to work. If one is not working it will cause delays at that light as well as increase the time to your work. If you magically arrive to work on time even when a light has failed then the report of a outage is incorrect.

This is very hard because the ping says it is not a true network issue. I don't know how OBS works does it use TCP or UDP. If it is TCP you should be able to run wire shark and see which end is causing the delays or packet retransmissions. Wireshark is not a easy thing to read since there is massive amounts of data. This is the problem with complex software. You see it all the time on game software. The game claims there is network delay but the game client got stuck say in a video render routine and when it finally got less busy and checked for its "ping" packet it blames all the time on the network when the data packet was sitting there waiting to be read.
 

KingLoki

Upstanding
Jul 10, 2024
423
69
270
So obviously the internet speeds are running around maximum for your situation and pings are ok. It's ethernet connection, right?

Have you tried different streaming software, like Streamlabs etc. to see if there's any difference?
Also if you stream with friends on say, discord, are there any speed problems?
 
Yup this is where removing data really hurts. Those are all IPv6 addresses. They do not reveal any more than IPv4 addresses, like you live someplace in new jersey.

I would disable the IPv6 support in the nic settings.

IPv4 and IPv6 can follow very different paths in the internet. Also for some reason IPv6 tends to have more issues and have non optimum paths. They have been saying IPv6 is the future for 20 years but the ISP are not very proactive in making it actually work as good or better than IPv4.

This may or may not make any different. It depends, it tends to be kinda random since some sites support IPv6 and others do not.

You will at least know that the trace follows the same path as your actual data.
 
  • Like
Reactions: Ralston18
Oct 5, 2024
11
0
10
Yup this is where removing data really hurts. Those are all IPv6 addresses. They do not reveal any more than IPv4 addresses, like you live someplace in new jersey.

I would disable the IPv6 support in the nic settings.

IPv4 and IPv6 can follow very different paths in the internet. Also for some reason IPv6 tends to have more issues and have non optimum paths. They have been saying IPv6 is the future for 20 years but the ISP are not very proactive in making it actually work as good or better than IPv4.

This may or may not make any different. It depends, it tends to be kinda random since some sites support IPv6 and others do not.

You will at least know that the trace follows the same path as your actual data.
Looks like with the little googling I just did, there isn't anyway to disable IPV6 with Xfinity. At least with the gateway that they supply that I'm using (that I need to actually get the speeds I'm paying for).

Unless there is a way? Would love to give it a try.
 

USAFRet

Titan
Moderator
I hear you, and that may very well be what it is. Only thing that troubles me with that is:
  • I stream late into the nights (usually 4AM). I've had this happening until 3AM. At 3AM, there's still congestion?
  • This was not a problem for 3+ years. Obviously something could've changed in that time, but strange.
Neighbor cranking up a new mining farm?

If it is happening to ALL your systems, it is outside your house. And little really you can do about it.
 
Oct 5, 2024
11
0
10
Neighbor cranking up a new mining farm?

If it is happening to ALL your systems, it is outside your house. And little really you can do about it.
While I don't plan to know every neighbor, obviously, most of them are much older - that I doubt are doing anything even remotely close to that to warrant my connection suffering lol.
 
Oct 5, 2024
11
0
10
Yup this is where removing data really hurts. Those are all IPv6 addresses. They do not reveal any more than IPv4 addresses, like you live someplace in new jersey.

I would disable the IPv6 support in the nic settings.

IPv4 and IPv6 can follow very different paths in the internet. Also for some reason IPv6 tends to have more issues and have non optimum paths. They have been saying IPv6 is the future for 20 years but the ISP are not very proactive in making it actually work as good or better than IPv4.

This may or may not make any different. It depends, it tends to be kinda random since some sites support IPv6 and others do not.

You will at least know that the trace follows the same path as your actual data.
Well, I disabled IPv6, and now it looks like my tracer log reflects that (I might be exposing more vulnerable info here but at this point, I need solutions).

However, the problem still persists. Strangely, other than a spike at 281ms, it does not look like the log is reflecting any network issues while these dropped frames are happening on my end with the stream. I suppose it could be entirely possible that there are more complicated and nuanced communications going on with my network and delivering the Twitch stream that might not even register on a log test like this, but I'm just at a loss on where to go from here.


6d885517a8349381d502b9f0e2db2469.png


ab43e6a9e283586b5ab43d3d8581bc00.png



8e1b43410ec56f5cab01d5ba0984a3db.png