----- Original Message ----- From: "Patrick McHardy" <kaber@xxxxxxxxx> To: "Andy Furniss" <andy.furniss@xxxxxxxxxxxxx> Cc: "Jiri Fojtasek" <jiri.fojtasek@xxxxxxxxxxxx>; "LARTC" <lartc@xxxxxxxxxxxxxxx> Sent: Wednesday, March 31, 2004 3:46 AM Subject: Re: New IMQ device implementation supporting device EOS > Andy Furniss wrote: > > Jiri Fojtasek wrote: > >> > >> > >> It leave always only one packet in the device queue. It is > there until > >> is not dequeued (sent to the device driver) and then is > inserted > >> another etc, etc > > > > > > I think I understand - in the case of imq -> ppp -> > usb/pci -> radsl > > modem with big buffer -> phone line. imq will only let one > packet wait > > in ppp queue, but there could still be a full buffer in the > '"'real'"' device. > > I haven't followed the discussion, but this is the way it is supposed to > work. As IMQ can queue packets for multiple devices it is not possible > to couple the dequeue event with the '"'real'"' output device's dequeue > event, simply because there may be multiple. Use non-work-conserving > qdiscs in this case and make sure you don't exceed the rate of the > individual output devices. > > Regards > Patrick Even if I still not understand if all this is nesecary, ( I only suspect it can make imq stable for local trafic shaping what nome of us was able to do) But ths idea is posible to implement (i am not sure if what he did realy works as supposed) multiple devices do not harm anything because of the way how dequeuing works. if device refuses to accept packet it should be requeued in same place later next packet will be dequeued which may be for other interface. _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
