[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Using TC to simulate wireless channels





On Wed, 16 Aug 2000, christian.benven wrote:

> > christian.benven wrote:
> > > it depends on what you mean by bits/s (I do not know what is a 3G 
> > > channel). Do you mean 300, 1200, 9600, ...?
> > > To smaller you want it to be, the worse it becames the simulation.
> > 
> > Do you mean that the overall result is worse or that the quality of
> the
> > simulation suffers ? I'd be surprised by the latter, though, because
> one
> > of the big problems of any shaping is the limited temporal granularity
> > of dequeue actions (hmm, we'll have to find a "standard" term for this
> > concept ...), so low bit rates should actually be easier.
> > 
> 
> Yes and no.
> The main problem you face when writing a shaper is for sure the HZ (100)
> on intel machine.
> On alpha, the 1024 is a bit better.
> When you are for example simulating a 28Kbps channel over a 10/100 eth,
> you can not send the whole 28K in one shot (it takes less than 1ms.) and
> then stay silent for the remaining 999ms. In case you split the second
> in "n" slots, with "n"<=100 (HZ), it means that on each slot you can not
> send more than .28Kbps (35Bytes). Given that the IP header is at least
> 20Bytes, and then you have to add all the other headers (layer4 and
> maybe layer5) you can see that the transmission could become too bursty.
> Moreover you are adding to mush overhead (repeated headers), and because
> you probably are fragmenting the IP packets, you are also introducing a
> defragmentation delay on the other side.  This means that 100 is too
> much and then if you make it smaller (say 50) you start loosing
> precision, ...
> The shaper I have written takes into account all of those aspects by
> means of retroactive mechanism.
> 
> > > I have written a traffic shaper one year ago that does all of those 
> > > things.
> > 
> > Very good - a dedicated module definitely looks like the right
> approach
> > to me. (At least until we get better useful granularity for
> components,
> > but that's FFS :-)
> > 
> > - Werner
> > 
> 
> This is exactly what I was thinking. The problem is that last year when
> I wrote it they told me there was already cbq on the kernel plus the
> Alan Cox shaper so it was useless to try to add it.
> Then I had other things to do so I put it in a corner.
> 

Alan's shaper should really not be used. It was ok when we were poor ;->
With the TC infrastructure in place, i would recommend it get removed from
2.4. Someone should write shaper-compatibility scripts.

> Recently I have been asked again about my shaper, so I decided to update
> it to kernel 2.2 and 2.4 and to try to add it to the kernel
> distribution.
> (Unfurtunately it is not written as a module at the moment :-) )
> 
> This shaper can basicly do the following things:
> - Force a given Bandwidth
> - Change the HZ to use for the simulation
> - Force a given delay
>   - apply the delay in 2 different ways
> - Change the MTU (at that time it was not possible to do it with iproute
> - Modify the buffer size
> - Decide the layer where to work (2 or 3)
>   - decide what protocols (/etc/protocols) to leave unshaped (usefull
> for debugging purposes)
> - Very detailed graphical interface included 
> - maybe something else, I do not remember :-)
> 
> Of course you can change all of those parameters without rebooting the
> machine.
> 
> - Unlike the Alan Cox version, this one is not seen as a device. To
> change it to look like a device it would take a couple of days.
> At the moment it can only work with a single nic, but everything is
> ready for the multi-nic version and I have already ready (on paper) the
> patch for the multi nic buffer handling.
> 
> As I said before, at latest by the first week of september I'll put
> everything online. At the moment I have some problem with the real-time
> classifier. I wrote it without following the "cls_api", so now I am
> converting everything but there are some things not clear to me.
> 
> This classifier is very nice and it is supposed to work very well with a
> linux diffserv router. It can mark as EF all the multimedia realtime
> traffic (audio and video) and so you can imagine what you can do.
> 
> 

This is all great but really not that useful. Packet scheduling algorithms
have been studied for years. You have just invented another one, as
Alan did. I would suggest you go back and study your scheme again under 
an academic environment. I strongly disagree that it should go anywhere
close to the kernel; however,there might be some useful ideas there that
can be leveraged.

cheers,
jamal