That strange issue with the internet that took three years to fix
That strange issue with the internet that took three years to fix
Do you want to check out this picture? Here is the link: https://imgur.com/50PKn1r. Also, see this one: https://imgur.com/50PKn1r
As far as I know, Bill001g gave a good summary. Check if the problem is IPv4 or IPv6 by turning off one type on your computer (or on the router or both) to see which one works: run ping 10.0.0.1 with settings for IPv4 in the command window and keep an eye on statistics while holding CTRL-break. To check for IPv6, run ping a specific long IP address of the router using IPv6 settings (-t -6), again watch the stats when you hold CTRL-break. The goal is to keep pinging in the background for a few hours or more just so you can see if things break later. If there are packet losses when trying to connect to 10.0.0.1, it's very likely your router or modem is the problem. If they aren't working well, all packets going past them also need to pass through and will be lost too, which means any further stops will have issues. You once mentioned a screenshot that shows 50% packet loss to 10.0.0.1, so this strongly points to either your modem or the computer having problems. TLDR; this is basically what Bill001g said again: start diagnosing on your own side first and make sure everything works before going deeper. Don't forget to test turning off IPv6 too because some things haven't been fixed yet, which can cause packet loss, high latency, and a huge load on the CPU.
Thanks a lot for getting back to me. When I tried turning off IPv6 inside the router, I couldn't find any settings for it. Maybe I should just look online and try my own guess about how to turn that off on my computer so I can decide what to do next based on your advice, then I'll come back later with more questions.
I turned off IPv6 on my network and it didn't help at all. When I poked things with ping, the 20 ms delay was still there but the server said no data loss in total. The problem keeps showing up even when I send random test files or run Streamlabs OBS to upload stuff. Is there a better way to spot this if I already know it shows up during uploads?
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 guarantee 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 an 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.
well, my next step in testing this would be to get the route to where you upload through tracert and set up ping -t to each stop on separate windows then start uploading to find out what's wrong. what should happen is that the pings to steps with problems will go up or get dropped. latency itself isn't usually a big deal for games, especially if it stays steady (like 50, 100, or 150) and doesn't jump around between 50 and 200. this is even more true when streaming. I think your ISP might have over-provisioned their main lines too much and sold you a gigabit or 100 megabit connection that they can't actually handle, and their load balancing system has problems. so... run ping -t's to each step for a while to see the normal min/max latencies. (this is basically what pingplotter does) then start uploading and see which steps get noticeable increases or drops in packets. if the problem keeps happening, you could try limiting your upload speed as a test by lowering the resolution you stream at to see if there is a lower bandwidth that stays steady. limiting speed isn't supported by most file transfers like this, so I recommend testing with something that can be controlled, like streaming quality or audio.
I can send up to 75 MB of fake files to testmy.net because it is a very good website I used before that also shows a graph for the upload (which you saw above). Sometimes I record about 20ms, but in most cases it takes just 1 ms when hitting -ping 10.0.0.1 or whatever that address is. But wait, what I said earlier was wrong because Shaw denied this problem for about a year. Then someone who works on the internet found out about it in just one day. Now it's happening again. They say they see nothing, but even my overall upload speed tests through other sites (like Ookla) show it is very slow.
I am a Live Streamer on Twitch. I need about 6 Mbps upload speed to keep a 1080p stream going. The bit rate is set to 6000 -- and sometimes there are spikes in the connection. If you check some graphs I posted, they show that sometimes my upload drops down to just 49 Kbps, yes, exactly 49 Kbps ... other times it might drop all the way down to 1 or 2 on a 100 Mbps internet line. Generic uploads of dummy files show this same problem when testing on testmy.net (you can plot the graph and see the big drops while uploading a small file). Any real-world app seems to have this issue too. Inspector Twitch TV also showed it up, but it stopped working for a long time now, so I don't think that's the real issue anymore. Do you think I should try a ping plotter to the Twitch server? Is that what you are suggesting?
If you get a 20ms ping to 10.0.0.1, something is wrong inside your house. It's probably your computer or your router. A lot more likely it is just a testing error. If your PC gets too busy and can't finish processing the data from your router before it waits in the buffer, it might say it took 20ms even though the data was waiting all along. This isn't really a network problem by itself. It's asking why your PC keeps doing something else while waiting. You don't want to just upload that and leave it there because it's too complicated to fix easily.
If I were you, my ISP would blame the server and say its hard drives are slow. How would you prove that? Instead, you upload a file and set a speed limit of 50mbps. This leaves a lot of extra bandwidth unused but gives you a huge constant load compared to just typing a ping command. You need something where the problem only shows up when there is traffic on the line but you still use simple tools like ping. Why do this? Because that way, even though other users are using your server, your test data goes straight to the ISP router and doesn't get mixed with their traffic.
The real issue here is that you have no clear way to prove it's a network problem. All those testing tools say nothing wrong happened. That means either there isn't really a network problem, or something different about your data stream than what the equipment on your side can handle. Your ISP doesn't actually see what's inside the packets; they only see IP addresses and packet sizes. It gets even messier because of that. Having a switch that bounces copies of data to separate machines is helpful. You can then look at the actual data that left your machine to see if it was already damaged when sent over the network or if it stayed good throughout everything in between.
You could use Wireshark to catch the data right as it gets put into the Ethernet buffer, but the Wireshark program itself uses up lots of resources on your computer, which might mess up the timing stamps in what you capture. You also need to know your application well because not all magic tools can find these problems by themselves. You'd have to check if the delay between data packets was actually correct. For example: does your app send 1 packet every second for 10 seconds, or does it send 10 packets in a second and nothing else for the other 9 seconds? Both of those look like 1 packet per second when you average them over 10 seconds.
But the actual app is much more complex. It probably doesn't stream data at a fixed rate if you zoom in too closely on tiny delays, maybe less than 1ms between packets. Since this seems mostly just one very complex application, it's likely a software issue rather than a network problem. It can be a network issue, but now you have to figure out what makes that data stream different. You need to know exactly how much damage the server reports on the far end happened after leaving your machine versus some other device in the path hurting it. While this is possible, all the simple tools and whatever the ISP has don't see the actual problem here.