Date: Wed, 29 Jun 2011 14:50:00 -0700 From: Matt <sendtomatt@gmail.com> To: freebsd-current@freebsd.org Subject: Re: Time keeping Issues with the low-resolution TSC timecounter Message-ID: <4E0B9E08.1090202@gmail.com>
index | next in thread | raw e-mail
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@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@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. Matthelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E0B9E08.1090202>