On Tue, 24 Aug 2004 09:15:56 +0100 Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > eme@xxxxxxxxxxxxxxx wrote: snip > > On Mon, 23 Aug 2004 23:58:51 +0100 > > Andy Furniss <andy.furniss@xxxxxxxxxxxxx> wrote: > > > > > > Thanks for the answer, Andy. > > I think I'm starting to understand. > > > > Does the "transmit time" here, mean "time the kernel should take in > > order to send out the packet" ? > > > > OK, so here's how I understood. Please correct me if I'm wrong. > > > > 1. When the kernel receives a packet, it gets the transmit time > > corresponding to the packet length. > > > > xmit_time = rtab[pkt_len>>cell_log]; > > > > 2. Then, the kernel sends that packet using xmit_time ? > > (If xmit_time was like 10 milli sec, it consumes 10 milli sec to > > sends the packet ? Or does it wait for xmit_time to send it) > > > > Is my understanding correct ? > > > > It's the qdisc that uses the rate table(s). On my setup with HTB a > table is generated for the rate and ceil of each class. > > When HTB dequeues a packet it doesn't always know how long it is until > it's gone (eg. I use SFQ on leafs), so I guess it will look up the time > from the len of the skb that sfq returns and delay dequeueing the next > packet from that class until that time has passed. > > I suppose burst an requeue complicate things - I don't really know how > HTB does things :-) > Thanks again Andy. I still can't understand the burst stuff, but I think I got the point about the rtable. I'll try to see the burst. Thanks !! > Andy. > -- Hideaki Nemoto <eme@xxxxxxxxxxxxxxx> _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
