From owner-freebsd-current@FreeBSD.ORG Fri Jun 17 17:45:14 2011 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F1B29106564A; Fri, 17 Jun 2011 17:45:13 +0000 (UTC) (envelope-from ianf@clue.co.za) Received: from inbound01.jnb1.gp-online.net (inbound01.jnb1.gp-online.net [41.154.0.151]) by mx1.freebsd.org (Postfix) with ESMTP id 34B478FC0C; Fri, 17 Jun 2011 17:45:13 +0000 (UTC) Received: from [41.154.88.19] (helo=clue.co.za) by inbound01.jnb1.gp-online.net with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1QXd6U-0004K2-It; Fri, 17 Jun 2011 19:45:10 +0200 Received: from localhost ([127.0.0.1] helo=clue.co.za) by clue.co.za with esmtp (Exim 4.72 (FreeBSD)) (envelope-from ) id 1QXd6S-0001Cu-Fo; Fri, 17 Jun 2011 19:45:08 +0200 Message-Id: To: Jung-uk Kim From: Ian FREISLICH In-Reply-To: <201106171323.43864.jkim@FreeBSD.org> References: <201106171323.43864.jkim@FreeBSD.org> <201106151819.32495.jkim@FreeBSD.org> <201106151639.30308.jkim@FreeBSD.org> X-Attribution: BOFH Date: Fri, 17 Jun 2011 19:45:08 +0200 Cc: freebsd-current@FreeBSD.org Subject: Re: Time keeping Issues with the low-resolution TSC timecounter X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 17:45:14 -0000 Jung-uk Kim wrote: > 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? The folowing is with timecounter=HPET, just to see what the effect on TSC-low is. It looks like it does stop in C3. hw.acpi.cpu.cx_lowest=C3 [mini] /usr/home/ianf $ sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1)); sysctl kern.timecounter.tc.TSC-low.counter; sleep 1; done' kern.timecounter.tc.TSC-low.counter: 722687906 kern.timecounter.tc.TSC-low.counter: 724328394 kern.timecounter.tc.TSC-low.counter: 726038743 kern.timecounter.tc.TSC-low.counter: 727690855 kern.timecounter.tc.TSC-low.counter: 729245616 kern.timecounter.tc.TSC-low.counter: 730786569 kern.timecounter.tc.TSC-low.counter: 732398571 kern.timecounter.tc.TSC-low.counter: 733910987 kern.timecounter.tc.TSC-low.counter: 735711469 kern.timecounter.tc.TSC-low.counter: 737368279 hw.acpi.cpu.cx_lowest=C2 kern.timecounter.tc.TSC-low.counter: 897318486 kern.timecounter.tc.TSC-low.counter: 909873821 kern.timecounter.tc.TSC-low.counter: 922416894 kern.timecounter.tc.TSC-low.counter: 934960462 kern.timecounter.tc.TSC-low.counter: 947504154 kern.timecounter.tc.TSC-low.counter: 960050573 kern.timecounter.tc.TSC-low.counter: 972590754 kern.timecounter.tc.TSC-low.counter: 985133990 kern.timecounter.tc.TSC-low.counter: 997677052 kern.timecounter.tc.TSC-low.counter: 1010220299 CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.04-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbff Features2=0x40c39d AMD Features2=0x1 TSC: P-state invariant, performance statistics Ian -- Ian Freislich