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. -- -|-__ YAMAMOTO, Taku | __ < <taku_at_tackymt.homeip.net> - A chicken is an egg's way of producing more eggs. -Received on Thu Oct 16 2008 - 14:39:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:36 UTC