Question The impossible internet problem of 3 years

[vguy95]

Hi, I'm going to do my best to explain what I know about this situation I'm in. I would really appreciate if the Networking genius' could help me figure this problem out, since we've had this similar problem for 3 years. Its a direct ethernet connection, not WiFi. Its 1 GB down and 100 upload from Shaw here in Canada. I have ran tests on other computers in the household, with different ethernet cables and ports and created the same situations. The modem/router is the same device.

It all began 3 years ago, out of no where between like 2 am central to 11 am, the internet would spike and lag on things like live streams. I complained many times, and eventually some guy on the forums said they found the problem and patched it, seemed to work. About 3 months later, the problem was less specific to time, but my upload would spike downwards to 49 Kbps or so. Because I'm a live streamer on Twitch.TV its important to have a good connection, so when I was running Streamlabs OBS, I noticed I was dropping 3-5% of my total frames, which is very bad for streaming. In order to see what exactly was going on, I went to inspector twitch TV and graphed my upload. It showed what I suspected, the upload kept spiking downwards to 49 Kbps, sometimes 1 Mbps, sometimes 2 Mbps, sometimes 3 Mbps -- and you need about 6 Mbps upload to maintain a 1080p stream. I also tested other twitch servers, the same thing.

When I contacted Shaw they did the typical hey, I did a speed test it looks fine. They hooked up their equipment to my cable modem, said hey it looks fine. In the past, they had sent a total of 10+ techs out, and locally they could never find an issue. About a year later, someone working internally at Shaw almost instantly found a problem in the node. He called me personally, and let me know that he found the problem. The problem was like 90% better. He then found some other problems, but it was still doing this weird spiking stuff once in awhile. It was never completely fixed, but I was somewhat satisfied and just accepted it.

Some months later pass, I end up with the exact same problem. The upload is spiking downwards again. Because Shaw didn't believe my Streamlabs OBS and inspector Twitch, I decided to watch my Streamlabs OBS live information, and when it would begin lagging I would immediately go do a test on testmy.net, with a dummy file upload. This way I could try to rule out whether its a specific server, or if its just like this across the entire internet for me. Well, when I did that and plotted the graph there too, it showed my average upload was 8.8 Mbps, and the graph showed spikes downwards to 1 Mbps (as my other applications were reading).

I showed Shaw all of this. They keep saying it looks fine, no matter what I do. So, my next step was I was going to try to find even more evidence to show a problem exists. So, I downloaded pingplotter and did some tests. It showed at 10.0.0.1 (my local modem) has a constant 50% packet loss. When I do pings to google, theres many hops that have a constant 50-70% packet loss too. I notified Shaw of this, and they said they dont trust 3rd party software for their diagnostics.

One thing I'm questioning, is that theres a cable line going directly to my house, which is close to my modem, that looks frayed. The tech was up there just the other day, I'm not sure how he didnt notice that, or maybe its not a big deal and I'm wrong about that.

Here are some of the images I have. (? when I try to upload it says contact admin something went wrong)...

https://imgur.com/oOXXyXF

View: https://imgur.com/oOXXyXF

https://imgur.com/jmQ7Nxf

View: https://imgur.com/jmQ7Nxf

https://imgur.com/SOZtis7

View: https://imgur.com/SOZtis7

https://imgur.com/nRIPRUb

View: https://imgur.com/nRIPRUb

https://imgur.com/rR5pcrG

View: https://imgur.com/rR5pcrG

 

[vguy95]

Before someone asks, Shaw has a monopoly on my street.

 

[bill001g]

You have to be careful about how you interpret pingplotter. Really this tool should have a required training test before they let people use it. They just run it and go "red bad must fix".

In the first pingplot you show no issues at all. Everything you see is testing error. If for example hop 11 actually discards 100% of the traffic you would never see any hop past it. The same as hop 1 losing 50% of the traffic. If you were really losing 50% your connection would be almost totaly unusable. Even 10% makes it very very bad so these numbers can't be true.

The second pingplot is what a bad one looks like. You see .3% packet loss starting in a hop and then continuing all the way to the end including the final destination. Damage caused by a earlier hop will have affect on every hop past it.

