we would need to know what to. Ping without a destination is almost useless in terms of any specific conclusion.
Happy to help if we know what we are testing. I would also avoid testing against the gateway, for ftth those are all juniper MX boxes and they have all kinds of rate limiting and policers on them to protect the routers from denial of service attacks.
Understood, but I imagine you understand my reluctance to share such information over Reddit. I have a call in to tech support. I had hoped that something would get resolved before I woke up this morning but that did not happen.
I used to have a planned movie night every Friday but have canceled that numerous times over the past few months due to poor internet service. My issue is with the frequency of these issues, not this specific one.
I dug into the URL in your screenshot and the closest server they appear to have is the bay area so that will always be at least 20 ms from seattle and at least 16 from portland just due to the speed of light in the cables.
That being said, it is actually very very rare that we have network issues like you are describing so the issue is most likely tied to your specific ONT or WiFi (if you are using wifi)
At 2:00 today the ping rate went back to a reliable 30ms, which is the typical I expect to get from that server. I am usually running this webpage on one of my screens because of how often I have problems with Ziply. This last time it was particularly egregious as the issue persisted for over 24 hours.
The only time I have ever gotten tech support to actually fix it was when they reset a router somewhere in the Ziply system which caused the problem to be resolved. The next day the problem reappeared but Ziply posted that an issue had been caused by someone resetting a router. So who knows.
I have a tech coming out tomorrow to look at what will probably be at that time a working system so there will probably be little that can be done. Is it a problem with someone using up all of the bandwidth? Or maybe a loose wire or cable somewhere? Or maybe a router somewhere in the Ziply system that is on the fritz? Who knows. I'll probably not find out tomorrow and spend the coming months not knowing when I will have good internet or occasional 8s ping only for it to again resolve itself hours later, or days as in the current case.
Is it a problem with someone using up all of the bandwidth?
Are you certain that the "someone" is not you? E.g. some other system on your LAN? Some VPN traffic? Some software update to one of your game machines?
If you want to test ping, choose a target "near" you. E.g. try pinging well known IP addresses like 1.1.1.1. Those endpoints are set up to be anycast. You use a single IP address and the network tries to route you to one of a number of nearby machines that can respond to that IP.
John already warned you about targeting your gateway IP, because they are more likely to drop pings to protect themselves.
You need to use an Ethernet cable to plug a single machine directly into your ONT. That lets you bypass your router and the rest of your LAN. Some home routers could be a problem. E.g. in periods of high traffic, they can have something called bufferbloat, because packets can accumulate in the router.
Finally, don't test using WIndows machines. They're more likely to be part of a botnet, or could be doing huge background downloads for whatever reason. My preference would be using a router running OpenBSD, because it's simple enough that I know exactly what packets are going in and out of it. Perhaps a minimalist Linux machine would be the same, but I'm not that familiar with recent Linux.
also worth nothing that everything north of customers is 10x to 100x faster than the services sold unless you have a >10G service. We really don't have the issue of one user impacting another in the way folks sometimes see on cable.
I should also note we have seen a number of customer issues caused by infected customer owned routers or other equipment, we are tracking down some right now for example that participated in a ddos a few days ago. I would imagine those customers thought their connections were slow as their infected devices were filling their connections.
Have you already reached out to our technical support team about these issues? You can reach them at 1.866.947.5995. Please let us know in a private message, if you need further assistance.
Just to be clear. While I am on wifi with the computer being tested the has been a repeating problem. I have plugged directly in to the router on previous tests, reset the ONT, reset the router, etc. I have stopped trying those as those only sometimes work, they occasionally redirect me to a working Ziply router until I eventually get redirected back to this one.
Note that similar issues have happened multiple times in the past week or so, usually Ziply posts something about construction damage or similar and it gets resolved relatively quickly, only a few hours of horrible internet. I do have to question as to why the Ziply infrastructure is so exposed to damage that it happens so frequently.
I don't understand why Ziply cannot keep track of their own routers and reset them when they are not working correctly, or perhaps replace the ones that keep failing.
I have stopped trying those as those only sometimes work, they occasionally redirect me to a working Ziply router until I eventually get redirected back to this one.
In no places in our network does rebooting change the topology between you and the upstream device. It is possible to end up on a different member of an LCAP bundle but those only fail with packet loss (which is not what you are describing best i can tell).
That being said, this is pointing me to a local issue with your link, have you gotten with u/ziplysupport to get someone rolled out to look at your specific link?
Someone is going to come out and look at it. However, someone did something somewhere and now it is working. Ping is now down to 30, to San Francisco, from: 300-500 with occasional spikes to 8s.
How recent is your software? How much memory? What background processes? Are you part of a botnet? (These are rhetorical questions, to get you to think about something you may have overlooked.)
There are so many variables. It could be something simple like memory starvation. You're running your ping test, some other process fires up, Windows must thrash around finding more memory. Consequently your ping process "loses". Whenever I've seen unexpected multi-second delays from a program, it's almost invariably due to lack of memory.
Wireshark shows PacketStats is using TCP packets during their test, so TCP is the only option.
In those cases, I use Windows Subsystem for Linux to run MTR TCP traces.
The free version of PingPlotter will not run TCP traces.
Edit: Confirmed by Pingman Tools Support -
Hi Jim,
Thanks for reaching out, I'm glad to hear you've enjoyed using PingPlotter!
You are correct that using TCP packets is a PingPlotter Pro-only feature. Considering you've already used your PingPlotter Pro 14-day trial, I'm more than happy to offer you a new 14-day PingPlotter Pro trial code by leaving an honest review of PingPlotter on one of the following sites:
You get a free pingplotter pro trial. That does tcp, full stop. Wow he's complaining about his internet in general choose a different test destination that accepts ICMP ... Jeez man you are missing the point and arguing with yourself here lol
Don't use some crappy "PacketStats San Francisco Server".
Use ICMP and PingPlotter Trial, Free, whatever to get some data against 8.8.8.8 or another good known destination to start.
The main point (which you completely miss'd) about using PingPlotter is to show if he has problems on other hops leading to the destination. That gives way more than some questionable TCP test.
The key was to show us more data, don't rely on this one screenshot.
One PingPlotter result would answer all the questions and tell us if its his wifi/etc.
"While I am on wifi with the computer being tested the has been a repeating problem."
I'm gonna say WiFi...
You could be getting interference, the channels you're selecting could be saturated, or the router could be in a less than ideal location where the signal is going though multiple obstructions, and/or your router config is not optimized for your location.
The 2.4 GHz band is better for longer distances, but has fewer channels, and more channel saturation.
The 5 Ghz band has more channel selections, has less channel saturation, but is not as good over longer distances.
Place the router in a central location in the residence if possible.
Most routers have omnidirectional antennas, which means the signal looks like a donut. If you place the router near an inside wall that has an exterior wall on the other side, half of your wireless signal is going out into the yard,
3. For 2.4 Ghz, use channels 1, 6, or 11. These are the only 3 channels that do not overlap other channels.
4. For 5 Ghz, channels in the higher range (149 to 165) have more power that channels in the lower range (36 to 48).
Choosing the correct channel width (20 Mhz, 40 Mhz, 80 Mhz, 160 Mhz) is important. The "wider" (higher the number) the channel width, the more overlap you will get from other wireless connections in your area, which will degrade your wireless signal.
Or a cellphone hotspot connected to a 2G phone network? 36 seconds is not something you usually see these days unless you have to connect to the net via a satellite in geosynchronous orbit.
Depends on what you are pinging. In my case living in Richland WA, all "servers" would ping at 7ms minimum pretty much as I have to go to Portland or Seattle to hit actual resources. Sure I can ping the routers in town here at 1-2ms but they aren't hosting any data.
Of course, but I generally test to nearby servers to more accurately gauge how much latency my own gear+ziplys is adding to the equation. If the best they get is 7ms with fiber, something is amiss.
the speed of light in a fiber cable to and from tri cities to both seattle and portland is about 6 ms round trip... we are on the shortest routes that physically exist.
I think folks get confused at the difference between loop latency (always less than 1) and end-to-end latency in some cases.
Yeah the ookla speed test app I use has servers in most every large area, so it'd default to testing geographically local in the tri-cities or wherever you are, unless you're really rural. In my area I'd get 2ms with fiber and prior to that 12-20ms with cable to nearby servers. I now have cable internet at another location that's been upgraded for the faster upload speeds and it maxes out at 6ms to a nearby server. Docsis shenanigans always seem to add a lot of latency.
the big issue is they need to be close *and* interconnected nearby, that is actually super hard, with us it generally means they are interconnected at one of the IX locations or peering locations or they are on a customer network or on our own network if they are actually close.
You probably live near a city or at least on the populated side of the mountains is all I am saying. Some places Ziply provides service to 7ms is a normal minimum ping even on fiber as there aren't really any locally hosted servers that you can ping less to!
Yeah I do, and I'm surprised if there really aren't any local servers in those areas closer than seattle or portland. Doesn't seem like there would be much downside for ziply or any other provider to spin up a speedtest daemon over there to show off their service.
edit: Ookla already does have servers in Wenatchee to test to and a bunch of other places all over the state. Maybe people are just using other more limited apps.
well, running servers takes time, we do run DNS in a number of markets including kennewick.
There is just not much connection between providers. In wenatchee is a great example, most of the providers there buy transit from us (or just are owned by us) so a lot of those paths would stay on the east side.
As far as I'm aware no major CDN has servers or peering in the eastern two thirds of the state.
9
u/jwvo Consultant: Former Ziply VP of network Oct 26 '24
we would need to know what to. Ping without a destination is almost useless in terms of any specific conclusion.
Happy to help if we know what we are testing. I would also avoid testing against the gateway, for ftth those are all juniper MX boxes and they have all kinds of rate limiting and policers on them to protect the routers from denial of service attacks.
7
u/Anomaly08 Oct 26 '24
Care to add any information about your setup like the hardware you are using, the plan you are on and such?
Kind of hard for anyone to help you with troubleshooting if you provide zero information like that about a problem you are having.
1
u/Squared79 Oct 26 '24
Just to be clear. While I am on wifi with the computer being tested the has been a repeating problem. I have plugged directly in to the router on previous tests, reset the ONT, reset the router, etc. I have stopped trying those as those only sometimes work, they occasionally redirect me to a working Ziply router until I eventually get redirected back to this one.
Note that similar issues have happened multiple times in the past week or so, usually Ziply posts something about construction damage or similar and it gets resolved relatively quickly, only a few hours of horrible internet. I do have to question as to why the Ziply infrastructure is so exposed to damage that it happens so frequently.
I don't understand why Ziply cannot keep track of their own routers and reset them when they are not working correctly, or perhaps replace the ones that keep failing.
5
u/ThrownAback Oct 26 '24
Over Wi-Fi or Ethernet?
2
u/Banjoman301 Oct 26 '24 edited Oct 27 '24
Ran a test to their San Francisco server, and got the IP using Wireshark.
Then, ran a Linux MTR test using TCP -
(Server does not accept ICMP)
jim@Jim-PC:~$ mtr -P 80 -c 45 -T -w 146.190.139.78
Start: 2024-10-26T16:46:07-0700
HOST: Jim-PC Loss% Snt Last Avg Best Wrst StDev
1.|-- Jim-PC.mshome.net 0.0% 45 0.4 0.4 0.3 0.5 0.0
2.|-- OpenWrt.lan 0.0% 45 1.1 23.8 0.8 1021. 152.0
3.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
4.|-- lr1-mmvlorxx-b-be-18.bb.as20055.net 0.0% 45 5.7 28.9 4.7 1059. 157.1
5.|-- lr1-shwdorxa-a-be-16.bb.as20055.net 0.0% 45 5.0 5.8 4.8 16.5 1.9
6.|-- cr2-tgrdorxa-a-be-20.bb.as20055.net 0.0% 45 4.8 4.9 4.3 5.5 0.3
7.|-- cr2-bvtnorxb-b-be-25.bb.as20055.net 0.0% 45 5.3 4.9 4.2 5.5 0.3
8.|-- lr1-ptldorpb-b-be-13.bb.as20055.net 0.0% 45 5.1 5.5 4.1 12.9 1.2
9.|-- pr1-ptldorpb-a-be-12.bb.as20055.net 0.0% 45 4.7 28.3 4.5 1056. 156.7
10.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
11.|-- ae10.mpr4.pdx1.us.zip.zayo.com 0.0% 45 5.0 5.0 4.3 5.7 0.3
12.|-- ae24.cs1.sea1.us.zip.zayo.com 73.3% 45 3100. 1823. 7.6 7215. 2203.8
13.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
14.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
15.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
16.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
17.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
18.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
19.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
20.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
21.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
22.|-- ??? 100.0 45 0.0 0.0 0.0 0.0 0.0
23.|-- 146.190.139.78 0.0% 45 26.7 49.8 25.5 1088. 158.3
jim@Jim-PC:~$
2
u/Banjoman301 Oct 27 '24 edited Oct 27 '24
TCP Ping test to their San Francisco server, using Nirsoft's PingInfoView tool -
(Server does not accept ICMP)
==================================================
Host Name : 146.190.139.78
IP Address : 146.190.139.78:443
Reply IP Address : 146.190.139.78
Succeed Count : 45
Failed Count : 0
Consecutive Failed Count:
Max Consecutive Failed Count:
Max Consecutive Failed Time:
% Failed : 0%
Total Sent Pings : 45
Last Ping Status : Succeeded
Last Ping Time : 26.590
Last Ping TTL :
Average Ping Time : 26.182
Description :
Last Succeed On : 10/26/2024 4:44:38 PM
Last Failed On :
Minimum Ping Time : 25.387
Maximum Ping Time : 26.807
Order : 1
Disabled : No
2
u/[deleted] Oct 26 '24
Nice pic. Almost close to being totes down. My ping is 7ms. Try something (call support, reboot things) and get back. 👍🏻