Calculating the required bandwidth for ACK queues for asymetric link

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