Taku YAMAMOTO wrote: > On Thu, 16 Oct 2008 09:28:44 -0600 (MDT) > "M. Warner Losh" <imp_at_bsdimp.com> wrote: > >> In message: <48F75773.7030100_at_FreeBSD.org> >> Alexander Motin <mav_at_FreeBSD.org> writes: >> : No, it's opposite. With lower frequency I have proportionally smaller >> : delays (more loop iterations). I don't remember exact numbers now, but >> : general tendency was like: with 2400MHz - 10 iterations, with 1200MHz - >> : 20 iterations and with 100MHz - 240 iterations. But neither syslog, nor >> : my eyes saw any visible delay there. >> >> You have more iterations. I'd have expected less. This doesn't say >> anything at all about DELAY, per se. If you are waiting for 1M cycles >> at 100MHz, it is only .01s, while at 10MHz it is .1s. Delay is >> implemented by reading a counter in the 8254 that's been calibrated. >> So unless the clock that's clocking it is running FASTER, delay won't >> be the source of additional iterations. >> >> Hmmm, looking at the i386 delay code, it looks like it depends on >> tsc_frequency being right when tsc isn't broken. If that's set >> bogusly, that could cause DELAY to be slower... > > I have a Core 2 Duo whose TSC ticks regardless of how EST is set. > In conjunction of tsc_freq_changed() function defined in tsc.c, > tsc_freq becomes lower than actual, thus shorter DELAY(). > > Maybe his machine has the same. Indeed: CPU: Intel(R) Core(TM)2 Duo CPU T7700 _at_ 2.40GHz (2394.01-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x6fb Stepping = 11 Features=0xbfebfbff<FPU,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> Features2=0xe3bd<SSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16, xTPR,PDCM> AMD Features=0x20100800<SYSCALL,NX,LM> AMD Features2=0x1<LAHF> Cores per package: 2 FreeBSD 8.0-CURRENT amd64. -- Alexander MotinReceived on Thu Oct 16 2008 - 15:25:38 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC