incorrect ping(8) interval with powerd(8)
Eric Anderson
anderson at centtech.com
Thu Jun 16 11:15:33 GMT 2005
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.
Eric
--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------
More information about the freebsd-current
mailing list