Navigation

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

    Traffic Graphs shows wrong throughout when traffic shaping enabled

    Traffic Shaping
    6
    12
    3431
    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.
    • F
      fireball last edited by

      Using the latest 2.2 build on amd64 (Intel i7).

      When I enable traffic shaping with the wizard the traffic graph (and the throughput on the WAN interface as reported by SNMP) is incorrect. It is showing much lower throughput than is actually occurring. I am testing this by remotely downloading a file from a local HTTP server on the DMZ. The traffic graph for the DMZ is correct, but the WAN outbound is showing about 1/3 or so of the actual throughput.

      Otherwise the shaping seems to be working OK. We have dual WAN and three LAN (LAN, DMZ, WIFI - which is handled by its own wifi router).

      I tried both HFSC and Priority queuing on all interfaces.

      Any thoughts? Known issue?

      Thanks.

      More info:

      The throughput of individual hosts/ips shows up correctly on the traffic graph page. It is just the total throughput of the WAN interface that is being displayed incorrectly it is incorrect both on the dedicated traffic graph page, and in the widget version of the traffic graph on the default page (assuming enable the traffic graph widget)

      The SNMP output for the WAN interface is also wrong (which is the most annoying part as I have this in my shell's screen hard status line, and reference it constantly.)

      The rrd graphs seem to indicate the correct throughput.

      The WAN2 interface, and the LAN, DMZ, and WIFI interfaces all display the correct throughput.

      No clue it is makes a difference, but the WAN interface is the second interface (if2 via SNMP).

      Thanks.

      1 Reply Last reply Reply Quote 0
      • T
        TheUbuntuGuy last edited by

        This issue is still present in 2.2.5. I upgraded from 2.1.5 a few days ago and immediately noticed this change.

        I noticed that only my WAN interface reports incorrect traffic, a little less than 50% the real throughput.
        My 3 LANs are all fine.

        After some experimentation, it seems to be the 'bandwidth' parameter in the WAN traffic shaper which is 'causing' this.
        In my setup it is set to 10Mbit/s. If I remove the value and reload the shaper, the traffic graph shoots up to the correct value. (However the shaper is no longer dropping packets).
        Since this is the only interface with a bandwidth value set, it is the only one which has its graph affected. As a result, only outbound traffic on the WAN is shown incorrectly.

        1 Reply Last reply Reply Quote 0
        • N
          Nullity last edited by

          Use pfTop instead of the traffic graph. Traffic graph is just a cutesy GUI thing. Do not rely on it (for now).

          @TheUbuntuGuy, if you are using HFSC, Bandwidth technically sets link-share's m2, so Bandwidth can be excluded while having the exact same functionality. When I was diving deep into the undocumented uses of HFSC I had some complex configs that would only work if I left out Bandwidth. The configurations were technically correct, but for unknown reasons, the GUI complained under certain circumstances.

          So, maybe the Bandwidth param should be the focus of some debugging.

          1 Reply Last reply Reply Quote 0
          • M
            moikerz last edited by

            Is this still an issue in 2.3?

            @Nullity:

            … using HFSC, Bandwidth technically sets link-share's m2, so Bandwidth can be excluded while having the exact same functionality.

            So I can clear the Bandwidth field, check the Link-Share option, and set m2 at the original value for Bandwidth? I thought the Bandwidth field sets the Upperlimit m2?

            1 Reply Last reply Reply Quote 0
            • H
              Harvy66 last edited by

              Bandwidth sets linkshare, which is the minimum amount of bandwidth, not maximum.

              1 Reply Last reply Reply Quote 0
              • M
                moikerz last edited by

                @Harvy66:

                Bandwidth sets linkshare, which is the minimum amount of bandwidth, not maximum.

                So for my setup (below), it makes no sense to set Bandwidth + Upperlimit to the same for LAN1 and LAN2?

                WAN, HFSC, Bandwidth: 5Mbps
                    - qInternet, CoDel, Bandwidth: 5Mbps
                        - qNormal, Default, CoDel, Bandwidth: 10%
                        - qHigh, CoDel, Bandwidth: 20%
                        - qLow, CoDel, Bandwidth: 5%

                LAN1, HFSC, Bandwidth: 900Mbps
                    - qLink, CoDel, Bandwidth: 895Mbps
                    - qInternet, CoDel, Bandwidth: 4Mbps, Upperlimit: 4Mbps
                        - qHigh, CoDel, Bandwidth: 20%
                        - qNormal, Default, CoDel, Bandwidth: 10%
                        - qLow, CoDel, Bandwidth: 5%

                LAN2, HFSC, Bandwidth: 900Mbps
                    - qLink, CoDel, Bandwidth: 895Mbps
                    - qInternet, CoDel, Bandwidth: 1Mbps, Upperlimit: 1Mbps
                        - qHigh, CoDel, Bandwidth: 20%
                        - qNormal, Default, CoDel, Bandwidth: 10%
                        - qLow, CoDel, Bandwidth: 5%

                1 Reply Last reply Reply Quote 0
                • H
                  Harvy66 last edited by

                  The upperlimit looks correct in your config. Just an fyi, but Codel does not always play well with really low bandwidth like 1Mb/s and it could aggressively drop packets. The reason for this is Codel is time based and a 1500mtu packet can take too long to send at 1Mb/s and trigger Codel's drop path.

                  1 Reply Last reply Reply Quote 0
                  • M
                    moikerz last edited by

                    @Harvy66:

                    The upperlimit looks correct in your config. Just an fyi, but Codel does not always play well with really low bandwidth like 1Mb/s and it could aggressively drop packets. The reason for this is Codel is time based and a 1500mtu packet can take too long to send at 1Mb/s and trigger Codel's drop path.

                    Hmm, yes I remember something about CoDel and low bandwidths. It probably explains why some webpages just seem to 'hang'.

                    1 Reply Last reply Reply Quote 0
                    • M
                      moikerz last edited by

                      Harvy66,
                      If I remove the parent "Bandwidth" value and put it in the Link-Share m2, I get a configuration error, because all of the child queues use Bandwidth as a % of the parent. So for:

                      LAN1, HFSC, Bandwidth: 900Mbps
                          - qLink, Bandwidth: 895Mbps
                          - qInternet, Bandwidth: 4Mbps, Upperlimit: 4Mbps
                              - qHigh, Bandwidth: 20%
                              - qNormal, Default, Bandwidth: 10%
                              - qLow, Bandwidth: 5%

                      If I'm understanding correctly, the throughput graphs are messed up when HFSC uses the Bandwidth value. I need to limit qInternet to 4Mbps to avoid saturation, but I need to specify the minimum service levels for the child queues as well.

                      Am I doing something wrong? Or is this still a bug with the throughput graphs?

                      1 Reply Last reply Reply Quote 0
                      • H
                        Harvy66 last edited by

                        The HFSC config really wants bandwidth provided even though link-share is synonymous. What I've done is just make sure they're both the same if I plan on using link-share for its more advanced features, which I don't really recommend messing with.

                        1 Reply Last reply Reply Quote 0
                        • M
                          moikerz last edited by

                          @Harvy66:

                          The HFSC config really wants bandwidth provided even though link-share is synonymous. What I've done is just make sure they're both the same if I plan on using link-share for its more advanced features, which I don't really recommend messing with.

                          Hmmmkay. So it sounds like what I've done is correct for HFSC, but a consequence is the UI graphs are messed up. I'll just rely on pfTop in the shell.

                          1 Reply Last reply Reply Quote 0
                          • A
                            asayler last edited by

                            I'm seeing the traffic graph issue as well using a PRIQ shaper. Although it became most pronounced (e.g. off by more than 50% - shows ~4 Mbps for an 11+ Mbps flow) only after I disabled all of the scheduler options (e.g. Codel, RED, ECN, etc). I mentioned this issue at https://forum.pfsense.org/index.php?topic=115862.0 but figured I should post it here as well in case the extra data is usefull. WHen Codel or ECN were enabled, the traffic graph was much closer (within 1 Mbps or so) to being correct (if not exactly correct).

                            Is there an open bug report for this in redmine? If not, should I open one?

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post

                            Products

                            • Platform Overview
                            • TNSR
                            • pfSense
                            • Appliances

                            Services

                            • Training
                            • Professional Services

                            Support

                            • Subscription Plans
                            • Contact Support
                            • Product Lifecycle
                            • Documentation

                            News

                            • Media Coverage
                            • Press
                            • Events

                            Resources

                            • Blog
                            • FAQ
                            • Find a Partner
                            • Resource Library
                            • Security Information

                            Company

                            • About Us
                            • Careers
                            • Partners
                            • Contact Us
                            • Legal
                            Our Mission

                            We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                            Subscribe to our Newsletter

                            Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                            © 2021 Rubicon Communications, LLC | Privacy Policy