In the second case it is going to be your router or your PC causing it. What is much more likely it is something stupid with the way IPv6 is implemented. Try to turn off IPv6 support in your PC nic settings and maybe even your router. This could be your whole problem. IPv6 has all kinds of strange issues and when you are running a mix of IPv4 and IPv6 session you can get very inconsistent results. Most times it is people reporting that some web pages run fine and other runs slow.

Once you are only running IPv4 you can try the pingplotter tests again but be careful about how you read it.

Most times you are better off just using simple constant ping commands. In general you are not going to get anything fixed that is far away from you. You want to test ping to your router ip and to the IP in hop 2. These are the most common points of failure. If there was something wrong with the connection to your house you would see no loss to your router but packet loss to the ISP ip address in hop 2.

Get into the modem and check the power level both down and up. The exact values you need to search for it varies a bit depending on the exact docsis encoding being used. Problem with a bad cable tend to show up in these numbers. The ISP likely has checked these already but some ISP techs are idiots.

 

[vguy95]

You have to be careful about how you interpret pingplotter. Really this tool should have a required training test before they let people use it. They just run it and go "red bad must fix".

In the first pingplot you show no issues at all. Everything you see is testing error. If for example hop 11 actually discards 100% of the traffic you would never see any hop past it. The same as hop 1 losing 50% of the traffic. If you were really losing 50% your connection would be almost totaly unusable. Even 10% makes it very very bad so these numbers can't be true.

The second pingplot is what a bad one looks like. You see .3% packet loss starting in a hop and then continuing all the way to the end including the final destination. Damage caused by a earlier hop will have affect on every hop past it.

In the second case it is going to be your router or your PC causing it. What is much more likely it is something stupid with the way IPv6 is implemented. Try to turn off IPv6 support in your PC nic settings and maybe even your router. This could be your whole problem. IPv6 has all kinds of strange issues and when you are running a mix of IPv4 and IPv6 session you can get very inconsistent results. Most times it is people reporting that some web pages run fine and other runs slow.

Once you are only running IPv4 you can try the pingplotter tests again but be careful about how you read it.

Most times you are better off just using simple constant ping commands. In general you are not going to get anything fixed that is far away from you. You want to test ping to your router ip and to the IP in hop 2. These are the most common points of failure. If there was something wrong with the connection to your house you would see no loss to your router but packet loss to the ISP ip address in hop 2.

Get into the modem and check the power level both down and up. The exact values you need to search for it varies a bit depending on the exact docsis encoding being used. Problem with a bad cable tend to show up in these numbers. The ISP likely has checked these already but some ISP techs are idiots.

Could those problems that you possibly see in the pingplotter be related to the other graphs I showed you here? I'll try to find what you are talking about in the modem and post here again

 

[bill001g]

Hard to say if they are using IPv6 then it could be the same issue.

You IPv4 pingplotter shows no issues. Does not mean there are no issue just the tool does not show any. Could be a very intermittent issue that did not happen while the pingplotter program was running.

 

[vguy95]

Hard to say if they are using IPv6 then it could be the same issue.

You IPv4 pingplotter shows no issues. Does not mean there are no issue just the tool does not show any. Could be a very intermittent issue that did not happen while the pingplotter program was running.

Just so you know, in the past, when I pressured Shaw HARD to fix this issue and they denied it was an issue for a long time, when the guy who works on the infrastructure found some problems and fixed them, those graphs I posted with all the spikes disappeared by like 90%. So, before there was definitely some problems in the node, is there a way for us to diagnose something like that? I mean, is it even possible for us to find noise in the node?

When I do these uploads to anywhere on the internet, it gives those same types of graphs, those spikes downward to 1 Mbps or less

 

[Ralston18]

Uploads.

Target destination?

 

[vguy95]

Uploads.

Target destination?

All sorts of applications, different twitch servers, dummy upload files to speed test websites, you name it, it all does the same thing

 

[vguy95]

Hard to say if they are using IPv6 then it could be the same issue.

You IPv4 pingplotter shows no issues. Does not mean there are no issue just the tool does not show any. Could be a very intermittent issue that did not happen while the pingplotter program was running.

I went into my XB7 router (I think thats what its called) and I couldn't see if there was a way to turn off the ipv6 stuff. Couldn't find any option for that.

I am feeling hopeless. Like I said, in the past, when I had this problem, it ended up being a problem in the node. But Shaw claims theres no problems, but last time, they claimed there was no problems for like 6 months before they found the issue in the node.

