Re: Time keeping Issues with the low-resolution TSC timecounter

From: Jung-uk Kim <jkim_at_FreeBSD.org>
Date: Fri, 17 Jun 2011 13:23:26 -0400
On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote:
> 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:
>
> /etc/rc.conf
> performance_cx_lowest="HIGH"
> performance_cpu_freq="HIGH"
> economy_cx_lowest="LOW"
> economy_cpu_freq="HIGH"
>
>
> [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.

Hmm...  So, you are saying this CPU model is P-state invariant but not 
C-state invariant (i.e., it stops incrementing in C2 state and 
above).  If that's the case, it is really useless for 
timecounter. :-(

What happens if you set it to C2, i.e.,

economy_cx_lowest="C2"

In other words, does it really stop in C2-state?

Jung-uk Kim
Received on Fri Jun 17 2011 - 15:23:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC