From owner-freebsd-current@FreeBSD.ORG Thu Aug 16 17:47:16 2012 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 02A26106566C for ; Thu, 16 Aug 2012 17:47:16 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta09.emeryville.ca.mail.comcast.net (qmta09.emeryville.ca.mail.comcast.net [76.96.30.96]) by mx1.freebsd.org (Postfix) with ESMTP id D61B58FC12 for ; Thu, 16 Aug 2012 17:47:15 +0000 (UTC) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta09.emeryville.ca.mail.comcast.net with comcast id nVQg1j0021Y3wxoA9Vn9BV; Thu, 16 Aug 2012 17:47:09 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta15.emeryville.ca.mail.comcast.net with comcast id nVn71j00W4NgCEG8bVn89T; Thu, 16 Aug 2012 17:47:08 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id q7GHl6cX017218; Thu, 16 Aug 2012 11:47:06 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: lev@freebsd.org In-Reply-To: <1849591745.20120815144006@serebryakov.spb.ru> References: <157941699.20120815004542@serebryakov.spb.ru> <502AE8B5.9090106@FreeBSD.org> <502B775D.7000101@FreeBSD.org> <1849591745.20120815144006@serebryakov.spb.ru> Content-Type: text/plain; charset="koi8-r" Date: Thu, 16 Aug 2012 11:47:06 -0600 Message-ID: <1345139226.27688.48.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 8bit Cc: current@freebsd.org Subject: Re: CURRENT as gateway on not-so-fast hardware: where is a bottlneck? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Aug 2012 17:47:16 -0000 On Wed, 2012-08-15 at 14:40 +0400, Lev Serebryakov wrote: > Hello, Alexander. > 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 > > 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. > > (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. > I had trouble earlier this year with an industrial single-board computer that uses the same chipset as your Soekris (Geode 500 + CS5536) where the interrupt handler for the RTC chip would occasionally get stuck in a loop for a minute or more at a time, making userland processes completely unresponsive during that time. It's a long shot, but if the trouble you're seeing has the same cause, it should be fixed by this patch: http://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037233.html -- Ian