Is there any way you could help me figure out whether its in the node or not? Is there any tests we can do? Its the upload thats bugging me because I cant live stream like this.

 

[vguy95]

https://imgur.com/XsoKtAP

View: https://imgur.com/XsoKtAP


Does this help at all or no?

 

[vguy95]

https://imgur.com/YTA2OPf

View: https://imgur.com/YTA2OPf


Any help?

 

[vguy95]

How about this?

https://imgur.com/50PKn1r

View: https://imgur.com/50PKn1r

 

[little_me]

As far as I can read, Bill001g summed up things pretty well.

check to see if it's IPv4 or IPv6 issue by disabling one or other on your computer (or on router or both)
to check router/modem for IPv4 functionality:
run ping 10.0.0.1 -t -4 in command window and check CTRL-break for current statistics occasionally.

to check router/modem for IPv6 functionality:
run ping <insert long to type IPV6 address of router here> -t -6 in command window and check CTRL-break for current statistics occasionally.

the goal is to run ping in background for hour or two at least or until problems appear, especially during/if problems arise.

if pings to 10.0.0.1 have packet loss, it is 99% likely your router/modem and if that is having problems, ALL packets going past it to elsewhere also have to pass through this, packet loss will be hereditary to further stops too.

you once mentioned and one of the screenshots shows 50% packet loss to 10.0.0.1 which heavily points to problems either on your modem or computer.

TLDR; this is a retype of what Bill001g pretty much said, start diagnostics on own end, make sure it works before delving deeper.

and remember to test disabling IPV6 also, some things have still not applied it in working fashion and it can break and/or cause LOTS of issues, including packet loss, latency and massive CPU usage.

 

[vguy95]

As far as I can read, Bill001g summed up things pretty well.

check to see if it's IPv4 or IPv6 issue by disabling one or other on your computer (or on router or both)
to check router/modem for IPv4 functionality:
run ping 10.0.0.1 -t -4 in command window and check CTRL-break for current statistics occasionally.

to check router/modem for IPv6 functionality:
run ping <insert long to type IPV6 address of router here> -t -6 in command window and check CTRL-break for current statistics occasionally.

the goal is to run ping in background for hour or two at least or until problems appear, especially during/if problems arise.

if pings to 10.0.0.1 have packet loss, it is 99% likely your router/modem and if that is having problems, ALL packets going past it to elsewhere also have to pass through this, packet loss will be hereditary to further stops too.

you once mentioned and one of the screenshots shows 50% packet loss to 10.0.0.1 which heavily points to problems either on your modem or computer.

TLDR; this is a retype of what Bill001g pretty much said, start diagnostics on own end, make sure it works before delving deeper.

and remember to test disabling IPV6 also, some things have still not applied it in working fashion and it can break and/or cause LOTS of issues, including packet loss, latency and massive CPU usage.

Thanks so much for the reply. When I went into the router to disable ipv6 I could not find any option to do that. I guess I will google how to disable IPV6 on my own computer and see if I can figure out what to do based on what you said then I'll come back again

 

[vguy95]

As far as I can read, Bill001g summed up things pretty well.

check to see if it's IPv4 or IPv6 issue by disabling one or other on your computer (or on router or both)
to check router/modem for IPv4 functionality:
run ping 10.0.0.1 -t -4 in command window and check CTRL-break for current statistics occasionally.

to check router/modem for IPv6 functionality:
run ping <insert long to type IPV6 address of router here> -t -6 in command window and check CTRL-break for current statistics occasionally.

the goal is to run ping in background for hour or two at least or until problems appear, especially during/if problems arise.

if pings to 10.0.0.1 have packet loss, it is 99% likely your router/modem and if that is having problems, ALL packets going past it to elsewhere also have to pass through this, packet loss will be hereditary to further stops too.

you once mentioned and one of the screenshots shows 50% packet loss to 10.0.0.1 which heavily points to problems either on your modem or computer.

TLDR; this is a retype of what Bill001g pretty much said, start diagnostics on own end, make sure it works before delving deeper.

and remember to test disabling IPV6 also, some things have still not applied it in working fashion and it can break and/or cause LOTS of issues, including packet loss, latency and massive CPU usage.

I disabled IPV6 on my Network (ethernet) and it made no difference. I ran the pings to the ipv4 and while there was the odd 20 ms response, it said there was 0% loss in total.

I STILL see the problem when I do random dummy file uploads/run my Streamlabs OBS software (which uploads) too. Is there not a better way to diagnose this if I KNOW the problems can be seen during an upload?

 

[bill001g]

To which ip did you see 20ms response your router IP?

In general most times it takes spikes closer to 100ms and you have to get many of them to detect it in a game. 20ms most times is undetectable and you have to be careful about small numbers like this , it could just be some error in the testing measurements rather than a actual issue.

If you see this problem to your router I am not sure what it can be. You would commonly see this on say wifi but on ethernet the cable can not really delay traffic. This means it is software on the pc or the router.

If the problem is outside your house even if you have 200ms of latency spikes the ISP will not care. They don't even really guarentee bandwidth with their stupid "up to" disclaimer. They might fix packet loss because that indicates some defective equipment. Packet delays mean something is overloaded and the data is being held in a buffer. ISP would normally have to invest more money to fix a overload condition so will pretend they don't see the problem.

Testing upload is a pain. It is really easy to find things you can download. Upload for your average person is the request sent to a web site which is tiny. Streaming is another but it is a extremely complex data format where many things can go wrong. What would be best i guess is if you could find some place you can for free upload files for cloud storage. You would also need the ability to manually limit the data rate so it does not just use all your upload bandwidth, that would cause latency spikes for sure.

Now there are programs that will blindly transmit data and you could send it to a IP that does not exist but is still a valid IP. Problem is these type of programs can also be used for denial of service attacks so I will no go into details.

 

[little_me]

well, my next step in testing this would be to get the route to where you upload to through tracert and set up ping -t to each step in separate windows

then upload to get the issues.

what should happen is that the ping to steps that have problems should increase and/or get packet loss.

latency itself is most times non-issue for games, especially if it is stable (like 50, 100 or 150) and not fluctuating between 50 and 200.
for streaming, this is even more so.

What I suspect is that your ISP might have (they all do to one extent or other) over-provisioned their main lines too much and sold everyone that 1G/100M connection when they don't have enough capacity for that and their load balancing is having problems.

so... run ping -t's to each step for a bit to see the normal min/max latencies. (this is pretty much what pingplotter does)
then start to upload
see which steps get noticeable increase and/or packet loss.

if problem persists, you could try to limit the upload (the speed) as a test by lowering the resolution you stream at to see if there is a lower bandwidth that stays stable.

limiting speed is not supported by most file transfers as such, which is why I recommend testing with something that can be limited, like streaming resolution/audio quality

 

[vguy95]

To which ip did you see 20ms response your router IP?

In general most times it takes spikes closer to 100ms and you have to get many of them to detect it in a game. 20ms most times is undetectable and you have to be careful about small numbers like this , it could just be some error in the testing measurements rather than a actual issue.

If you see this problem to your router I am not sure what it can be. You would commonly see this on say wifi but on ethernet the cable can not really delay traffic. This means it is software on the pc or the router.

If the problem is outside your house even if you have 200ms of latency spikes the ISP will not care. They don't even really guarentee bandwidth with their stupid "up to" disclaimer. They might fix packet loss because that indicates some defective equipment. Packet delays mean something is overloaded and the data is being held in a buffer. ISP would normally have to invest more money to fix a overload condition so will pretend they don't see the problem.

Testing upload is a pain. It is really easy to find things you can download. Upload for your average person is the request sent to a web site which is tiny. Streaming is another but it is a extremely complex data format where many things can go wrong. What would be best i guess is if you could find some place you can for free upload files for cloud storage. You would also need the ability to manually limit the data rate so it does not just use all your upload bandwidth, that would cause latency spikes for sure.

Now there are programs that will blindly transmit data and you could send it to a IP that does not exist but is still a valid IP. Problem is these type of programs can also be used for denial of service attacks so I will no go into details.

I can upload 75 MB dummy files to testmy.net which is a very good website I used that also plots a graph of the upload (which I posted above).

20ms was recorded once in awhile but 90% of them were 1 ms to the -ping 10.0.0.1 -4 or whatever it was.

But remember, what I said before, was Shaw denied this problem for like 1 year, then some person who works on the infrastructure found it in 1 day. But now, its bad again. They say they see nothing, but even my overall upload to speed test websites (aside from Ookla) show its extremely slow.

 

[vguy95]

well, my next step in testing this would be to get the route to where you upload to through tracert and set up ping -t to each step in separate windows

then upload to get the issues.

what should happen is that the ping to steps that have problems should increase and/or get packet loss.

latency itself is most times non-issue for games, especially if it is stable (like 50, 100 or 150) and not fluctuating between 50 and 200.
for streaming, this is even more so.

What I suspect is that your ISP might have (they all do to one extent or other) over-provisioned their main lines too much and sold everyone that 1G/100M connection when they don't have enough capacity for that and their load balancing is having problems.

so... run ping -t's to each step for a bit to see the normal min/max latencies. (this is pretty much what pingplotter does)
then start to upload
see which steps get noticeable increase and/or packet loss.

if problem persists, you could try to limit the upload (the speed) as a test by lowering the resolution you stream at to see if there is a lower bandwidth that stays stable.

limiting speed is not supported by most file transfers as such, which is why I recommend testing with something that can be limited, like streaming resolution/audio quality

I am a Live Streamer on Twitch. I require approximately 6 Mbps upload to maintain a 1080p stream. The bit rate is set to 6000 -- and the spikes happen intermittently. If you look at some of the graphs I have posted, in some cases the upload dropped to 49 Kbps, yes 49 Kbps ... other times it will drop to 1, 2 or 3 on a 100 upload connection. Generic uploads of dummy files show this same issue on testmy.net (you can plot the graph and see the downwards spikes while uploading a 75mb file). Any real world application seems to show this issue. Inspector twitch tv showed it too (however it seems to be down for quite awhile now, its not working).

You think I should try a ping plotter to the twitch server, is that what you are saying?

 

[bill001g]

If you got 20ms ping to 10.0.0.1 then the problem is inside your house. It is either your pc or your router. Much more likely it is some kind of testing error. If the pc got very busy and did not have time to process the replay from your router then it might say it took 20ms when the data was in the buffer all the time.
This is not actually a network problem directly. It is more why is the pc getting stuck doing something else and what else does it impact.

You do not want to just upload that does no good it is too complex. If I was you ISP I could just blame the server and say its disks where slow and how would you prove different.

What you do is upload and cap the rate at 50mbps. This leave a lot of extra bandwidth unused but you have a much larger constant load than you can generate with something simple with a ping command. What you are looking for is some condition where the problem only occurs when there is load on the line but you still use the simple ping testing tools. Again this is to avoid the ISP saying it is somehow the file server or the network the file server is one. Even though there is other traffic going to that server your actual test traffic is only going to the ISP router.

Your main problem is you have no way to really show it is a actual network problem. All the testing tools say it is not. What that means is either it is not really a network problem or there is something very different about the data stream that the ISP equipment can not handle. The ISP does not actually know what is inside the packets they only see thing like the ip addresses and the packet lengths so it makes it even more complex.

This is where having a network switch that can mirror data ports and separate machine that can capture the traffic is nice. You can then actually look at the data that was sent from your machine. You would know if the data was already damaged when it was offered to the network or if the data was good. You would then if you had full control over the network capture the data again at different point to find it.

You could try to just use wireshark to capture the data as it is put in the ethernet data buffer BUT the wireshark process itself is going to compete for resources on your machine so it could have a impact on the timing stamps in the captured data. You would also have to know the application very well, it is not some magic tools that can find issues like this. You would have to actually look to see if the latency between the data packets was correct. The issue for example is does the application actually send data at 1 packet a second for 10 seconds or does it send 10 packets in 1 second and 0 packets for 9 seconds. Both these give a average rate of 1 packet a second when averaged over 10 second time. The actual application is going to be much more complex but it likely does not actually stream data a a fixed rate when you look at it a extremely detailed level where you can see less than 1ms delays between packets.

Since this appears to be mostly just 1 very complex application it tends to be more likely it is a software issue rather than a network problem. It can be a network issue but you are now back to figuring out what is different about that data stream. It is more how do you actually know if the data is good as it leaves your machine, so the damage reported by the server on the far end occurred between the software and the ethernet port on your machine rather than some other device in the path damaging it. It very well can be but all the simple tools and the tools the ISP have do not see the problem.

 

[little_me]

