[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
> > simulation suffers ? I'd be surprised by the latter, though, because
> > 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
> > to me. (At least until we get better useful granularity for
> > 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
> (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
> - 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.