В Чтв, 21/05/2009 в 13:13 +0200, Fabio Marcone пишет: > Hi! > > >> With your script I get the same result as mine: 2 parallel connections > >> (with different priority), one uses all bandwitdh and the other stalls > >> alternatively. > >> > >> perhaps there is a timeout mechanims that forse sending queued packets > >> although lower priority? > >> > > > > This is exactly how PRIO works. Higher priority classes get dequeued > > first, so if there is something to dequeue forever then the lower > > priority classes would never dequeue. > > > > > but it's not behaviour shown by test. And I don't no why. > Ex. > connection A -> higher priority > connection B -> lower priority > > results: > time | connection A | connection B > 1 sec 32 KB/s 0 KB/s > 10 sec 18 KB/s 15 KB/s > 20 sec 2 KB/s 31 KB/s > 30 sec 0 KB/s 32 KB/s > 40 sec 15 KB/s 16 KB/s > 50 sec 25 KB/s 7 KB/s > 60 sec 33 KB/s 0 KB/s > ... .... .... > and so on > > do you understand? I don't know why... > > suggestions are welcome. If you mean why connB get traffic - then it's probably connA doesn't *always* fill its bandwide which makes it possible for connB to send. Try to fullfil connA with several mass downloading connections. -- Покотиленко Костик <casper@xxxxxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
