In article <20060625213923.fa3cfac9.smb@cs.columbia.edu>,
Steven M. Bellovin <smb@cs.columbia.edu> wrote:
>-=-=-=-=-=-
>
>On a machine with source from about 24 hours ago, time-keeping just
>doesn't seem to be very good.  Here's my ntpq output (peers selected via
>pool.ntp.org):
>
>$ ntpq -c peer
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>+raptor.tera-byt 132.163.4.102    2 u   52   64  377   65.294  -233.11  93.500
>*97.f7bed1.clien 130.207.244.240  2 u   47   64  377   17.832  -190.04  79.984
>+ferocious.dairi 140.142.16.34    2 u   50   64  377  130.086  -218.50  90.091
>+dns.ziandra.net 198.60.22.240    2 u   47   64  377  128.035  -216.76  90.929
>
>These offsets are fairly typical of what I've seen today, though sometimes
>one or two offsets will drop down:
>
>$ ntpq -c peer              
>     remote           refid      st t when poll reach   delay   offset  jitter
>==============================================================================
>+raptor.tera-byt 132.163.4.102    2 u   52   64  377   63.531   71.127 202.376
>*97.f7bed1.clien 198.30.92.2      2 u   52   64  377   17.832  -190.04 225.819
>+ferocious.dairi 140.142.16.34    2 u   50   64  377  130.086  -218.50 255.100
>+dns.ziandra.net 198.60.22.240    2 u   51   64  377  128.035  -216.76 255.084
>
>
>The timer is the ACPI timer (which I didn't even know existed...):
>
>$ sysctl kern.timecounter
>kern.timecounter.choice = clockinterrupt(q=0, f=100 Hz) TSC(q=-100,
>f=3391682240 Hz) ACPI_PM_TMR(q=900, f=3579545 Hz) i8254(q=100, f=1193182
>Hz) dummy(q=-1000000, f=1000000 Hz)
>kern.timecounter.hardware = ACPI_PM_TMR
>kern.timecounter.timestepwarnings = 0
>
>The machine itself is a Dell Dimension 8400 with hyperthreading; I've
>attached the dmesg.
>


Does it do better with i8254?

christos