Date: Sat, 21 Oct 1995 16:23:57 +1000 From: Bruce Evans <bde@zeta.org.au> To: freebsd-current@FreeBSD.org, joerg_wunsch@uriah.heep.sax.de, uhclem%nemesis@fw.ast.com, wollman@lcs.mit.edu Subject: Re: clock running faster? Message-ID: <199510210623.QAA07072@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>Now I will be the first to admit that the 14.31818MHz (4 x NTSC color burst >frequency - what a choice) clock that the traditional PC system clock is >based from (although a multiple of this is used frequently in newer machines) >isn't that easy to work with, at least it is consistent on all PCs, and >even a 200ppm error in a given crystal will still be a pretty small drift >in the system clock, once you get down to ~18.2/sec or ~100/sec or whatever >you have it programmed to. (This clock has to be reasonably accurate or >else RS-232 operations will suffer from bit errors.) The problem is that the 8254 clock takes about 5 usec to read (at least on 8MHz ISA buses) while the Pentium clock takes only about 7 cycles to read. The 8254 clock could be used as a reference to recalibrate the Pentium clock fairly often, but this would take more programming and be slower. >If a processor "tight loop" with interrupts disabled is used to determine >the processor clock speed (I suspect this is the case), such a routine can >be fooled by the methods some chipsets use for performing refresh, which Nope, it reads the Pentium cycle counter, delays for 1 second, then reads the cycle counter again, then takes the difference in the number of cycles. The possible error causes are: cycle counts: 0 resolution of DELAY(): 20 usec accuracy of DELAY(): same as that of the 8254 clock (worst I've seen is 7 parts in 10000) >Since a refresh cycle is simply an incomplete memory read cycle >(RAS but no CAS), the act of fetching instructions, reading and >writing memory all effectively perform refreshes, but not in a uniform >fashion. Old systems made no attempt to take advantage of the fact >the processor had accessed given memory rows recently, but many bus control >chipsets made since 1990 do, keeping "decay" counters that alert it to >when a row needs refreshing, and these counter are reset by the processor >accessing that row as part of one of its memory operations, a DMA cycle, >or a genuine refresh cycle. Er, Pentiums count their own cycles. The count is perfectly accurate and unaffected by bus activity. Perhaps the clock source is affected by bus activity. >This somewhat unpredictable refresh activity could probably explain >systems that people boot ten times get ten different processor speed >ratings for code that should be running "uninterruptable". The one second delay should be enough to compensate for bus activity. I think the variance is because the power on states are different. >Even if you argue that the complete timing test should end up being >executed from the processor cache and pipeline, since the full internal >workings of the Pentium (or its Pro buddy) are not public, we can't be >sure that residual memory writes from earlier operations aren't performed >during the actual timing test, or that memory reads for pipeline and >cache fills aren't occurring during the test. There isn't any good DELAY(1) executes the same instructions at least 200000 times. I hope the Pentium's pipelines are that long :-). > (Ask before SGMLing) >Frank Durda IV <uhclem@nemesis.lonestar.org>|"The Knights who say "LETNi" >or uhclem%nemesis@fw.ast.com (Fastest Route)| demand... A SEGMENT REGISTER!!!" >...letni!rwsys!nemesis!uhclem |"A what?" >...decvax!fw.ast.com!nemesis!uhclem |"LETNi! LETNi! LETNi!" - 1983 OK, who are the Knights who say "LETNi"? I know what a ******* REGISTER is :-). Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199510210623.QAA07072>