Patrick McHardy wrote: > Nuutti Kotivuori wrote: >> Patrick McHardy wrote: >> >> BTW the Blue scheduler patch for 2.6 seems to be working nicely - >> but I haven't had the time to run the tests on it that I wished to, >> so I haven't posted anything further about it. > > I have in the mean time read up on SFB, maybe I'll extend blue when > I find the time. That reminds me - I have an "extension" to Blue I'd like to try and cook up, if I ever manage to get the time. Ingress Blue. Basically just having a token bucket on ingress, just like traffic policing has - but using Blue on that. Running out of tokens means packet drop, so increase probability. Bucket overflowing with tokens means link idle, so decrease probability. I have a feeling something like that might work well when trying to reduce packet queueing at the ISP on a slow inbound link - better than the usual strict ingress police or using IMQ with RED and such. > PSCHED_GETTIMEOFDAY (or PSCHED_CPU in case of the kernel) are > important for HFSC to work properly, PSCHED_JIFFIES has too low > resolution. That might be what was messing up my other simulations as well - thanks for the heads up, I will see what comes out of that. [...] > I know what the problem is. Try: ip link set lo txqueuelen 1 Works like a dream! > or upgrade to 2.6.4. The problem got introduces when fixing > an off-by-one in pfifo_fast, before it would enqueue one packet > with a txqueuelen of 0. In 2.6.4 this behaviour is restored, > although it's a misconfiguration anyway to use leaf-queues with > a limit of 1 for anything but well-formed flows. Figures... :-) So I just got bitten by the default configuration of txqueuelen of 0 for lo, that I didn't even happen to think about. Time to upgrade to 2.6.4 as well it seems. -- Naked _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
