Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck?

On 15.08.2012 13:40, Lev Serebryakov wrote:
> You wrote 15 августа 2012 г., 14:18:05:
> AM> It is quite pointless to speculate without real info like mentioned
> AM> above KTR_SCHED traces. Main thing I've learned about schedulers, things
> AM> there never work as you expect. There are two many factors are relations
> AM> to predict behavior in every case.
>    I'll take these with as much variants (ULE and 4BSD, polling with
> HZ=1000 and interrupts with default HZ) as I can, in day or two.
>    Now I have kernels with KTR compiled in (GEN, NET and SCHED).
>
> AM> About Soekris and idle CPU measurement, let's start from what kind of
> AM> eventtimer is used there. As soon as it is UP machine, I guess it uses
> AM> i8254 timer in periodic mode. It means that it by definition can't
>   It doesn't have any other timers. You could think about this machine
> as about good old "true" i386, with PCI (and some additional fancy
> commands in CPU core, something like classic Pentium) but
> nothing more.
>
> kern.eventtimer.choice: i8254(100) RTC(0)
> kern.eventtimer.et.RTC.flags: 17
> kern.eventtimer.et.RTC.frequency: 32768
> kern.eventtimer.et.RTC.quality: 0
> kern.eventtimer.et.i8254.flags: 1
> kern.eventtimer.et.i8254.frequency: 1193182
> kern.eventtimer.et.i8254.quality: 100
> kern.eventtimer.periodic: 1
> kern.eventtimer.timer: i8254
> kern.eventtimer.activetick: 1
> kern.eventtimer.idletick: 0
> kern.eventtimer.singlemul: 2

Yes, that is what I expected to see there. If you have timecounter other 
then i8254, you can release i8254 from those duties to allow using it as 
one-shot setting hint.attimer.0.timecounter=0. Otherwise there are no 
options now.

> AM> properly measure load from treads running from hardclock, such as
> AM> dummynet, polling netisr threads, etc.
>    You see, here are two different problems:
>
> (a) with polling, system is responsive under any load, but wire2wifi
> performance  is hugely affected by wire2wire traffic (and mpd5
> inbetween). And, yes, "top" seems to lie about idle time.

I don't know why wifi is so different. Suppose it is for some reason 
more affected by latencies.

> (b) with interrupts, system works much better when it works (wire2wifi
> speed is affected by wire2wire traffic, but to much less extent), but
> it freezes every third minute for minute, when traffic is passed, but
> no user-level applications including BIND and DHCP server) works at
> all FOR MINUTE OR MORE. It not looks like 100ms lag, which could affect
> video playback. It looks like 60-120 seconds lag! At least, in case of
> ULE, I didn't try 4BSD yet.

In this case problem may be that kernel and interrupt threads are all 
having absolute priorities. It means until they release the CPU, 
user-level may get no CPU time at all. :(

-- 
Alexander Motin