Basic question on setting bandwidth
-
You could use HFSC's link-sharing parameter, which uses ratios to determine which queue will be granted how much throughput, and when throughput is unused any link-sharing queue can use the maximum available.
That won't do any good because if the bandwidth is set at 8Mb and there's only 1.6Mb actually available, there will be no shaping done. Linkshare 25% will mean 2Mbit, which is already over what's available.
Link-share chooses which packet to send based on a "virtual time" scale derived from the ratio between the queues. You could set queue-A to 7Kb and queue-B to 1Kb or queue-A to 700Kb and queue-B to 100Kb. Since the ratio is the same, link-share would act exactly the same for both of the previous examples. Link-share has no limit, hence the need for the "upper-limit" parameter.
The ratio, not the actual bitrate, is what HFSC bases it's link-share algorithm on.
-
What does the WISP say when you complain?
Yeah they are on a first name basis with me. They always give the same old "we can see your modem so it must be your router or possibly malware on your computer".
This was just taken a few minutes ago. This is what I 'm dealing with. Tonight is an especially bad case but it still reflects what I'm talking about.
-
And I just ran it again and get this:
-
You could use HFSC's link-sharing parameter, which uses ratios to determine which queue will be granted how much throughput, and when throughput is unused any link-sharing queue can use the maximum available.
That won't do any good because if the bandwidth is set at 8Mb and there's only 1.6Mb actually available, there will be no shaping done. Linkshare 25% will mean 2Mbit, which is already over what's available.
Link-share chooses which packet to send based on a "virtual time" scale derived from the ratio between the queues. You could set queue-A to 7Kb and queue-B to 1Kb or queue-A to 700Kb and queue-B to 100Kb. Since the ratio is the same, link-share would act exactly the same for both of the previous examples. Link-share has no limit, hence the need for the "upper-limit" parameter.
The ratio, not the actual bitrate, is what HFSC bases it's link-share algorithm on.
But until the total set bandwidth is reached, I don't believe any drops occur, which is why it is imperative for the top-end to be set a little lower than what's actually available. There is no reason for the shaper to drop any packets if there is bandwidth available (absent upperlimit on the queue), regardless of link-share ratio.
-
You could ask your ISP how much bandwidth they see you using. Since their argument is that you must have malware using your bandwidth, then they should be able to see that traffic. Better yet, have them bring a laptop of their choosing over and do some speed tests. When my ISP installed my connection, they first checked it with their computer plugged directly in, then did a speedtest with one of ours.
-
Curious what your WAN RRD graphs look like. Status > RRD Graphs
-
But until the total set bandwidth is reached, I don't believe any drops occur, which is why it is imperative for the top-end to be set a little lower than what's actually available. There is no reason for the shaper to drop any packets if there is bandwidth available (absent upperlimit on the queue), regardless of link-share ratio.
Maybe it makes more sense to consider link-share a traffic-policer instead a traffic-shaper.
I know the HFSC paper mentions a test where they explicitly stated they were imitating the throughput limits of a 10Mbit connection, which says to me that allowing the link to define the limits is perfectly fine.Or… someone could just try it. Too much theory in here. :P
Edit: Interpret the quote for yourself:
The sessions at level one all have bandwidth reservation of 1.5Mbps, and the sessions at level two have bandwidth reservations of 80Kbps, 480Kbps, 1.44Mbps and 2Mbps respectively. The total aggregate bandwidth reservation is 10Mbps – Ethernet's theoretical maximum throughput.
That is from the "Link-Sharing" section of the paper. Seems if maxing out the link was a poor choice when using link-sharing, they would have either limited it below or stated that this was a bad practice.
-
Yeah, someone could.
-
You could use priq so at least the traffic you mark as priority is sent first.
Damn me and my HFSC tunnel vision… :( I kinda forgot that PRIQ could achieve his goal.
Using PRIQ is probably the most convenient and predictable method. One drawback is that any of the higher priority queues can completely block lower priority queues, so "fairness" is impossible. -
Well, I just tested my theory and it failed. HFSC needs to be configured as the throughput bottle-neck with the root queue's "Bandwidth" parameter.
I will be testing more scenerios, like perhaps moving the actual link's queue from the root (root queue cannot change it's bandwidth dynamically, apparently) to an interior leaf queue (a leaf's bandwidth is dynamic). I will report back if find anything new. How the hierarchy of the queues is laid out is actually important, so I have some hope it may work. :)
It may be interesting to note that HFSC was not originally implemented with an "upper-limit".
https://github.com/freebsd/freebsd/blob/428b45aa532260e8c6ddf0217ec31db2234d29a8/sys/contrib/altq/altq/altq_hfsc.c#L39Anyway, here are my results:
WAN Bandwidth set to 640Kb. (Less than real-world throughput of 666Kb)
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 16:55:57 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S root_pppoe0 640K hfsc 0 0 0 0 0 0 0 0 qBulk 1000 hfsc 214 76697 0 0 1 1 695 qACK 500K hfsc 1697 94153 0 0 0 3 211 qNTP 25000 hfsc 0 0 0 0 0 0 0 qTEST1 **1000** hfsc 1285 1500K 19 7521 38 9 **11K** qTEST2 **6000** hfsc 3067 3792K 0 0 35 52 **67K**You can see that the ratios between the 2 test queues are almost exactly 1:6.
These are the speeds recorded in my ftp client, "lftp", during the above test. The speeds are not pasted exactly as I observed, because I had to freeze the terminal with Ctrl-S.
tmp/linux-3.18.5.tar.xz.1' at 5651256 (11%) **63.2K/s** eta:11m [Sending data]progit.en.pdf' at 3180520 (56%) 11.0K/s eta:2m [Sending data]WAN Bandwidth set to 250Mb.
pfTop: Up Queue 1-6/6, View: queue, Cache: 10000 17:01:25 QUEUE BW SCH PR PKTS BYTES DROP_P DROP_B QLEN BORR SUSP P/S B/S root_pppoe0 250M hfsc 0 0 0 0 0 0 0 0 qBulk 1000 hfsc 14 2667 0 0 0 0 0 qACK 500K hfsc 34 1874 0 0 0 0 0 qNTP 25000 hfsc 0 0 0 0 0 0 0 qTEST1 **1000** hfsc 1592 1921K 0 0 0 27 **34K** qTEST2 **6000** hfsc 1551 1940K 0 0 0 35 **46K**As you can see, this test did not function as I expected.
Edit: "Bandwidth" and link-share's "m2" are set to the same value.
