Re: Time keeping Issues with the low-resolution TSC timecounter
Hmm... GPF seems to be related to unclean %rcx. Can you please try the attached patch? Please note you have to rebuild kernel from scratch because this is a header file change. It may not fix hang, though. Please let me know. It is just committed at r223796. JK This issue is resolved for me. Thanks Jung-uk! It's a far nicer fix than clobbering out TSC-low :). Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On 06/23/11 08:25, Jung-uk Kim wrote:
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
Jung-uk Kim wrote:
On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
Can you please try the attached patch? It should disable
TSC/TSC-low timecounter for your CPU models, I think.
Sorry, I attached a wrong patch. Please ignore the previous one
and try this, instead.
TSC-low is not presented as an option any more:
CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class
CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c
Stepping = 2
Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR
R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M
OVBE AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
Event timer LAPIC quality 400
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0:24-bit timer at 3.579545MHz port 0x408-0x40b on
acpi0 atrtc0:AT realtime clock port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer RTC frequency 32768 Hz quality 0
hpet0:High Precision Event Timer iomem 0xfed0-0xfed003ff irq
0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950
Event timer HPET frequency 14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
attimer0:AT timer port 0x40-0x43,0x50-0x53 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950)
ACPI-fast(900) dummy(-100)
It's already committed (r223426).
Thanks!
Jung-uk Kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
I had been holding off on csup on this machine for a moment:
Machine: Thinkpad SL410 Core2Duo T6570
I rm -rf /usr/src csup'd sources yesterday.
Issues still exist with TSC-low on Intel laptop hardware. Quality was
set to 1000, but time was inaccurate. Felt like 300 baud serial console
over a very long link!
I have C2 powerd:
/etc/sysctl.conf:
...
# Save electricity thermal
hw.pci.do_power_nodriver=3
hw.acpi.cpu.cx_lowest=C2
dev.cpu.1.cx_lowest=C2
dev.cpu.0.cx_lowest=C2
...
/etc/rc.conf:
...
#power
powerd_enable=YES
powerd_flags=-b adaptive -a maximum
...
I'm getting as far as
/usr/src/sys/x86/x86:
...
if (smp_cpus 1) {
tsc_timecounter.tc_quality = test_smp_tsc();
max_freq= 8;
...
test_smp_tsc() returns 1000, allowing TSC-slow to win.
Forcing this to 50 fixed all time/speed issues, allowing HPET to win.
I think the test for C3 above that may need to include additional
machines under its protection! I have no C3 support, but it's clear that
issues are occuring with TSC clocks even in C2 on intel platforms.
Matt
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 29 June 2011 05:50 pm, Matt wrote:
On 06/23/11 08:25, Jung-uk Kim wrote:
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote:
Jung-uk Kim wrote:
On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
Can you please try the attached patch? It should disable
TSC/TSC-low timecounter for your CPU models, I think.
Sorry, I attached a wrong patch. Please ignore the previous
one and try this, instead.
TSC-low is not presented as an option any more:
CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz
686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6
Model = 1c Stepping = 2
Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,
MTR
R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,
PBE
Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDC
M,M OVBE AMD Features2=0x1LAHF
TSC: P-state invariant, performance statistics
Event timer LAPIC quality 400
Timecounter ACPI-fast frequency 3579545 Hz quality 900
acpi_timer0:24-bit timer at 3.579545MHz port 0x408-0x40b on
acpi0 atrtc0:AT realtime clock port 0x70-0x77 on acpi0
atrtc0: Warning: Couldn't map I/O.
Event timer RTC frequency 32768 Hz quality 0
hpet0:High Precision Event Timer iomem
0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET
frequency 14318180 Hz quality 950 Event timer HPET frequency
14318180 Hz quality 450
Event timer HPET1 frequency 14318180 Hz quality 440
Event timer HPET2 frequency 14318180 Hz quality 440
attimer0:AT timer port 0x40-0x43,0x50-0x53 on acpi0
Timecounter i8254 frequency 1193182 Hz quality 0
Event timer i8254 frequency 1193182 Hz quality 100
kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950)
ACPI-fast(900) dummy(-100)
It's already committed (r223426).
Thanks!
Jung-uk Kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
freebsd-current-unsubscr...@freebsd.org
I had been holding off on csup on this machine for a moment:
Machine: Thinkpad SL410 Core2Duo T6570
I rm -rf /usr/src csup'd sources yesterday.
Issues still exist with TSC-low on Intel laptop hardware. Quality
was set to 1000, but time was inaccurate. Felt like 300 baud serial
console over a very long link!
I have C2 powerd:
/etc/sysctl.conf:
...
# Save electricity thermal
hw.pci.do_power_nodriver=3
This betther be set from /boot/loader.conf.
hw.acpi.cpu.cx_lowest=C2
dev.cpu.1.cx_lowest=C2
dev.cpu.0.cx_lowest=C2
There is no reason to do this here. Just add a line in /etc/rc.conf:
economy_cx_lowest=C2
...
/etc/rc.conf:
...
#power
powerd_enable=YES
powerd_flags=-b adaptive -a maximum
...
I'm getting as far as
/usr/src/sys/x86/x86:
...
if (smp_cpus 1) {
tsc_timecounter.tc_quality = test_smp_tsc();
max_freq= 8;
...
test_smp_tsc() returns 1000, allowing TSC-slow to win.
Forcing this to 50 fixed all time/speed issues, allowing HPET to
win.
I think the test for C3 above that may need to include additional
machines under its protection! I have no C3 support, but it's clear
that issues are occuring with TSC clocks even in C2 on intel
platforms.
Hmm... That's strange. Can you show me verbose dmesg output? Also,
I'd like to see 'acpidump -dt' output.
Sorry about the trouble.
Jung-uk Kim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. TSC-low is not presented as an option any more: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Event timer LAPIC quality 400 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Thursday 23 June 2011 04:21 am, Ian FREISLICH wrote: Jung-uk Kim wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. TSC-low is not presented as an option any more: CPU: Intel(R) Atom(TM) CPU N270 @ 1.60GHz (1596.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106c2 Family = 6 Model = 1c Stepping = 2 Features=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Event timer LAPIC quality 400 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 atrtc0: AT realtime clock port 0x70-0x77 on acpi0 atrtc0: Warning: Couldn't map I/O. Event timer RTC frequency 32768 Hz quality 0 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 attimer0: AT timer port 0x40-0x43,0x50-0x53 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 kern.timecounter.choice: TSC(-1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) It's already committed (r223426). Thanks! Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Friday 17 June 2011 02:54 pm, Jung-uk Kim wrote: On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote: Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037144590601.0098392393 1495969404144473671.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=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,M TR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,P BE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM ,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Thanks for the info, it confirmed my speculation. Somewhere from an Intel manual, I think I read TSC stops when DPSLP# pin is asserted for Core/Core2/Atom processors and I guess that means entering C3 stops TSC. :-( Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry for the delay, Jung-uk Kim Index: sys/dev/acpica/acpi_cpu.c === --- sys/dev/acpica/acpi_cpu.c (revision 223372) +++ sys/dev/acpica/acpi_cpu.c (working copy) @@
Re: Time keeping Issues with the low-resolution TSC timecounter
On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote:
Can you please try the attached patch? It should disable
TSC/TSC-low timecounter for your CPU models, I think.
Sorry, I attached a wrong patch. Please ignore the previous one and
try this, instead.
Jung-uk Kim
Index: sys/dev/acpica/acpi_cpu.c
===
--- sys/dev/acpica/acpi_cpu.c (revision 223372)
+++ sys/dev/acpica/acpi_cpu.c (working copy)
@@ -856,6 +856,8 @@ acpi_cpu_cx_list(struct acpi_cpu_softc *sc)
sbuf_printf(sb, C%d/%d , i + 1, sc-cpu_cx_states[i].trans_lat);
if (sc-cpu_cx_states[i].type ACPI_STATE_C3)
sc-cpu_non_c3 = i;
+ else
+ cpu_can_deep_sleep = 1;
}
sbuf_trim(sb);
sbuf_finish(sb);
Index: sys/kern/kern_clocksource.c
===
--- sys/kern/kern_clocksource.c (revision 223372)
+++ sys/kern/kern_clocksource.c (working copy)
@@ -59,6 +59,7 @@ __FBSDID($FreeBSD$);
cyclic_clock_func_tcyclic_clock_func = NULL;
#endif
+intcpu_can_deep_sleep = 0; /* C3 state is available. */
intcpu_disable_deep_sleep = 0; /* Timer dies in C3. */
static voidsetuptimer(void);
Index: sys/sys/systm.h
===
--- sys/sys/systm.h (revision 223372)
+++ sys/sys/systm.h (working copy)
@@ -253,6 +253,7 @@ voidcpu_startprofclock(void);
void cpu_stopprofclock(void);
void cpu_idleclock(void);
void cpu_activeclock(void);
+extern int cpu_can_deep_sleep;
extern int cpu_disable_deep_sleep;
intcr_cansee(struct ucred *u1, struct ucred *u2);
Index: sys/x86/x86/tsc.c
===
--- sys/x86/x86/tsc.c (revision 223372)
+++ sys/x86/x86/tsc.c (working copy)
@@ -444,6 +444,19 @@ init_TSC_tc(void)
goto init;
}
+ /*
+* We cannot use the TSC if it stops incrementing in deep sleep.
+* Currently only Intel CPUs are known for this problem unless
+* the invariant TSC bit is set.
+*/
+ if (cpu_can_deep_sleep cpu_vendor_id == CPU_VENDOR_INTEL
+ (amd_pminfo AMDPM_TSC_INVARIANT) == 0) {
+ tsc_timecounter.tc_quality = -1000;
+ if (bootverbose)
+ printf(TSC timecounter disabled: C3 enabled.\n);
+ goto init;
+ }
+
#ifdef SMP
/*
* We can not use the TSC in SMP mode unless the TSCs on all CPUs are
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim j...@freebsd.org wrote: On Tuesday 21 June 2011 04:53 pm, Jung-uk Kim wrote: Can you please try the attached patch? It should disable TSC/TSC-low timecounter for your CPU models, I think. Sorry, I attached a wrong patch. Please ignore the previous one and try this, instead. Works for me: fk@r500 ~ $dmesg | grep TSC Calibrating TSC clock ... TSC clock: 1995045800 Hz Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE TSC: P-state invariant, performance statistics TSC timecounter disabled: C3 enabled. Timecounter TSC frequency 1995045800 Hz quality -1000 Thanks a lot. Fabian signature.asc Description: PGP signature
Re: Time keeping Issues with the low-resolution TSC timecounter
On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037 144590601.0098392393 1495969404 144473671.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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037144590601.0098392393 1495969404144473671.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=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,MOVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Friday 17 June 2011 01:45 pm, Ian FREISLICH wrote: Jung-uk Kim wrote: On Thursday 16 June 2011 03:10 am, Ian FREISLICH wrote: Jung-uk Kim wrote: 1481522037 144590601.0098392393 1495969404 144473671.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=0xbfe9fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTR R,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x40c39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M OVBE AMD Features2=0x1LAHF TSC: P-state invariant, performance statistics Thanks for the info, it confirmed my speculation. Somewhere from an Intel manual, I think I read TSC stops when DPSLP# pin is asserted for Core/Core2/Atom processors and I guess that means entering C3 stops TSC. :-( Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? I have the same issue with my system (Atom N270). The effect that I see is about 29 wall clock seconds are recorded as 1 system second. Can please you send me output from the following? sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ sysctl kern.timecounter; sleep 1; done' Interesting it doesn't seem to be constant. While there was lots going on (launching exmh and scanning my mail folders opening and reading 20k files) keyboard repeats work as normal and xclock ticks one a second. When the activity stops, xclock ticks every 6 seconds. While the system clock recorded 10 seconds of wall clock, stopwatch ran for 42 seconds. Script started on Thu Jun 16 08:23:51 2011 [mini] /usr/home/ianf $ time sh -c 'count=10; while [ $count -gt 0 ]; do count=$((cou nt - 1)); sysctl kern.timecounter; sleep 1; done' kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 12748229 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3380795670 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 9828 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1915282150 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 4005701 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3480043331 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 22926 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1927865521 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 5223570 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3552023679 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 57522 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1940447630 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware: TSC-low kern.timecounter.stepwarnings: 0 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 5712953 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 3621090061 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 45866 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1953031506 kern.timecounter.tc.TSC-low.frequency: 12469046 kern.timecounter.tc.TSC-low.quality: 1000 kern.timecounter.smp_tsc: 1 kern.timecounter.invariant_tsc: 1 kern.timecounter.tick: 1 kern.timecounter.choice: TSC-low(1000) i8254(0) HPET(950) ACPI-fast(900) dummy(-100) kern.timecounter.hardware:
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim wrote: 1481522037144590601.0098392393 1495969404144473671.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. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
Jung-uk Kim j...@freebsd.org wrote:
On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
The problem I noticed first is that it takes unusually long
until a key press is repeated. With the default eventtimer
(HPET) it seems to take about 4s, which can be slightly
improved by switching to i8254.
The error beep seems to take longer than usual, too,
and the system feels sluggish in general.
An effect that is easier to measure is that the system is
unable to properly keep the time. Again the problem is less
severe when using i8254 instead of HPET:
[SNIP]
First of all, please do not mix timecounter issues with
eventtimer. They are not directly related.
Can you please show me verbose boot messages *without* your
patch? Does sysctl kern.timecounter.hardware=HPET help
*without* touching eventtimers?
I have the same issue with my system (Atom N270). The effect
that I see is about 29 wall clock seconds are recorded as 1
system second.
Can please you send me output from the following?
sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count -
1));\ sysctl kern.timecounter; sleep 1; done'
The OP sent me some data. The following is cooked data from what I
got:
TSC Delta Elapsed Time
---+---+
2245026970
2249708604 4681634 0.3003693189
2255874998 6166394 0.3956301509
2260656402 4781404 0.3067704701
2261993048 1336646 0.0857579744
2264175164 2182116 0.1400025497
2266445706 2270542 0.1456758803
2266987003 541297 0.0347291162
2267645095 658092 0.045757
2268274965 629870 0.0404118782
2268979787 704822 0.0452207294
2270482069 1502282 0.0963850274
2271140877 658808 0.0422685136
HPETDelta Elapsed Time
---+---+
1322734365
1337156221 144218561.0072408644
1351548130 143919091.0051493276
1365949265 144011351.0057936833
1380376349 144270841.0076059946
1394823985 144476361.0090413726
1409273964 144499791.0092050107
1423719753 144457891.0089123757
1438167064 144473111.0090186742
1452613630 144465661.0089666424
1467062977 144493471.0091608710
1481522037 144590601.0098392393
1495969404 144473671.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.
Can you please test the attached patch? Theoretically, it should not
make a difference but I'd like to see if it does, just in case.
As you suspected, it doesn't seem to make a difference:
fk@r500 ~/test/freebsd/timeissues $awk '/low.counter/ { o=c; c=$2; d=o?c-o:-;
print c d }' kern.timecounter2
3065017784 -
3066228257 1210473
3074551564 8323307
3081121276 6569712
3084706794 3585518
3087211252 2504458
3090413096 3201844
3100133126 9720030
3104014847 3881721
3105442070 1427223
fk@r500 ~/test/freebsd/timeissues $awk '/HPET.counter/ { o=c; c=$2;
d=o?c-o:-; print c d }' kern.timecounter2
3544564602 -
3559020869 14456267
3573467329 14446460
3587889861 14422532
3602318403 14428542
3616764316 14445913
3631211075 14446759
3645625298 14414223
3660038347 14413049
3674482395 1048
The unfiltered data is attached.
Fabian
kern.timecounter2
Description: Binary data
signature.asc
Description: PGP signature
Re: Time keeping Issues with the low-resolution TSC timecounter
The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: [SNIP] First of all, please do not mix timecounter issues with eventtimer. They are not directly related. Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? I have the same issue with my system (Atom N270). The effect that I see is about 29 wall clock seconds are recorded as 1 system second. I had do something similar to the OP to make my system useable since it doesn't seem possible to influence timecounter choice at boot time. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: [SNIP] First of all, please do not mix timecounter issues with eventtimer. They are not directly related. Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? I have the same issue with my system (Atom N270). The effect that I see is about 29 wall clock seconds are recorded as 1 system second. Can please you send me output from the following? sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ sysctl kern.timecounter; sleep 1; done' I had do something similar to the OP to make my system useable since it doesn't seem possible to influence timecounter choice at boot time. You can just add the following line in /etc/sysctl.conf for now: kern.timecounter.hardware=HPET Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote: On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote: The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: [SNIP] First of all, please do not mix timecounter issues with eventtimer. They are not directly related. Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? I have the same issue with my system (Atom N270). The effect that I see is about 29 wall clock seconds are recorded as 1 system second. Can please you send me output from the following? sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count - 1));\ sysctl kern.timecounter; sleep 1; done' The OP sent me some data. The following is cooked data from what I got: TSC Delta Elapsed Time ---+---+ 2245026970 2249708604 4681634 0.3003693189 2255874998 6166394 0.3956301509 2260656402 4781404 0.3067704701 2261993048 1336646 0.0857579744 2264175164 2182116 0.1400025497 2266445706 2270542 0.1456758803 2266987003 541297 0.0347291162 2267645095 658092 0.045757 2268274965 629870 0.0404118782 2268979787 704822 0.0452207294 2270482069 1502282 0.0963850274 2271140877 658808 0.0422685136 HPETDelta Elapsed Time ---+---+ 1322734365 1337156221 144218561.0072408644 1351548130 143919091.0051493276 1365949265 144011351.0057936833 1380376349 144270841.0076059946 1394823985 144476361.0090413726 1409273964 144499791.0092050107 1423719753 144457891.0089123757 1438167064 144473111.0090186742 1452613630 144465661.0089666424 1467062977 144493471.0091608710 1481522037 144590601.0098392393 1495969404 144473671.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. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Wednesday 15 June 2011 06:19 pm, Jung-uk Kim wrote:
On Wednesday 15 June 2011 04:39 pm, Jung-uk Kim wrote:
On Wednesday 15 June 2011 03:27 pm, Ian FREISLICH wrote:
The problem I noticed first is that it takes unusually long
until a key press is repeated. With the default eventtimer
(HPET) it seems to take about 4s, which can be slightly
improved by switching to i8254.
The error beep seems to take longer than usual, too,
and the system feels sluggish in general.
An effect that is easier to measure is that the system is
unable to properly keep the time. Again the problem is less
severe when using i8254 instead of HPET:
[SNIP]
First of all, please do not mix timecounter issues with
eventtimer. They are not directly related.
Can you please show me verbose boot messages *without* your
patch? Does sysctl kern.timecounter.hardware=HPET help
*without* touching eventtimers?
I have the same issue with my system (Atom N270). The effect
that I see is about 29 wall clock seconds are recorded as 1
system second.
Can please you send me output from the following?
sh -c 'count=10; while [ $count -gt 0 ]; do count=$((count -
1));\ sysctl kern.timecounter; sleep 1; done'
The OP sent me some data. The following is cooked data from what I
got:
TSC Delta Elapsed Time
---+---+
2245026970
22497086044681634 0.3003693189
22558749986166394 0.3956301509
22606564024781404 0.3067704701
22619930481336646 0.0857579744
22641751642182116 0.1400025497
22664457062270542 0.1456758803
2266987003541297 0.0347291162
2267645095658092 0.045757
2268274965629870 0.0404118782
2268979787704822 0.0452207294
22704820691502282 0.0963850274
2271140877658808 0.0422685136
HPET Delta Elapsed Time
---+---+
1322734365
1337156221144218561.0072408644
1351548130143919091.0051493276
1365949265144011351.0057936833
1380376349144270841.0076059946
1394823985144476361.0090413726
1409273964144499791.0092050107
1423719753144457891.0089123757
1438167064144473111.0090186742
1452613630144465661.0089666424
1467062977144493471.0091608710
1481522037144590601.0098392393
1495969404144473671.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.
Can you please test the attached patch? Theoretically, it should not
make a difference but I'd like to see if it does, just in case.
Thanks,
Jung-uk Kim
Index: sys/x86/x86/tsc.c
===
--- sys/x86/x86/tsc.c (revision 223102)
+++ sys/x86/x86/tsc.c (working copy)
@@ -579,6 +579,9 @@ tsc_get_timecount(struct timecounter *tc __unused)
static u_int
tsc_get_timecount_low(struct timecounter *tc)
{
+ uint32_t low, high;
- return (rdtsc() (int)(intptr_t)tc-tc_priv);
+ __asm __volatile(rdtsc; shrd %2,%1,%0
+ : =a (low), =d (high) : Ic ((uint8_t)(intptr_t)tc-tc_priv));
+ return (low);
}
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Time keeping Issues with the low-resolution TSC timecounter
On Monday 13 June 2011 12:44 pm, Fabian Keil wrote: I'm experiencing time-related issues that seem to be caused by the low-resolution TSC timecounter (r222866). The problem I noticed first is that it takes unusually long until a key press is repeated. With the default eventtimer (HPET) it seems to take about 4s, which can be slightly improved by switching to i8254. The error beep seems to take longer than usual, too, and the system feels sluggish in general. An effect that is easier to measure is that the system is unable to properly keep the time. Again the problem is less severe when using i8254 instead of HPET: [SNIP] First of all, please do not mix timecounter issues with eventtimer. They are not directly related. Can you please show me verbose boot messages *without* your patch? Does sysctl kern.timecounter.hardware=HPET help *without* touching eventtimers? Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
