R1CH Twitch Test (Most servers 0, all bad)

You have very high Jitter and packetloss.
thank you. it's very frustrating when i'm trying to stream, i pay for the best package they offer and i'm constantly hearing "everything looks good on our end" or "you're expereincing issues due to covid and people working from home" but my internet prices are the same and it's not working for what i'm trying to do. it's starting to sound more like an excuse and it's never getting fixed.
 

FerretBomb

Active Member
I've also tried to run a trace route to twitch asand my results were "reports: Destination net unreachable."
Yes, that's because they have ICMP traffic ignored.
With pingplotter, you'd test to the domain. So abc123.twitch.tv. Let it run while you stream for a while, it'll build up an analytic spread. The bad node will PROBABLY stand out like a sore thumb with a huge bar (again, the ingest server hop will show 100% packet loss, but that's expected).
 
Yes, that's because they have ICMP traffic ignored.
With pingplotter, you'd test to the domain. So abc123.twitch.tv. Let it run while you stream for a while, it'll build up an analytic spread. The bad node will PROBABLY stand out like a sore thumb with a huge bar (again, the ingest server hop will show 100% packet loss, but that's expected).

okay so i'd put in rtmp://live-iad05.twitch.tv/ and let it run? dropped you a follow! thanks for your help and hopefully i can figure this out
 
also will this work with a twitch bandwidth test or should i actually go live? sorry for all the questions im learning as we go. it's been stressful.
 

TryHD

Member
Yes, that's because they have ICMP traffic ignored.
With pingplotter, you'd test to the domain. So abc123.twitch.tv. Let it run while you stream for a while, it'll build up an analytic spread. The bad node will PROBABLY stand out like a sore thumb with a huge bar (again, the ingest server hop will show 100% packet loss, but that's expected).
that will not give you any usefull data. Since ICMP is dropped at the destination you can't tell if the routers on the way simply depriorize ICMP or if there is real packetloss. Also since async routing is the norm today you would have to do that from twitch to your homerouter too at the same time. So this complete test helps nothing.
 
that will not give you any usefull data. Since ICMP is dropped at the destination you can't tell if the routers on the way simply depriorize ICMP or if there is real packetloss. Also since async routing is the norm today you would have to do that from twitch to your homerouter too at the same time. So this complete test helps nothing.

man, i appreciate everyones help! this is so confusing/frustrating. all i want to do is have a decent enough connection for a solid stream. i literally pay for the best package my ISP offers and i'm stuck doing this stuff.
 

TryHD

Member
Actually you don't need more to know. What you tested did already show that your ISP is the cause of your problems, it is now their part to fix it.
 

FerretBomb

Active Member
that will not give you any usefull data. Since ICMP is dropped at the destination you can't tell if the routers on the way simply depriorize ICMP or if there is real packetloss. Also since async routing is the norm today you would have to do that from twitch to your homerouter too at the same time. So this complete test helps nothing.
That's incorrect. Pingplotter tracks the ping to each individual node in the route path, not just to the final node itself. You absolutely can and will see packet loss to each node, as well as a ping timing spread that can heavily suggest which hop in the route is having a problem, if it's an issue somewhere in your routing path to the destination.
Please do not give misinformation like that if you are not conversant with the tools in question.
 

FerretBomb

Active Member
Yes please do so to you.
Giving tips while you don't understanding what data the tools you suggest give you.... man
Maybe you should start with the basics and read later this https://www.netbraintech.com/blog/limitations-of-traceroute/ before providing more false information. Because you clearly lack knowledge in this field.
I was a network engineer for 10 years, working on-site deployments, troubleshooting, and in NOCs.
I was NOT advising the use of traceroute.
Would you like to continue making yourself look foolish?
 

TryHD

Member
They have the same limitations regarding packetloss, they use both ICMP, they both need to be done from both sides to find usefull things.
So working for 10 years as network engineer and still know nothing about networking and somebody like that calls me fool. Haha thanks for the laugh. But seriously dude, if you want to give tipps know atleast what you talk about.
You don't even need to know anything about networking, logic is enough to see the flaw.
 

FerretBomb

Active Member
They have the same limitations regarding packetloss, they use both ICMP, they both need to be done from both sides to find usefull things.
So working for 10 years as network engineer and still know nothing about networking and somebody like that calls me fool. Haha thanks for the laugh. But seriously dude, if you want to give tipps know atleast what you talk about.
You don't even need to know anything about networking, logic is enough to see the flaw.
Again, this is NOT USING TRACEROUTE. I'd recommended a separate tool called Pingplotter, which pings each host in the route individually, tracking response time spread and packet loss of the traffic to/from each individual node over time, NOT only to the endpoint. This allows rough-identifying a problem node on a routing chain, even if the final hop has ICMP traffic black-holed, as intermediary links with issues will generally show problems with returning signaling responses, as well as routing traffic.

You really, really should shut your mouth. It's just making it clear that you have no knowledge on how to actually troubleshoot a network issue, the longer you talk.
 
I didn't mean for this to become more than it needs to be. Apologies if I did. I'm just trying to get this fixed and i appreciate all the help.
 

FerretBomb

Active Member
I didn't mean for this to become more than it needs to be. Apologies if I did. I'm just trying to get this fixed and i appreciate all the help.
Not your fault at all, man. Don't worry about it. :)

Again, I'd recommend running Pingplotter pointed at your chosen ingest server, and actively streaming for 10 minutes or so to place the connection under real load. Then look at Pingplotter's results. It will give you a decent idea of where the problem is happening. Once you know where the issue is located in the routing chain, the next-steps vary from there. You can screenshot the window and paste it here, but it should be fairly obvious with a R1ch test quality score of zero. Either lots of dropped packets at a point before the last entry, or one with a BIG latency bar is most common.

If it's on your LAN, that's something you can control.
If it's on your ISP's intranet up to their backbone link, that's something you can yell at your ISP about and point to the specific problem node. Fortunately, with all of the results at zero, it's likely one of these two.
If it's in the middle of the route after exiting your ISP, it's a lot harder to fix. But normally you'll only see one or two quality-zero results if that were the case.
 
Not your fault at all, man. Don't worry about it. :)

Again, I'd recommend running Pingplotter pointed at your chosen ingest server, and actively streaming for 10 minutes or so to place the connection under real load. Then look at Pingplotter's results. It will give you a decent idea of where the problem is happening. Once you know where the issue is located in the routing chain, the next-steps vary from there. You can screenshot the window and paste it here, but it should be fairly obvious with a R1ch test quality score of zero. Either lots of dropped packets at a point before the last entry, or one with a BIG latency bar is most common.

If it's on your LAN, that's something you can control.
If it's on your ISP's intranet up to their backbone link, that's something you can yell at your ISP about and point to the specific problem node. Fortunately, with all of the results at zero, it's likely one of these two.
If it's in the middle of the route after exiting your ISP, it's a lot harder to fix. But normally you'll only see one or two quality-zero results if that were the case.

ISP just left my house. He ran tests from his meter and it showed 0.8 packet loss and said all the numbers are good. He said "we can look at the modem and see if the numbers are good, but anything past that or trying to connect to servers (twitch) they can't do anything. I'll try pingplotter, but i honestly have no idea what i'm looking for.

so i'd basically put these below there without the "/app/{stream_key}" correct? (sorry for my questions i just want to get this done correctly) should i stream while doing this? or could i do a twitch inspector test or just not stream at all?

US East: Ashburn, VA (5)
rtmp://live-iad05.twitch.tv/app/{stream_key}

US East: Ashburn, VA (3)
rtmp://live-iad03.twitch.tv/app/{stream_key}
 

TryHD

Member
Again, this is NOT USING TRACEROUTE. I'd recommended a separate tool called Pingplotter, which pings each host in the route individually, tracking response time spread and packet loss of the traffic to/from each individual node over time, NOT only to the endpoint.
Man what do you thing traceroute does? Excatly the same without doing it over time.
This allows rough-identifying a problem node on a routing chain, even if the final hop has ICMP traffic black-holed, as intermediary links with issues will generally show problems with returning signaling responses, as well as routing traffic.
It does not
You really, really should shut your mouth. It's just making it clear that you have no knowledge on how to actually troubleshoot a network issue, the longer you talk.
Yes it makes it very clear that YOU don't have any knowledge of the topic and try to shutup others so your lack of knowledge doesn't get exposed.
 
I went to my moms house to do a twitch test after the tech lift my house. She has 40down and 6 upload...ON WIFI. she doesn't have a direct connections..i didn't have a single 0 quality connection. clearly theres an issue and my ISP doesn't want to do anything about it.
 

FerretBomb

Active Member
Man what do you thing traceroute does? Excatly the same without doing it over time.
Exactly. Traceroute does it three times per hop. It does not aggregate data on each node over time, which is what makes PP useful as a diagnostic tool separate from traceroute, and is exactly the thing that can point out a problem node. It's why Pingplotter exists, and why network professionals use it instead of just whacking traceroute at the problem.
Again. I worked as a network engineer in the industry for 10 years. CCNA, MCSE, hell I think I still have my CNE somewhere, back from when people actually used Novell. Christ, this must be how doctors feel 'debating' with anti-vaxxers.

I went to my moms house to do a twitch test after the tech lift my house. She has 40down and 6 upload...ON WIFI. she doesn't have a direct connections..i didn't have a single 0 quality connection. clearly theres an issue and my ISP doesn't want to do anything about it.
Did you run Pingplotter as advised? Do you have a screenshot of it from your connection? Again, that's the first step, seeing where the problem is actually occurring in the chain.
It tends to motivate ISPs if you can say 'I am showing a lot of packet loss originating at [IP] which appears to be a routing node on your intranet' as opposed to 'my connection is unstable'. The latter they can brush off.
 
Top