Time keeping Issues with the low-resolution TSC timecounter
Matt
sendtomatt at gmail.com
Wed Jun 29 21:50:07 UTC 2011
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=0xbfe9fbff<FPU,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=0x40c39d<SSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,xTPR,PDCM,M
>> OVBE> AMD Features2=0x1<LAHF>
>> 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 0xfed00000-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(-1000000)
> It's already committed (r223426).
>
> Thanks!
>
> Jung-uk Kim
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at 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
More information about the freebsd-current
mailing list