Hi, It becomes possible to play with a bunch of CPU-related timers in the 2.6.13-rc series, which MAY help (but no guarantees). The latest tree also has some scheduling fixes which probably won't make much of a difference to you. Standard distro kernels tend to be compromises, which means they'll be OK for everything but great at nothing. If you want to squeeze every last bit of performance out of the machine, you'll need to do some kernel configuration work. The latest "vanilla" kernel is 2.6.13-rc3 and the latest Andrew Morton release is 2.6.13-rc3-mm1 (The differences that MAY be useful to you is that the -mm release has some driver fixes for ethernet cards.) If you roll your own kernel and are wanting to use it for a bridge setup, my guess is you want to use the server settings for preempt (no forced preemption - ie: pretty much disable it) but would likely want to use the desktop settings for the timer frequency (1000 Hz) as that gives the fastest response to events. (If you're using an SMP machine, 250 Hz might be better, as SMP doesn't like lots of interrupts.) Depending on who you ask and what phase the moon is in, different people give different opinions about whether to compile in or use modules. Compiled-in drivers MAY be marginally faster and MAY eat fractionally less kernel memory, which MIGHT trim down latency a little. If that's not serious voodoo enough, don't compile in any network layers you're not using. Every layer is absolutely going to add latency, because it is extra code to run. Finally, and this is going to be the hardest step, it MAY be possible to get the Linux kernel to compile with the latest Intel C compiler. If you're using a genuine Intel processor, the speedup is something like 40% - for AMD or other ix86 processors, GCC is either equal to or faster than Intel's compiler. The problem with using Intel's C compiler is that it has very different ideas on what is ok than GCC, so the kernel won't necessarily compile. Sometimes people put icc patches out, to fix this, but not all kernels have patches and the kernel of interest is a pre-release, making patches less likely in the event they are needed. Any of these steps should trim a little latency off, and if you somehow manage all of them, you should get quite a decent improvement. Whether the improvement is worth the effort required is another matter. --- "Christian Konecny (VI/SEA)" <christian.konecny@xxxxxxxxxxxx> wrote: > Hi there! > > I am working a lot with VoIP in my company, so I > thought to use linux bridge functionality together > with tc to emulate delay, jitter, packet loss, > duplication, reordering etc. for testing purposes in > our lab against our VoIP products. > I just recognized, that a basic bridge just with > it's minumum configuration of 2 network interfaces > creates latency of approx. 5ms on very low traffic. > This seems to be independent on CPU speed. I tried > on 2 GHz PC while having just 64kBit traffic with > packet size of about 300bytes. > I am using Knoppix 3.82 which is actually a debian > Live-CD Linux, Kernel 2.6.11. > For some reason they put iproute2 041019 on this > distro, which is intended to be used for kernel > 2.6.9. > I am aware of remastering the CD, but have to check > if it is possible to recompile the kernel for the > remaster. > > back to my question: where does this latency come > from? > "top" shows almost no load while the bridge is > handling traffic, so how come? > is there some timer-granularity which can be set in > the kernel, is the latency normal, or what could > cause it else? > > Thank you very much in advance! > > /Christian > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
