Seems I was to fast to declare success, my version is not much more stable than the original one,everything depends on dropped packets. This is even not imq fault afterall, can be prowed in other way also: atempts to police outgoing trafic it will be ok until you dont touch localy generated packets if you try to drop them you will be sorry, because kernel will resend then together with new ones of cource policer will drop them too, but linux kernel keeps resending then thus increasing rate progresively. I noticed that with my trafic counter. internal trafic grew to enormous levels 10X more than it can be. In reality there was almost no output at all. so DONT USE POLICERS ON EGRESS. on low trafic it is harmless but on 100mb/s it probably can kill computer (not tested). Seems imq have similar problem even if driver itself have no leaks kernel consumes all resousces on resnending droped packets so that computer stops responding for now I dont have good idea how to fix it so I will try to avoid localy generated trafic so it will me possible to shape ingress and forward, egress will be left for real device. maybe later I will find how fix that > > It seems to capture ingress and egress traffic of all interfaces; wouldn't > this count packets twice ? No, ingress is for local and egress for everything so everything should be ok (in theory) > If the machine is doing SNAT or DNAT, what IP addresses would be seen by > the qdisc ? > I made driver see the final destination address because it is more usefull > Rubens > > > _______________________________________________ > LARTC mailing list / LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
