Re: incorrect ping(8) interval with powerd(8)

On Thu, 16 Jun 2005, Eric Anderson wrote:
> M. Warner Losh wrote:
>> In message: <20050616075743.GE2239_at_obiwan.tataz.chchile.org>
>>             Jeremie Le Hen <jeremie_at_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?

Andy

/*  Andre Guibert de Bruet  * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/*   Code poet / Sysadmin   * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/*   GSM: +1 734 846 8758   * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com *      Tormenting bytes since 1980.       */