Date: Wed, 15 Aug 2012 15:11:49 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: Adrian Chadd <adrian@freebsd.org>, Doug Barton <dougb@FreeBSD.org>, current@freebsd.org Subject: Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck? Message-ID: <938388715.20120815151149@serebryakov.spb.ru> In-Reply-To: <502B82F4.1090804@FreeBSD.org> References: <157941699.20120815004542@serebryakov.spb.ru> <CAJ-Vmon86-FPs4%2BXXkQXAow1jW465pMM2Sj7ZHi_0_E9VYSFSA@mail.gmail.com> <502AE8B5.9090106@FreeBSD.org> <502B775D.7000101@FreeBSD.org> <1849591745.20120815144006@serebryakov.spb.ru> <502B82F4.1090804@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Alexander. You wrote 15 =E0=E2=E3=F3=F1=F2=E0 2012 =E3., 15:07:32: AM> Yes, that is what I expected to see there. If you have timecounter other AM> then i8254, you can release i8254 from those duties to allow using it as AM> one-shot setting hint.attimer.0.timecounter=3D0. Otherwise there are no= =20 AM> options now. % dmesg | grep timer pmtimer0 on isa0 Event timer "RTC" frequency 32768 Hz quality 0 attimer0: <AT timer> at port 0x40 on isa0 Event timer "i8254" frequency 1193182 Hz quality 100 % >> (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. AM> I don't know why wifi is so different. Suppose it is for some reason AM> more affected by latencies. Adrian says, it is. >> (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. AM> In this case problem may be that kernel and interrupt threads are all AM> having absolute priorities. It means until they release the CPU,=20 AM> user-level may get no CPU time at all. :( How could it be seen in KTR traces? Where could I read how to decipher and read these traces? --=20 // Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?938388715.20120815151149>