Calculating the required bandwidth for ACK queues for asymetric link

eri--

Can i assume this is right now?!

I am just asking to be sure and i would hate to rerun the calculations again on this :).

dusan

The calculation is now formally exact and the formula approximates it tightly. However, for K = 20, the old formula gives X/A = 61% which corresponds to the largest qWANack I ever hear of (see hoba's post in this thread), while the new formula shows something else: X/A=75%, which is clearly more aggressive and may be over-estimate.

Which formula is better, I don't know. I think the better approach is to use the old as the default, users should apply the new only if they'll experience packet drops.

eri--

@dusan:

The calculation is now formally exact and the formula approximates it tightly. However, for K = 20, the old formula gives X/A = 61% which corresponds to the largest qWANack I ever hear of (see hoba's post in this thread), while the new formula shows something else: X/A=75%, which is clearly more aggressive and may be over-estimate.

Which formula is better, I don't know. I think the better approach is to use the old as the default, users should apply the new only if they'll experience packet drops.

if i solve this formula(the old one) for X i get:

log(X) = 0.8 * log(B) + 0.2 * log(A) - log(0.0558)

and for A=512 and B=128 i get X = 9.X ?!

Have i made an error somewhere?!
Or does this formula gives a result in percentages?!
Meaning i should do a 9% * A(512) after it. Sorry for the dumb question just to be sure.

dusan

@eri--:

if i solve this formula(the old one) for X i get:

log(X) = 0.8 * log(B) + 0.2 * log(A) - log(0.0558)

You may use it this way (to compute X directly), of course. When posted, it was meant to compute the ratio X/A from the known ratio B/A, however.

Just a typo: the sign of log(0.0558). I know that you used + and just mistakenly typed - here.

@eri--:

and for A=512 and B=128 i get X = 9.X ?!

Have i made an error somewhere?!

There is no error. X = 9.42445330 [kb/s] and X/A = 0.0184 = 1.84%. Just that it is for uplink four times faster than downlink, which may be unusual (for home user) and may not what you mean for.

Note that X/A=1.84% in this case (B/A = 1/4) equals to Y/B in the case of B/A = 4 (see the old table). In general, the formula has a property that a link with B/A = 1/K behaves exactly like a link with B/A = K in reverse orientation, i.e.

X/A * Y/B = (5.58%)^2 = const

That's because I've modelled the link using pairwise symmetric traffic patterns. For example,

FTP upload pattern: (1, 0.005, 0.001, 0.025)
FTP download pattern: (0.005, 1, 0.025, 0.001)

then, I've put a straight line as an approximation of the resulting curves (B/A,X/A) and (A/B,Y/B) in (log,log)-scale coordinate plane (see attached figures).

Also note that the formula gives X/A > 100%, which is clearly nonsense, in case of large B/A. The suitable range of direct applicability is about 1/20 <= B/A <= 20. If B/A is out of the range, one may take the result from the nearest in-range case (i.e., B/A = about 1/20 or 20).

qwanack.gif_thumb

qwanack-old.gif_thumb

eri--

You may use it this way (to compute X directly), of course. When posted, it was meant to compute the ratio X/A from the known ratio B/A, however.

I know i can use it this way, math has the rules to allow it.
Furthermore, i arrived to a conclusion that with a +-10% tolerance i can simplify it to
log(X) = 0.8 * log(A) so it will be mostly OK for most of users and remove the dependency on the other side.

One thing i noticed about ALTQ_HFSC is that parameter m1 is just the burst/bandwidth that will be guaranteed by the scheduler for d time, for a realtime queue.
So usually it gets back to m1 = packet size of the application, d = the latency you want guaranteed for it and m2 = the bandwidth you want it to get assured in the long run.

The last paragraph just to make this complete.

dusan

@eri--:

Furthermore, i arrived to a conclusion that with a +-10% tolerance i can simplify it to
log(X) = 0.8 * log(A) so it will be mostly OK for most of users and remove the dependency on the other side.

I don't think that it can be simplified that way. X in the original formula depends on on both A and B, while X in the simplified formula depends on A only. Thus the simplified formula is not an approximation of the original (they're completely different and non-comparable instead) and we may not talk about any tolerance. I doubt such a simplification would be helpful.

eri--

Formally they are very different.
Practically, with that tolerance the values ressemble pretty much the original for the set of bandwidths of home users.

dusan

That's an unfounded argument.

Assume, as an example, A = 1 [mb/s]. Using the simplified formula we would obtain X = 1 [mb/s] regardless of the downlink (B).

Using the original formula, with several possible downlinks B = 1, 2, 5, 10, 20 [mb/s] we have X = 0.0558, 0.0972, 0.2022, 0.3521, 0.6130 [mb/s], respectively.

Relative error of the simplified formula against the original is 1692%, 929%, 395%, 184%, 63%, respectively. So, the simplified formula is not 10%-tolerated.

The ratio of X in the last case (B=20) against X in the first case (B=1) is 0.6130/0.0558 = 1099%. This is big enough to see that no single value of X suits both the cases and, consequently, formulas computing such X can never be tolerated.

Nostradamus

Hmm… I don't understand a shit, hehe hehe

I like to setup traffic sharper with max 25/10 mbit for all IP's in this IP Range 192.168.100.100-192.168.100.111 with full max speed to all protocols, like P2P, everything. And give those users in this IP Range 192.168.100.112-192.168.100.125 max 10/5 mbit with low priority of P2P user and other traffic use. But still have 100mbit speed on LAN(local network, i have a server).
Please don't come with those formulas, because i don't understand:) I need pictures, hehe

