incorrect ping(8) interval with powerd(8)
Andre Guibert de Bruet
andy at siliconlandmark.com
Wed Jul 6 19:15:19 GMT 2005
On Fri, 1 Jul 2005, Eric Anderson wrote:
> Eric Anderson wrote:
>> Andre Guibert de Bruet wrote:
>>> 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?
>>
>> 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?
What do the respective outputs of vmstat -i look like for either kernel?
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. */
More information about the freebsd-current
mailing list