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   _at_ 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