Date: Fri, 17 Jun 2011 13:23:26 -0400 From: Jung-uk Kim <jkim@FreeBSD.org> To: Ian FREISLICH <ianf@clue.co.za> Cc: freebsd-current@FreeBSD.org Subject: Re: Time keeping Issues with the low-resolution TSC timecounter Message-ID: <201106171323.43864.jkim@FreeBSD.org> In-Reply-To: <E1QX6j4-0000q5-Ff@clue.co.za> References: <201106151819.32495.jkim@FreeBSD.org> <201106151639.30308.jkim@FreeBSD.org> <E1QX6j4-0000q5-Ff@clue.co.za>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201106171323.43864.jkim>