RRD Quality Delay values wrong after updating to 2.2
-
Sorry man - That graph looks like 4 or 5 ms to me, which seems good but not too good to be true.
(I am sipping wine as I critique the post though - It's a good strong Cabernet, so itt may be influencing my judgement)
-
I've never logged the apinger data before, but it looks like lines that list the "delay:" is showing the average/min/max and this looks correct. I'm guessing that the RTT showing in the gateway widget is showing the data from the "avg:" lines which doesn't seem to correlate. This is a home connection via dsl 20down/0.8up. For some reason I think that dsl tends to have higher latencies than cable.
-
I just noticed this post.
https://forum.pfsense.org/index.php?topic=87835.0
Restarting the apinger service seems to have fixed this issue on my system.
-
I'm seeing the same thing. Fresh installation, ping is 5-6ms, apinger is showing 0.5ms. After restarting apinger it looks fine.
-
Thanks to wbond for letting me know about this thread. I've noticed the same thing; apinger delays are much less than a manual ping or traceroute will show; and restarting apinger corrects the problem.
-
It looks like in my case restarting apinger only worked for couple of hours, and now it's back to underreporting the RTT.
-
wbond, RRD is showing about 5ms, it's supposed to be about 25ms? Are you sure you're pinging the same IP address?
-
Harvy66, yes, same ip address and it usually measures in the mid 20's using ping and was consistently in that range in 2.1.5
I just pinged from pfsense and results were:
PING 67.41.239.70 (67.41.239.70): 56 data bytes
64 bytes from 67.41.239.70: icmp_seq=0 ttl=64 time=22.187 ms
64 bytes from 67.41.239.70: icmp_seq=1 ttl=64 time=22.040 ms
64 bytes from 67.41.239.70: icmp_seq=2 ttl=64 time=23.700 ms
64 bytes from 67.41.239.70: icmp_seq=3 ttl=64 time=21.708 ms
64 bytes from 67.41.239.70: icmp_seq=4 ttl=64 time=25.904 ms
64 bytes from 67.41.239.70: icmp_seq=5 ttl=64 time=39.864 ms
64 bytes from 67.41.239.70: icmp_seq=6 ttl=64 time=46.233 ms
64 bytes from 67.41.239.70: icmp_seq=7 ttl=64 time=22.777 ms
64 bytes from 67.41.239.70: icmp_seq=8 ttl=64 time=21.835 ms
64 bytes from 67.41.239.70: icmp_seq=9 ttl=64 time=21.580 ms–- 67.41.239.70 ping statistics ---
10 packets transmitted, 10 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 21.580/26.783/46.233/8.347 msThe dashboard is show 2.6ms at the same time.
-
Sorry - didn't get any notifications that anyone had replied to this.
Anyway - restarting apinger has put the stats back to normal. I'll keep an eye on it and see how long it looks sensible ;-)
-
Restarting apinger only seemed to fix it for a couple of hours for me. I ended up changing the probe interval on the gateway to 2 seconds and changed the Down value to 20 and the RTT has been running at normal levels for 2 days now. No idea why this would make any difference, but it seems to.
-
Just to let you I tried a workaround to restart apinger when monitoring alarm goes off and it seems to do the trick for 2 days now:
https://forum.pfsense.org/index.php?topic=87835.msg487013#msg487013 -
@cmb:
Could you enable gateway monitoring debug logging under System>Advanced, Misc, check "Enable gateway monitoring debug logging", and post your apinger logs?
I think I may have a clue here…
I restarted apinger and cleared the logs.The RRD RTT values where then ok for some time, but the reported values "went silly" when the log showed:
Feb 15 22:01:35 apinger: alarm canceled: GW_WAN(###) *** delay ***
Feb 15 22:01:22 apinger: ALARM: GW_WAN(###) *** delay ***
Feb 15 19:27:16 apinger: alarm canceled: GW_WAN(###) *** delay ***The graphs changed at the same time as the first "alarm canceled" event, so it looks like its related to the alarm clearing rather than triggering.
-
I have the same problem, a VSAT wan (supposed to be always more than 500ms) and a WIMAX (supposed to be always more than 120ms), after 2.2 upgrade (well, fresh installation) are 20/10/0ms