Help troubleshooting random crazy high pings
-
While you aren't likely to get too far complaining about latency, the amount of packet loss you are seeing is pretty substantial and something that you should be able to get traction on.
The first thing they are going to have you do is to power cycle the modem. Might as well do that before you call them… ;)
not sure where to start, i doubt complaining to isp's will do any good
dpinger log:
Jan 30 00:58:33 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 4860984us stddev 2118777us loss 2%
Jan 30 00:57:48 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 7078675us stddev 3902331us loss 22%
Jan 30 00:57:44 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 8407503us stddev 4562891us loss 8%
Jan 30 00:57:29 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 9739973us stddev 9408171us loss 43%
Jan 30 00:57:15 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 25866us stddev 1581us loss 22% -
The packetloss is probably caused by the latency. TCP will treat large latency as lost packets creating many retransmitted packets that will flood the target. Bittorrent does this to me all the time when seeders are seeing 1.5k+ pings. As much as 50% of my incoming data can be retransmitted TCP segments. Luckily my ISP uses an AQM which limits my ping to around 30ms no matter what. I just get massive loss instead of high pings. This is a much more sane approach. Lost packets are much easier to handle than bufferbloat.
250ms is my ping from Midwest USA to China, India, or New Zealand. That's half way around the World. 8x that is crazy and breaks stuff like TCP.
I would first validate dpinger is reporting correct values by having another ping, MTR, or pathping seeing the same results.
-
Dpinger acts a bit differently with regard to missing packets. Packets are not permanently declared to be lost. When dpinger generates a report, it reports loss based on the number of packets that have not been received outside of the loss window at that point in time. If missing packets are subsequently received, they are not counted as lost in subsequent reports.
If you want to stop reading here, the take home point is that grandrivers is almost certainly experiencing significant packet loss.
While the only thing we have is the alarm entries in the log, we can still deduce a lot about his situation. Assuming that he has stayed with the default dpinger parameters, the 2% and 8% examples could be explained by periods of high latency. However, the examples of higher loss can't be explained this way.
There are two examples of an alarm firing with 22% loss. If he is using the default dpinger parameters, there would be 115 probes that are outside the loss interval of 1.125 seconds during reporting. For a 22% loss rate, there have to be at least 25 probes with a missing response. To achieve this without actual loss, the minimum latency would have to be over 6.3 seconds.
So in the first example of 22% loss, where the average RTT is 7.1 seconds, it is theoretically possible that very high latency turned into a 22% reported loss for that period. But it's still pretty unlikely given that the standard deviation indicates that there is a fair bit of spread in the RTT samples. In the second example of 22% loss, it's really not possible–the average latency is 25 milliseconds, which the 1.6 millisecond standard deviation indicates is highly consistent.
For the 43% example, the minimum RTT would need to be above 12 seconds.
Now of course if grandrivers is not using the default dpinger values, the above analysis is all wrong. :)
-
Denny,
not quite at defaults but am thinking about going back to defaults I am at a probe interval of 750 and set the time to treat packet as loss to 2500MSI am not happy with either of my isps and the guys at esf dont have much experience with semi rural isps as they talk of gig connections at there home that is more than my isps backbone 540M ish for more than 1100 cable modems (4M-50M down packages) school with 1300 students there business t-1 t-3 and they do have dsl customers will be this way for next 2 years contract length then there next problem is mixed modem cable modem upstream with station maintenance on qspk but data flow on qam16 so as the system gets noisy station maintenance rarely moves my modem by more than 1dbmv the modems are also all over the board mine comes in at 35-36 dbmv while others run 44 or more (ie the whole system needs rebalanced)
I know the head cable tech(not always a good thing) he was a year behind me in school so he does get the loss graphs via email and sometimes text depending on my mood, this is also an isp that blocked all icmp on there network for 5-7 yearsNow my Adsl2+ all i have to say is its a windstream connection one without enough competitors multiple remotes all funning back to overloaded fiber ports and a way overloaded backbone. equipment just got upgraded and the area manager told me 2 weeks ago my capacities problems are all fixed now 1 month prior i was told no issues or it way on my equipment or even being told it was cause i had more than 1 apple device on my network
i do have 3 different fiber optic backbones that are infront of our farm and no money can buy me access to any of them and all 3 did damage durning installation so was alway willing to trade access for damages, no luck
ps sorry for rant tone of post
-
Not everyone has gig fiber at home. I am on cable… but if I would get fiber I could. :)
I'm sure most of the devs have good connectivity at home. This is to be expected. It's what they do for a living. That being said, I think they put a lot of effort into making pfSense work well in a wide variety of circumstance.
Regards your dpinger settings, the packet loss value of 2500ms is fine for a higher latency connection. However on the send interval, I would either return it to 250ms, or increase the time period to 90 seconds or so to improve the accuracy of loss reporting. Your current accuracy is about 3%.
-
i returned it to defaults and will give it awhile see
have thought about also about ways i could monitor and graph my cable modem is doing as i know the isp is notwould also be nice to have 2 targets per connection to monitor
-
heres what last night looked like set at defaults, is there a benefit to leaving probe interval at 250 and moving time period longer than 30 say like 45 or 60 ?
Jan 31 22:49:05 dpinger CABLEMODEM_DHCP 8.8.8.8: Clear latency 25818us stddev 1181us loss 0%
Jan 31 22:48:41 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 3263762us stddev 3077790us loss 0%
Jan 31 22:48:15 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 758464us stddev 1477231us loss 25%
Jan 31 22:48:14 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 725947us stddev 1451881us loss 21%
Jan 31 22:46:51 dpinger CABLEMODEM_DHCP 8.8.8.8: Clear latency 55638us stddev 157651us loss 0%
Jan 31 22:46:26 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 3291780us stddev 3383516us loss 11%
Jan 31 22:46:12 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 863789us stddev 1647268us loss 21%
Jan 31 22:46:09 dpinger CABLEMODEM_DHCP 8.8.8.8: Alarm latency 765539us stddev 1570559us loss 11% -
There is both a benefit and detriment. The benefit would be increased accuracy of loss and smoothing for the latency and standard deviation. The detriment would be delayed response for alarm thresholds. It's a balance. I would leave it at 30 seconds.
is there a benefit to leaving probe interval at 250 and moving time period longer than 30 say like 45 or 60 ?
-
You still using Hyper-V? It still has the same root issue which caused same with apinger. I believe if you either disable time sync to the VM at the Hyper-V level, or disable NTP sync within the VM, that helps that issue.
-
have never used hyper v always bare metal should add signature
super micro c2558
-
I must have confused you with someone else, nevermind.
-
no problem , its got to be hard keeping everything you do as straight as you do, thanks for all the help