Cheers

heiko

Do you have a calculator?

sullrich

@Nostradamus:

Hmm… I don't understand a shit, hehe hehe

I like to setup traffic sharper with max 25/10 mbit for all IP's in this IP Range 192.168.100.100-192.168.100.111 with full max speed to all protocols, like P2P, everything. And give those users in this IP Range 192.168.100.112-192.168.100.125 max 10/5 mbit with low priority of P2P user and other traffic use. But still have 100mbit speed on LAN(local network, i have a server).
Please don't come with those formulas, because i don't understand:) I need pictures, hehe

Cheers

Please do not hijack this conversation. If you do not understand then simply ignore!

dusan

@Nostradamus:

I like to setup traffic sharper with max 25/10 mbit for all IP's in this IP Range 192.168.100.100-192.168.100.111 with full max speed to all protocols, like P2P, everything.

Let's call it Range1.

@Nostradamus:

And give those users in this IP Range 192.168.100.112-192.168.100.125 max 10/5 mbit with low priority of P2P user and other traffic use.

Let's call it Range2.

@Nostradamus:

But still have 100mbit speed on LAN(local network, i have a server).

Please don't come with those formulas, because i don't understand:) I need pictures, hehe
Cheers

Well here are some pictures.

Link hiearchy:

–--Mainlink
|
+----Range1 (10,25) mb/s
|
+----Range2 (5,10) mb/s

Queue hiearchy:

For Range2 you don't need to use the formula since the required bandwidths are pre-calculated in the table. The column B/A means how many times is downlink faster than uplink. For Range2 it is 10/5 = 2, so have a look at row 2:

-The X/A is the required bandwidth of qWANack, i.e. 9.72%.

-The Y/B is the required bandwidth of qLANack, i.e. 3.2%.

For Range1, B/A = 25/10 = 2.5 which is not listed in the table. If you don't use the formula then you'll have to guess the required bandwidths from the nearest rows (2 and 3) of the table. Thus qWANack should be something between 9.72% and 13.44%, and qLANack should be something between 3.2% and 2.32%.

Hope it helps.

Nostradamus

@dusan.

Thank you very very much ;) You are the man

Cheers

Master One

Looks more like black magic to me too. Has any of this already been implemented in 1.2-RELEASE? I just run the wizard, and this is what came out:```
0 No 830Kb qwanRoot
0 No 14552Kb qlanRoot
1 Yes 1 % qwandef
1 Yes 1 % qlandef
ACK 7 No 25 % qwanacks
ACK 7 No 25 % qlanacks
7 No 25 % qVOIPUp
7 No 25 % qVOIPDown
RED ECN 1 No 1 % qP2PUp
RED ECN 1 No 1 % qP2PDown

I just changed qwanacks to 65%. No idea, if that's any good yet.

eri--

As Scott said in some posts before ask your question in another thread.

The answer to your question is a plain NO.

Remember that this is just a recommendation and not suitable to every case.

Ermal