I am a Live Streamer on Twitch. I require approximately 6 Mbps upload to maintain a 1080p stream. The bit rate is set to 6000 -- and the spikes happen intermittently. If you look at some of the graphs I have posted, in some cases the upload dropped to 49 Kbps, yes 49 Kbps ... other times it will drop to 1, 2 or 3 on a 100 upload connection. Generic uploads of dummy files show this same issue on testmy.net (you can plot the graph and see the downwards spikes while uploading a 75mb file). Any real world application seems to show this issue. Inspector twitch tv showed it too (however it seems to be down for quite awhile now, its not working).

You think I should try a ping plotter to the twitch server, is that what you are saying?

Yes, during said upload problem time when you are test-streaming.

this is to possibly rule out your computer and/or router/modem out of the equation.

And lowering resolution of stream (720P, 480P 320P) was to see at what bitrate network/computer/modem can handle the data.
It does not mean you should stick to said resolutions and just accept it, it's just a method to add certain amount of traffic to the background in addition to the pings to cause load on the network devices and possibly see which one of them drops out first and/or last and at what bitrate.

and as a random test out of curiosity, what does speedtest.net say about your speeds?

 

[vguy95]

If you got 20ms ping to 10.0.0.1 then the problem is inside your house. It is either your pc or your router. Much more likely it is some kind of testing error. If the pc got very busy and did not have time to process the replay from your router then it might say it took 20ms when the data was in the buffer all the time.
This is not actually a network problem directly. It is more why is the pc getting stuck doing something else and what else does it impact.

You do not want to just upload that does no good it is too complex. If I was you ISP I could just blame the server and say its disks where slow and how would you prove different.

What you do is upload and cap the rate at 50mbps. This leave a lot of extra bandwidth unused but you have a much larger constant load than you can generate with something simple with a ping command. What you are looking for is some condition where the problem only occurs when there is load on the line but you still use the simple ping testing tools. Again this is to avoid the ISP saying it is somehow the file server or the network the file server is one. Even though there is other traffic going to that server your actual test traffic is only going to the ISP router.

Your main problem is you have no way to really show it is a actual network problem. All the testing tools say it is not. What that means is either it is not really a network problem or there is something very different about the data stream that the ISP equipment can not handle. The ISP does not actually know what is inside the packets they only see thing like the ip addresses and the packet lengths so it makes it even more complex.

This is where having a network switch that can mirror data ports and separate machine that can capture the traffic is nice. You can then actually look at the data that was sent from your machine. You would know if the data was already damaged when it was offered to the network or if the data was good. You would then if you had full control over the network capture the data again at different point to find it.

You could try to just use wireshark to capture the data as it is put in the ethernet data buffer BUT the wireshark process itself is going to compete for resources on your machine so it could have a impact on the timing stamps in the captured data. You would also have to know the application very well, it is not some magic tools that can find issues like this. You would have to actually look to see if the latency between the data packets was correct. The issue for example is does the application actually send data at 1 packet a second for 10 seconds or does it send 10 packets in 1 second and 0 packets for 9 seconds. Both these give a average rate of 1 packet a second when averaged over 10 second time. The actual application is going to be much more complex but it likely does not actually stream data a a fixed rate when you look at it a extremely detailed level where you can see less than 1ms delays between packets.

Since this appears to be mostly just 1 very complex application it tends to be more likely it is a software issue rather than a network problem. It can be a network issue but you are now back to figuring out what is different about that data stream. It is more how do you actually know if the data is good as it leaves your machine, so the damage reported by the server on the far end occurred between the software and the ethernet port on your machine rather than some other device in the path damaging it. It very well can be but all the simple tools and the tools the ISP have do not see the problem.

I told you, that this upload problem is detected by inspector twitch, by testmy.net, by streamlabs OBS, by pretty much anything that can graph an upload. I have tried other servers too and can mimic the same problem. How can someone blame all of these different servers, all different applications, different websites that produce the same problem? I also told you that in the past, when there were these upload spikes Shaw denied the problem for like an entire year, and out of no where one of the people who works on the infrastructure found an issue, and fixed it, called me, and over 90% of the problems were immediately gone. Now its back, but I'm going through the same process of denial.

Generic uploads to testmy.net are clocking in at 7 Mbps now when just 3-4 months ago it averaged 35+ and that was even slow for my 100 upload.

 

