Hardclock() not so hard on i386 lately.

[Caza, Aaron]

Greetings All,

I've been experiencing a problem with the hardclock() call not exhibiting the same determinism in the FreeBSD 8.1 i386 Stable snapshots since November.  In the October snapshot and previous releases, instrumenting the hardclock() to count ticks and using a kernel thread to print the output, I was seeing 1024hz with +/- 1 tick jitter .  Since November, however, I'm seeing a lot more jitter - 1016hz-1024hz.  To verify if the problem was with the time-keeping or the hardclock(), I modified the hardclock() to raise & lower a bit on the parallel port every tick and hooked it up to a frequency counter.  With the October release, I'm seeing 1023-1024hz as expected.  With the FreeBSD 8.2 i386 Jan 2011 snapshot I'm seeing 1016-1024hz.

Now, I know between Oct - Nov, the timecounter logic was modified to correctly allow for a 1-tick timecounter as prior to this the best it could do is every other tick; however, I wouldn't think that modifying the timecounter logic would have any bearing on the hard clock.  A diff of kern_clock.c betwix the two versions doesn't reveal anything useful.  Being relatively new to FreeBSD, I'm not certain where the next place I should be checking is.

FYI:  This is on an AMD Athlon II X2 235e Processor @ 2.7GHz running the SMP kernel.  Setting kern.smp.disabled=1 in /boot/loader.conf did not change the behavior.

Anyone got any useful pointers?

Thanks in advance,
Aaron
This message may contain confidential and privileged information. If it has been sent to you in error, please reply to advise the sender of the error and then immediately delete it. If you are not the intended recipient, do not read, copy, disclose or otherwise use this message. The sender disclaims any liability for such unauthorized use. PLEASE NOTE that all incoming e-mails sent to Weatherford e-mail accounts will be archived and may be scanned by us and/or by external service providers to detect and prevent threats to our systems, investigate illegal or inappropriate behavior, and/or eliminate unsolicited promotional e-mails (spam). This process could result in deletion of a legitimate e-mail before it is read by its intended recipient at our organization. Moreover, based on the scanning results, the full text of e-mails and attachments may be made available to Weatherford security and other personnel for review and appropriate action. If you have any concerns about this process, please contact us at dataprivacy at weatherford.com.
===============================
CONFIDENTIAL & PRIVILEGED COMMUNICATION

The information contained in this message is privileged, confidential, and protected from disclosure.
This message is intended for the individual or entity addressed herein. 
If you are not the intended recipient, please do not read, copy, use or disclose this communication to others. 
Also please notify the sender by replying to this message, and then delete it from your system. 
The sender totally disclaims, and will not accept, any responsibility or liability for the unauthorized use, 
or the consequences of any unauthorized use, of this communication or message.