Date: Sat, 21 Oct 95 22:09 WET DST From: uhclem@nemesis.lonestar.org (Frank Durda IV) To: current@freebsd.org Subject: Re: clock running faster? Message-ID: <m0t6qmU-000IscC@nemesis.lonestar.org>
next in thread | raw e-mail | index | archive | help
[3]If a processor "tight loop" with interrupts disabled is used to determine [3]the processor clock speed (I suspect this is the case), such a routine can [3]be fooled by the methods some chipsets use for performing refresh, which [4]Nope, it reads the Pentium cycle counter, delays for 1 second, then reads [4]the cycle counter again, then takes the difference in the number of cycles. [4]The possible error causes are: [4] [4] cycle counts: 0 [4] resolution of DELAY(): 20 usec [4] accuracy of DELAY(): same as that of the 8254 clock [4] (worst I've seen is 7 parts in 10000) Understood, but you still can't guarantee what the processor is doing. The cycle counter may count "execution cycles" instead of "total cycles", thus not counting cycles spent on housekeeping operations, such as bus grants and bus recoveries. Now I know the answers to a few of these questions, having been allowed to gaze at the infamous Appendix a few years ago, but I can't say exactly what is going on here, nor can I be sure that Intel bothered with such minor details in that document. So just because they didn't mention it there doesn't mean they aren't doing it. We used to discover things all the time and go to Intel and they would say "yeah, it does that" or "yeah, but the next stepping fixes that". Let's just say that I am hinting that this isn't an accurate method across all of the Pentium line... Only an external logic analyzer can give mortals a truthful answer to this question, but then the answer would be correct for only a single stepping of the Pentium, as I know they have changed timing around, particularly in the laptop versions of the chip. Also, don't forget that you really don't have a 8254 anymore. The ISA chipset makers have long abandoned attempting to exactly mimic the timing oddities of a real 8254. There isn't a 8254 megacell in there, so all the timing charts in the 8254 databook are useless on modern designs. Unless you see a discrete part on the board that says 8254, and you are using an 80486 or higher design, you don't have a real 8254. The last chipset with a "real" licensed 8254 megacell was the Chips and Technology '206 chip (also licensed by Siemens), which was meant for 286 systems, but also got pasted into some low-end 386 systems. The same thing is true of the 8237. The megacells don't run the DMA at a speed under 5MHz, which is what a real 8237-5 (fastest speed ever produced) would do. These megacell DMAs run at 8.33MHz or sometimes 10MHz, plus they frequently don't have set-up and tear-down cycles between CPU and DMA bus acquisition. Each chipset is different in this area. The newer DMA systems even cover the deadly embrace that could be generated between a real 8237 and a 80x86 processor. It could not happen between a 8237 and a 8085 (these two parts were designed for each other), but that is what you get when IBM used 8-bit parts for their 16-bit system. So, the only timing for these subsystems that you can believe comes from the chipset makers databook for that one chipset. [4]DELAY(1) executes the same instructions at least 200000 times. I hope [4]the Pentium's pipelines are that long :-). It depends on how much of the cache the Pentium decide to load in for instructions that follow the delay loop while the loop is being timed. Pentium does look-thru (it looks through absolute and conditional jumps) pipeline loading, plus matching and spectulative cache loading, plus delayed memory writes. You might find that having two separate loops near one another will yield more accurate results. The first loop can be very small, on the order of (let me see) 1176 loops. This will guarantee any delayed writes (memory or I/O) have completed before your primary loop begins. Jump to the second loop using a CONDITIONAL opcode that can never fail, eg jz xyz when Z is always true when you arrive. Then your second loop should be followed by a branch into a small amount of code located between the first loop and second loop. This will guarantee that the clean-up code is already in cache (make it small) and then you can jump out of the twisty passages to the main stream of code. It looks nasty but will reduce the artifacts. Based on what I know, even the above tricks won't eliminate the issue. Perhaps a kernel -c parameter should allow the user to override clock timing selection, so they can choose the more accurate method for their system. On the Tandy XENIX systems, the TOD clock was based on video vertical sync timing, and wasn't very accurate, almost always fast. Subsequently the kernel had a routine added that the user could configure that could bump the clock forward a bit and back a bit at regular intervals to make things come out OK. All you had to do is set the system clock exactly right and at least two hours later run a utility and tell it what the wall clock was at that instant. The routine would spit out a pair of values for the kernel to use to compensate for drift (big jog and little jog, they could point in alternate directions and be applied at different points in time). The system TOD would be set to what you just told it, then you would go away for at least two hours (overnight was fine) and repeat the process. By now the clock value was pretty close, and the drift would be a second or two a week, instead of two minutes in a day. [3]Frank Durda IV <uhclem@nemesitar.org>|"The Knights who say "LETNi" [3]or uhclem%nemesis@fw.ast.com t Route)| demand... A SEGMENT REGISTER!!!" [3]...letni!rwsys!nemesis!uhclem |"A what?" [3]...decvax!fw.ast.com!nemesis! |"LETNi! LETNi! LETNi!" - 1983 [4]OK, who are the Knights who say "LETNi"? I know what a [4]******* REGISTER is :-). Ok, back in 1983 when I and others got suckered into bringing out the first computer based on the Intels latest and greatest 80186 processor, I wrote a script that was a take-off on "The Knights who say Ni" from Monty Python and the Holy Grail. What is "LETNi"? What is "LETNi" backwards? That used to be their logo. I thought of it after coming from sane and rational processor designs, suddenly having to deal with everything being backwards (indian among other things), plus these stupid segments. What a kludge. The script was published far and wide on the net (as it was back then) and several computers around the world adopted the name "letni" as their system name based on that script. See "letni.UUCP" or "letni.lonestar.org" as an example. I even got letters from engineers at Intel who enjoyed the joke, saying it went right over the heads of their management, so it could remain posted on walls for weeks without being distrubed. There was even a system somewhere at Intel called "letni", but I don't know if it is still there. The script closely follows the Monty Python sketch, right up to the point where some 80186-equivalent impossible task is demanded as in the original "You must cut down a the mightiest tree in the forest with.... a herring!". I think it had something to with doing a rep move string with a segment override and interrupts enabled, which is possible but unbelievably dangerous. 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?m0t6qmU-000IscC>