Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Help troubleshooting random crazy high pings

    Scheduled Pinned Locked Moved 2.3-RC Snapshot Feedback and Issues - ARCHIVED
    15 Posts 5 Posters 6.3k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • dennypageD
      dennypage
      last edited by

      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. :)

      1 Reply Last reply Reply Quote 0
      • G
        grandrivers
        last edited by

        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 2500MS

        I 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 years

        Now 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

        pfsense plus 25.03 super micro A1SRM-2558F
        C2558 32gig ECC  60gig SSD

        1 Reply Last reply Reply Quote 0
        • dennypageD
          dennypage
          last edited by

          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%.

          1 Reply Last reply Reply Quote 0
          • G
            grandrivers
            last edited by

            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 not

            would also be nice to have 2 targets per connection to monitor

            pfsense plus 25.03 super micro A1SRM-2558F
            C2558 32gig ECC  60gig SSD

            1 Reply Last reply Reply Quote 0
            • G
              grandrivers
              last edited by

              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%

              pfsense plus 25.03 super micro A1SRM-2558F
              C2558 32gig ECC  60gig SSD

              1 Reply Last reply Reply Quote 0
              • dennypageD
                dennypage
                last edited by

                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.

                @grandrivers:

                is there a benefit to leaving probe interval at 250 and moving time period longer than 30 say like 45 or 60 ?

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • G
                    grandrivers
                    last edited by

                    have never used hyper v always bare metal should add signature

                    super micro c2558

                    pfsense plus 25.03 super micro A1SRM-2558F
                    C2558 32gig ECC  60gig SSD

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      I must have confused you with someone else, nevermind.

                      1 Reply Last reply Reply Quote 0
                      • G
                        grandrivers
                        last edited by

                        no problem , its got to be hard keeping everything you do as straight as you do, thanks for all the help

                        pfsense plus 25.03 super micro A1SRM-2558F
                        C2558 32gig ECC  60gig SSD

                        1 Reply Last reply Reply Quote 0
                        • First post
                          Last post
                        Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.