Time keeping Issues with the low-resolution TSC timecounter

Ian FREISLICH ianf at clue.co.za
Thu Jun 16 07:10:54 UTC 2011

Jung-uk Kim wrote:
> 1481522037	14459060	1.0098392393
> 1495969404	14447367	1.0090225853
> As you can see, HPET increases normally (within errors from sleep(3) 
> accuracy, syscall overhead, etc.) but TSC-low is totally erratic (and 
> too low).  I don't know how this can happen, though. :-(
> I need some time to figure it out.

Even though sleep states have been disabled in the past when on AC
power, they seem to have mysteriously been enabled.  Perhaps this
accounts for the strangeness:


[mini] /usr/home/ianf $ sysctl dev.cpu
dev.cpu.0.%desc: ACPI CPU
dev.cpu.0.%driver: cpu
dev.cpu.0.%location: handle=\_PR_.CPU0
dev.cpu.0.%pnpinfo: _HID=none _UID=0
dev.cpu.0.%parent: acpi0
dev.cpu.0.freq: 1600
dev.cpu.0.freq_levels: 1600/2000 1400/1750 1333/1533 1166/1341 1066/1066 932/932 800/600 700/525 600/450 500/375 400/300 300/225 200/150 100/75
dev.cpu.0.cx_supported: C1/1 C2/1 C3/57
dev.cpu.0.cx_lowest: C3
dev.cpu.0.cx_usage: 0.00% 8.69% 91.30% last 693us
dev.cpu.1.%desc: ACPI CPU
dev.cpu.1.%driver: cpu
dev.cpu.1.%location: handle=\_PR_.CPU1
dev.cpu.1.%pnpinfo: _HID=none _UID=0
dev.cpu.1.%parent: acpi0
dev.cpu.1.cx_supported: C1/1 C2/1 C3/57
dev.cpu.1.cx_lowest: C3
dev.cpu.1.cx_usage: 0.00% 14.96% 85.03% last 2897us

Pulling the power cord and re-inserting it has the cx_lowest correctly
trantsition to C1 and then TSC-low behaves properly as the system
timecounter.  But, time will be wierd when on battery.

In light of this, I doubt the patch in your other email will have
any effect.  Perhaps the thing to do is to have the timecounter
code aware of the lowest Cx sleep state and to pick best time counter
for that state and to re-evaluate the choice on cx_lowest transitions.

ie: TSC-low, HPET or ACPI-fast for C1 and HPET or ACPI-fast for C2 and lower.  


Ian Freislich

More information about the freebsd-current mailing list