Queue length in LAN shaper
-
Can you share a screen shot of the queue stats during an upload (WAN) load test?
-
Can you share a screen shot of the queue stats during an upload (WAN) load test?
Sorry, I can't find how to fill my outbound pipe with p2p traffic, it's just don't want to do it.
-
Look what I have found.
pfctl -s queue -v -vqueue qP2P on igb1 bandwidth 45Mb qlimit 50000 hfsc( red ecn default ) [ pkts: 44769 bytes: 3136059 dropped pkts: 0 bytes: 0 ] [ qlength: 0/50000 ] [ measured: 116.1 packets/s, 68.58Kb/s ]
Does red means RED is enabled? This is the problem. I have not enabled it!
During load:
queue qP2P on igb1 bandwidth 45Mb qlimit 50000 hfsc( red ecn default ) [ pkts: 4326757 bytes: 6132296391 dropped pkts: 242 bytes: 353048 ] [ qlength: 4174/50000 ] [ measured: 25052.9 packets/s, 290.45Mb/s ]
SO it's drops actually above 5000 limit, but queue length is 50000 shown correctly this time. I think it's autotuned by RED? I can't find how GUI gets the 5000 actual limit but it looks the Right value.
-
@w0w:
Can you share a screen shot of the queue stats during an upload (WAN) load test?
Sorry, I can't find how to fill my outbound pipe with p2p traffic, it's just don't want to do it.
Sharing a popular Linux distribution torrent like Ubuntu or Debian is a sure-fire way to saturate your upload.
-
@w0w:
Look what I have found.
pfctl -s queue -v -vqueue qP2P on igb1 bandwidth 45Mb qlimit 50000 hfsc( red ecn default ) [ pkts: 44769 bytes: 3136059 dropped pkts: 0 bytes: 0 ] [ qlength: 0/50000 ] [ measured: 116.1 packets/s, 68.58Kb/s ]
Does red means RED is enabled? This is the problem. I have not enabled it!
During load:
queue qP2P on igb1 bandwidth 45Mb qlimit 50000 hfsc( red ecn default ) [ pkts: 4326757 bytes: 6132296391 dropped pkts: 242 bytes: 353048 ] [ qlength: 4174/50000 ] [ measured: 25052.9 packets/s, 290.45Mb/s ]
SO it's drops actually above 5000 limit, but queue length is 50000 shown correctly this time. I think it's autotuned by RED? I can't find how GUI gets the 5000 actual limit but it looks the Right value.
Hmm, interesting results.
You should have RED and ECN disabled (and any other AQMs) if your goal is to (needlessly) fill your over-sized queue. I thought you already disabled ECN… is the GUI reporting ECN as disabled when it's actually not?
Again, like I said earlier, ultimately you never want an artificially inflated queue depth, so the fact that it doesn't is a good thing. Increasing latency is never the primary goal of a traffic-shaping setup. Usually increased latency is a side-effect of other goals like increasing bandwidth or decreasing latency of other, higher-priority traffic.
A more telling test would be saturating upload, rather than download, so try to get some results from an upload test. Download and upload QoS are very different. A great tutorial regarding those differences and other QoS fundamentals is: http://www.linksysinfo.org/index.php?threads/qos-tutorial.68795/
Just for fun, you might try enabling CoDel or setting the qlimit to 1 on qP2P as a test to see if your actual performance changes. There is no research I am aware of that shows traffic-shaping (queueing packets) superior to traffic-policing (no queueing packets) with regard to ingress/download when moving from a low-bandwidth network node (ex. 300Mbit) to a higher-bandwidth node (ex. 1Gbit). Here's a Cisco article comparing shaping and policing: http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
-
@w0w:
Can you share a screen shot of the queue stats during an upload (WAN) load test?
Sorry, I can't find how to fill my outbound pipe with p2p traffic, it's just don't want to do it.
Sharing a popular Linux distribution torrent like Ubuntu or Debian is a sure-fire way to saturate your upload.
Looking at their bandwidth settings, they're shaping to 300Mb/s. Seeding opensource torrents is not going to dent it. I seed almost 200 ISO images of the most popular Linux distros from my SSDs, and my average upload is about 10Mb/s on my 150Mb/s connection. They're already heavily seeded.
Unless I jump on a hugely popular ISO withing a few hours of it coming out, I will never max my connection because there will already be so many seeders.
-
Take a Linux DVD ISO, rename it to Netflix_Stranger_Things_Season_2_Leak.zip, shove it up TPB and watch your bandwidth die ;D
-
@w0w:
Can you share a screen shot of the queue stats during an upload (WAN) load test?
Sorry, I can't find how to fill my outbound pipe with p2p traffic, it's just don't want to do it.
Sharing a popular Linux distribution torrent like Ubuntu or Debian is a sure-fire way to saturate your upload.
Looking at their bandwidth settings, they're shaping to 300Mb/s. Seeding opensource torrents is not going to dent it. I seed almost 200 ISO images of the most popular Linux distros from my SSDs, and my average upload is about 10Mb/s on my 150Mb/s connection. They're already heavily seeded.
Unless I jump on a hugely popular ISO withing a few hours of it coming out, I will never max my connection because there will already be so many seeders.
Do you know of any sure-fire way of saturating a 300Mbit upload? Maybe simultaneously upload a few huge files to MEGA? Their bandwidth is pretty damn good and they offer 50GB is space for free.
I see no reason why OP couldn't just lower qP2P's bandwidth (with upper-limit), or the entire WAN interface's bandwidth, temporarily for testing purposes, which would make full upload saturation easy.
-
I like Nullity's idea to artificially limit the bandwidth to something low enough to saturate. I would not recommend going under 5Mb because other queuing issues start to crop up since 1500byte MTUs are relatively large as you near 1Mb.
There are also public iperf servers. With a 150Mb connection myself, I could possibly be of help.
-
Ok, I've disabled ECN everywhere.
queue qP2P on igb1 bandwidth 45Mb qlimit 50000 hfsc( default ) [ pkts: 7536667 bytes: 10776855638 dropped pkts: 0 bytes: 0 ] [ qlength: 9404/50000 ]
EDITED: I see now that pfctl shows me correct values everywhere and GUI is not! Still going on 5000 under load.
Ok it just liiks like GUI is broken. Queue length is really filled up to the limit, I think. -
https://redmine.pfsense.org/issues/6836