Taku YAMAMOTO wrote:
> On Thu, 16 Oct 2008 09:28:44 -0600 (MDT)
> "M. Warner Losh" wrote:
>
>> In message: <48F75773.7030100@FreeBSD.org>
>> Alexander Motin 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 @ 2.40GHz (2394.01-MHz
K8-class CPU)
Origin = "GenuineIntel" Id = 0x6fb Stepping = 11
Features=0xbfebfbff MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,F XSR,SSE,SSE2,SS,
HTT,TM,PBE>
Features2=0xe3bd xTPR,PDCM>
AMD Features=0x20100800
AMD Features2=0x1
Cores per package: 2

FreeBSD 8.0-CURRENT amd64.

--
Alexander Motin
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis...reebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"