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

Re: Using TC to simulate wireless channels



> 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.

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.


   Christian Benvenuti