[vguy95]

Yes, during said upload problem time when you are test-streaming.

this is to possibly rule out your computer and/or router/modem out of the equation.

And lowering resolution of stream (720P, 480P 320P) was to see at what bitrate network/computer/modem can handle the data.
It does not mean you should stick to said resolutions and just accept it, it's just a method to add certain amount of traffic to the background in addition to the pings to cause load on the network devices and possibly see which one of them drops out first and/or last and at what bitrate.

and as a random test out of curiosity, what does speedtest.net say about your speeds?

speedtest.net shows my speeds are normal. It blows my mind that any person who does tech related things uses this website. Ookla software discards 30% of your slowest speeds, uses multithreading to literally open up another pipe to inflate internet speeds and hide problems in the main line, and you connect to local servers, which are often sponsored by Ookla and the ISP you use, and they are given priority access to these servers. It is the biggest gimmick of a 'tool' you could possibly find on the internet, it is nothing but pure garbage that actually hides internet problems not solves them.

 

[bill001g]

I told you, that this upload problem is detected by inspector twitch, by testmy.net, by streamlabs OBS, by pretty much anything that can graph an upload. I have tried other servers too and can mimic the same problem. How can someone blame all of these different servers, all different applications, different websites that produce the same problem? I also told you that in the past, when there were these upload spikes Shaw denied the problem for like an entire year, and out of no where one of the people who works on the infrastructure found an issue, and fixed it, called me, and over 90% of the problems were immediately gone. Now its back, but I'm going through the same process of denial.

Generic uploads to testmy.net are clocking in at 7 Mbps now when just 3-4 months ago it averaged 35+ and that was even slow for my 100 upload.

So I will put my idiot ISP hat on now.

Please prove that the data that is received by all these programs was actually sent out of your machine correctly. Ie how do you prove that the data was not already damaged before it was even sent out the ethernet port of your machine.

Now if there is some kind of test server you could setup in your house that could receive the stream and analyze the data format it would be pretty easy to say see there is no frame loss in the house and this is the same data I am sending outside the house.

Until you find someway to basically prove some kind of problem the ISP can correctly say "it is a application issue". Even your own testing shows you only see issues with this one application every test tool you run shows no issues.

So me not having use OBS I can't say much. Are there any fake test "streams" where you could play some kind of pre encoded video file so you are not use OBS on live data. In effect you would be uploading a data file just using the transport part of the software rather than the complex encoding.

What I would suspect if this is a real network issue it is some kind of hardware/firmware issue in the ISP equipment. This would be similar to the intel PUMA issue years ago in cable modems. There was a bug that pretty much only certain game traffic would hit. No other traffic was affected. There were many more gamers than you have streamers so it was simpler to isolate it to certain models of modems. In this case if the problem is really equipment related it is likely some hardware revision of some board in the ISP equipment where only certain units are affected.

I still think your first step is to find a way to confirm that the data is actually correct as it leaves your machine. Then you need to find a way to help the ISP find this. I mean lets say you have 100% access to the ISP equipment what would you check. Just like you know nothing about their equipment they know nothing about data streaming and it really appears it is only that kind of traffic being affected.

 

[little_me]

speedtest.net shows my speeds are normal. It blows my mind that any person who does tech related things uses this website. Ookla software discards 30% of your slowest speeds, uses multithreading to literally open up another pipe to inflate internet speeds and hide problems in the main line, and you connect to local servers, which are often sponsored by Ookla and the ISP you use, and they are given priority access to these servers. It is the biggest gimmick of a 'tool' you could possibly find on the internet, it is nothing but pure garbage that actually hides internet problems not solves them.

and yet, being such "garbage" it shows same results as testmy.net for me.
as for using multithreading, it's non-issue, it's goal is see what is the maximum speed your connection allows, not what you normally can get with single thread. (difference here can point to problems on computers CPU power)
connect to local servers? by default, yes. it has a button to choose from list of them. or search from anywhere in world.
my result is same to local, europe and US, including shaw in canada.

My goal was to get you to test following things:
packet loss between you and twitch with streaming load and without.
different streaming loads to see where actual working upload speed is
find out what the testable maximum speed of connection is.

and rule out your computer and router, both of which are easy targets to blame for the ISP.
but since I know nothing, I'll stop here.