From owner-freebsd-current@FreeBSD.ORG Wed Aug 15 11:06:21 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 E41E71065673; Wed, 15 Aug 2012 11:06:20 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-lb0-f182.google.com (mail-lb0-f182.google.com [209.85.217.182]) by mx1.freebsd.org (Postfix) with ESMTP id BD3F78FC15; Wed, 15 Aug 2012 11:06:19 +0000 (UTC) Received: by lbbgk8 with SMTP id gk8so958398lbb.13 for ; Wed, 15 Aug 2012 04:06:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=yLEYJehd5dNE8hDdujybRUhRvGA1apRcmG1fbOWE+j4=; b=sPmN9OEO/UKNY9kxFKgg551/Vp3d+l3a63IziU6LqnHngmzkfSft4lMX9a1SOuuCQH tKBAvZz60mH7fzdQ21q4QawKrSCkVOgcWrzkb6jTP7q0JcH3cqmgg57i81G1mUoiEijj nfKtH+x3wqram/5198l045c30I6VTSIpKrmpXhNLAvgAa+GDNuJHOdC9JHPvhd/PwFv2 Exm4abiZnqWTBUudwX7L7Ip80EgHJ11p/pdJ7CjFGmOUsNa0zctR4cVkgAai9bZFN/cg cc4VNMc+mnEEekd4hrH88bPQqNp6ljBaI/tzbpa3CMEpwcc5ez61blEtQv1YEwP6q5Cr A8Hw== Received: by 10.112.88.34 with SMTP id bd2mr9100315lbb.33.1345028778405; Wed, 15 Aug 2012 04:06:18 -0700 (PDT) Received: from pc.mavhome.dp.ua (213-227-240-37.static.vega-ua.net. [213.227.240.37]) by mx.google.com with ESMTPS id i4sm312910lbg.17.2012.08.15.04.06.16 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 15 Aug 2012 04:06:17 -0700 (PDT) Sender: Alexander Motin Message-ID: <502B82F4.1090804@FreeBSD.org> Date: Wed, 15 Aug 2012 14:07:32 +0300 From: Alexander Motin User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:13.0) Gecko/20120621 Thunderbird/13.0.1 MIME-Version: 1.0 To: lev@FreeBSD.org References: <157941699.20120815004542@serebryakov.spb.ru> <502AE8B5.9090106@FreeBSD.org> <502B775D.7000101@FreeBSD.org> <1849591745.20120815144006@serebryakov.spb.ru> In-Reply-To: <1849591745.20120815144006@serebryakov.spb.ru> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 8bit Cc: Adrian Chadd , Doug Barton , 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: Wed, 15 Aug 2012 11:06:21 -0000 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