From owner-freebsd-current@FreeBSD.ORG Fri Jul 1 16:40:56 2005 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id F294D16A41C for ; Fri, 1 Jul 2005 16:40:55 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from mh2.centtech.com (moat3.centtech.com [207.200.51.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id A4E9743D48 for ; Fri, 1 Jul 2005 16:40:54 +0000 (GMT) (envelope-from anderson@centtech.com) Received: from [10.177.171.220] (neutrino.centtech.com [10.177.171.220]) by mh2.centtech.com (8.13.1/8.13.1) with ESMTP id j61GerAn079862; Fri, 1 Jul 2005 11:40:54 -0500 (CDT) (envelope-from anderson@centtech.com) Message-ID: <42C5720A.3030007@centtech.com> Date: Fri, 01 Jul 2005 11:40:42 -0500 From: Eric Anderson User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.8) Gecko/20050603 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andre Guibert de Bruet References: <20050616070445.GD2239@obiwan.tataz.chchile.org> <20050616.012302.48201645.imp@bsdimp.com> <20050616075743.GE2239@obiwan.tataz.chchile.org> <20050616.020442.31252848.imp@bsdimp.com> <42B15F2E.9050408@centtech.com> <20050616103629.T42933@lexi.siliconlandmark.com> <42B94F47.1000506@centtech.com> In-Reply-To: <42B94F47.1000506@centtech.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-current@freebsd.org Subject: Re: incorrect ping(8) interval with powerd(8) 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: Fri, 01 Jul 2005 16:40:56 -0000 Eric Anderson wrote: > Andre Guibert de Bruet wrote: > >> >> On Thu, 16 Jun 2005, Eric Anderson wrote: >> >>> M. Warner Losh wrote: >>> >>>> In message: <20050616075743.GE2239@obiwan.tataz.chchile.org> >>>> Jeremie Le Hen writes: >>>> : > : May you delve into this a little bit more please ? The >>>> ping(8) manual >>>> : > : page states that the -i flags makes ping(8) to wait a given >>>> couple of >>>> : > : seconds. If I use the flags "-i 1", I expect ECHO Requests to >>>> be sent >>>> : > : with one second between each, whatever the AC line status is. >>>> : > : (Note that I didn't explicitely specified "-i 1" in the above >>>> example, >>>> : > : but this doesn't change the behaviour.) >>>> : > : > Well, the rount trip times went way up (3x longer). That's >>>> normal for >>>> : > a 200MHz CPU... My 333MHz EISA machine can't do much better than >>>> : > that. >>>> : > : > But the 2.252s run time is a little longish. Do you see this >>>> : > consistantly? If you ran it a second time would you get identical >>>> : > results. I've seen ARP take a while... What else do you have >>>> running >>>> : > on the system? Maybe a daemon that takes almost no time at 1.7GHz >>>> : > takes a lot longer at 200Mhz and that's starving the ping >>>> process... >>>> : > Or some driver has gone insane... >>>> : : Yes, I ran this test multiple times, and I almost get always >>>> this same >>>> : result although I got 2.208s sometimes, but I don't think this is >>>> : significant. >>>> : : FYI, >>>> : my powerd(8) is configured to tastes AC-line four times per seconds. >>>> : I tried reducing it's freqency from 4 to 1, but it doesn't change >>>> : anything. >>>> : : ARP is not the culprit, the MAC address is already in cache. >>>> : : My kernel is compiled with INVARIANTS, but I don't have >>>> WITNESS. My >>>> : network interface uses the bge(4) driver. No firewall rule or >>>> complex >>>> : network setup. >>>> : : Anyway this doesn't hurt much. Thanks for lightening me. >>>> >>>> Dang, I was hoping it was one of the easy explainations.... Maybe it >>>> is the idle code not waking up fast enough when it has been asleep for >>>> a bit. But that's pure speculation at this point... >>> >>> >>> >>> Another datapoint - running -CURRENT as of about June 7th, I see this >>> too: >>> >>> $ time ping -i 1 -c 5 localhost >>> PING localhost (127.0.0.1): 56 data bytes >>> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.041 ms >>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.033 ms >>> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.029 ms >>> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.031 ms >>> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.035 ms >>> >>> --- localhost ping statistics --- >>> 5 packets transmitted, 5 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 0.029/0.034/0.041/0.004 ms >>> >>> real 0m9.728s >>> user 0m0.000s >>> sys 0m0.003s >>> >>> On a 5-STABLE machine: >>> $ time ping -i 1 -c 5 localhost >>> PING localhost (127.0.0.1): 56 data bytes >>> 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.049 ms >>> 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.032 ms >>> 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.024 ms >>> 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.021 ms >>> 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.032 ms >>> >>> --- localhost ping statistics --- >>> 5 packets transmitted, 5 packets received, 0% packet loss >>> round-trip min/avg/max/stddev = 0.021/0.032/0.049/0.010 ms >>> >>> real 0m4.064s >>> user 0m0.000s >>> sys 0m0.005s >>> >>> >>> I have powerd running, but it makes no difference whether I have it >>> running or not, nor does it make any difference if I'm on ac or battery. >>> >>> This worked fine a couple weeks back for me - the only thing I recall >>> changing is adding apic to my kernel. >> >> >> >> Just out of curiosity, does removing debugging options from your >> kernel config change anything? > > > Nope. And setting my scheduler back (from ULE) doesn't help either.. > > I'm thinking it must be a module, or something else I have installed. I > have set up another laptop just like mine, and it does not show the > issue. I'm still trying to track it down. After looking a little more, I noticed that booting into 'safemode' seems to get rid of the delay. Here's a snippet of a sysctl diff between two boots: 259,260c249,250 < kern.timecounter.hardware: ACPI-fast < kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-1000000) --- > kern.timecounter.hardware: TSC > kern.timecounter.choice: TSC(800) i8254(0) dummy(-1000000) I have apic in my kernel config, and I think teh safemode disables apic and acpi. I'm guessing it's an apic issue? Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------