Date: Wed, 22 Jun 2005 06:45:11 -0500 From: Eric Anderson <anderson@centtech.com> To: Andre Guibert de Bruet <andy@siliconlandmark.com> Cc: freebsd-current@freebsd.org Subject: Re: incorrect ping(8) interval with powerd(8) Message-ID: <42B94F47.1000506@centtech.com> In-Reply-To: <20050616103629.T42933@lexi.siliconlandmark.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <jeremie@le-hen.org> 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. Eric -- ------------------------------------------------------------------------ Eric Anderson Sr. Systems Administrator Centaur Technology A lost ounce of gold may be found, a lost moment of time never. ------------------------------------------------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42B94F47.1000506>