Ed Wildgoose wrote:
Hmm, interesting. Can you switch the order of your IP mappings around on this test so that you can prove that it is some feature of HTB that user1 always gets more bandwidth, and no something about that machine (ie if you swap ip's for user1 and 3 that it still remains (the new) user1 who gets all the b/w?
Obviously this should not be so, just curious to eliminate other possibilities
Ed W
I did it already. When I set filter to direct 192.168.3.4 packets to 1:60 and 192.168.3.6 to 1:40 then lines on my graph switch: now blue is over red...
The same switch happens when i set higher prio of 1:60...
So it means than when two classes at the same level have same "prio" then class with lower minor id has higher priority than classes with lower minor id... So there is no possibility to set them to be equal when borrowing occurs.
Now I am in trouble as I am writing my thesis and I wanted to show in my paper that HTB is excellent to share BW between users... what am I to write about this case?
BTW: maybe someone could repeat my experiment? Maybe it is something wrong with my hadrware or some unbelievable coincidence?
Have a read through the dequeue code. Perhaps you can spot a problem - there are plenty of debug flags you can switch on
If I had to guess, then I would suspect the following: When there is spare bandwidth available, then there is some kind of round robin scheduler which gives the spare stuff away by visiting each lower node in ascending priority order. However, I suspect that the order is deterministic and hence the first node with prio 1 effectively gets visited more often than the next node with prio1 and so on (makes sense from a computing implementation point of view - it's fast and efficient, etc)
It would also imply that the spare bandwidth is only allocated on a per time slice point of view, ie there are no long term timers checking that node 1 is not getting a little more than node 2 and hence biasing the allocation to node 2. All that kind of code would add overhead and is presumably therefore justified in not being there...?
This would be my hunch, but there is plenty of info on the HTB site on the theory, and I should think it worth checking the dequeue code with some debug statements to prove this (or not). Fixing it looks a little harder though...
Ed W _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
