A L . . . . . . . . . . . R |-2 | | | | | [z][h]LANDMARK SOFTWARE[] | [z]=1142 Pomegranate Court Sunnyvale CA 94087 408-733-4035[][~LM] | [b]IMPORTANT:[] SPEED and SETUP are neither public domain nor shareware programs. Rather, they are commercial programs. The two programs are sold as a package for $29.95. Companies wishing to bundle either or both program should contact Landmark Software for bundling prices. Dealers should ask about our DealerPak. Corporate users should contact us about multiple copy agreements and site licenses. [b]What Does SPEED Show?[] Use the F1 (HELP) key while running the program for a brief explanation. The 'MHz' reading relates the machine's speed to an 80286 machine operating with 1 wait state. A reading of say 12 MHz means that the machine is operating at the same speed as a 12 MHz 1 wait state AT (i.e., 80286 machine). If the machine accesses its memory without using a wait state, the readings will be higher (as they should be): [b]Machine Characteristics Typical Reading[] 4.77 MHz 8088 2.0 MHz 8 MHz 8088-2 3.3 MHz 6 MHz 1 wait state 80286 6.0 MHz 6 MHz 0 wait state 80286 7.8 MHz 8 MHz 1 wait state 80286 8.0 MHz 10 MHz 1 wait state 80286 10.0 MHz 8 MHz 0 wait state 80286 10.2 MHz 12 MHz 1 wait state 80286 12.0 MHz 10 MHz 0 wait state 80286 12.7 MHz 16 MHz 1 wait state 80386 18.0 MHz 16 MHz static col 80386 19.0 MHz 16 MHz interleaved 80386 20.0 MHz 16 MHz 64K cache 80386 23.0 MHz 20 MHz 1 wait state 80386 23.0 MHz 20 MHz static col 80386 24.0 MHz 20 MHz interleaved 80386 25.0 MHz 20 MHz 64K cache 80386 29.0 MHz 20 MHz 82385 cache 80386 32.5 MHz 20 MHz large cache 80386 32.8 MHz 25 MHz cache-based 80386 37.4-42.0 MHz So a Turbo 8088 running at 8 MHz is like a half-speed AT. And a 10 MHz 0 wait state 80286 is faster than a 12 MHz 1 wait state 80286. IBM's 80386 PS/2 Model 80 (the 16 MHz version with 1 wait state) gives a reading of 18 MHz which is just about exactly three times as fast as IBM's original 6 MHz 1 wait state 80286 AT (which was three times as fast as IBM's original 4.77 MHz 8088 PC or XT). | | - 1 - | | |-2 | | | | | The exact results produced by eliminating the memory wait state depend to some extent on the particular test-- the more that the test accesses memory (rather than working solely with registers), the more improvement you get by eliminating the wait state (up to a theoretical maximum of a 50% improvement). SPEED uses a computational algorithm that's reasonably representative of the work that real programs do; eliminating the wait state typically speeds up computational activity by 25% to 30%. SPEED is not affected by the presence of a math coprocessor (8087, 80287 or 80387). { Just as machines with an 8088 produce (much) lower readings than their nominal clock speed due to their slow 8- bit memory accesses, machines with an 80386 typically produce higher readings than their nominal clock speed due to the faster 32-bit memory access. For example, an 80386 running at 16 MHz with 1 wait state will typically be about as fast as an 18 MHz 1 wait state 80286 machine. } [b]IMPORTANT CAVEAT:[] Some machines, including many models made by Compaq, slow down when accessing the floppy drive. On such machines it is imperative that SPEED be loaded from the hard disk, not from a floppy disk. Otherwise the slow- down feature of the machine may interfere with SPEED's attempt to achieve location-independent readings on page mode and interleaved memory machines. [b]ABBREVIATED CHANGE HISTORY FOR LANDMARK'S SPEED[] [b]CHANGES IN SPEED VERSION 1.14 (7-20-89)[] Though we thought the 130 MHz limit of SPEED 1.13 was ample, one of our OEMs is already running into that limit-- only a month later! So SPEED 1.14's scale goes to 128 MHz and it will read accurately up to 200 MHz. We think that 25 MHz 486 machines will register over 100 MHz. [b]CHANGES IN SPEED VERSION 1.13 (6-15-89)[] One of our OEMs now has a prototype that exceeds the 100 MHz limit of SPEED 1.12. So we have extended SPEED's scale and range. SPEED 1.13's scale goes up to 80 MHz and it will read accurately up to 130 MHz. Our expectation is that a 25 MHz 486 will register somewhere in the 85 to 120 MHz range, which would be two to three times the speed of a 25 MHz cache-based 386. Incredible. | | | | | - 2 - | | |-2 | | | | | { [b]CHANGES IN SPEED VERSION 1.12 (9-6-88)[] On machines that have an interleaved or page mode memory architecture, the speed of any program varies depending on where the program is loaded in memory. With page mode memory, for example, if a program is loaded into memory so that its main loop happens to cross a page boundary, then the program will run slower than if the main loop were completely contained within a page. With benchmark programs, this phenomenon is particularly pronounced and can lead to much head scratching when the readings vary drastically depending on what resident utilities happen to be installed, what buffers setting was specified in CONFIG.SYS, what version of DOS is being used, etc.--because each of these items changes the location where the program gets loaded into memory. This can also lead users to erroneously conclude that the machine itself speeds up or slows down when one of these items is changed. } While this location-dependency is a quirk of certain memory architectures, rather than a deficiency in SPEED, it is undeniably an inconvenience and a source of confusion. As a result of many requests from users, we have attempted to modify SPEED so that it will give a constant reading regardless of where it is loaded in memory, even on machines with an interleaved or page mode memory architecture. { Version 1.12 represent our initial attempt to achieve that stability. Because of the diversity of memory architectures being used, we encourage users to test version 1.12 with various 'BUFFERS=' settings to determine whether the readings are constant. We welcome feedback on the results and recognize that additional modifications may be required for certain architectures. Your feedback is crucial in determining the need for such changes. } { [b]CHANGES IN SPEED VERSION 1.11 (8-29-88)[] Because one of our OEMs now has a prototype that exceeds a 60 MHz reading, we have once again extended SPEED's scale and range. } SPEED 1.11 has a scale that goes up to 64 MHz and will give accurate readings up to 100 MHz. When run on machines so fast that the reading would be greater than 100 MHz, a message appears advising the user to update to a later version of SPEED. SPEED 1.11 will thus accommodate not only the increasingly prevalent 25 MHz 80386 machines (that have readings up into the low 40's) but also the 33 MHz 80386 machines expected in 1989 that should reach the mid 50's. | | | - 3 - | | |-2 | | | | | [b]CHANGES IN SPEED VERSION 1.10 (1-1-88)[] SPEED 1.09 had a scale that went up to about 24 MHz and gave accurate readings up to 40 MHz. That seemed more than sufficient until we got a call from one of our OEMs whose latest prototype was exceeding 40 MHz. SPEED 1.10 has a scale that goes up to 40 MHz and will give accurate readings up to 60 MHz. That should be adequate for at least a couple of months. [b]CHANGES IN SPEED VERSION 1.09[] Prior to this version, the test algorithm always required the same amount of work regardless of the speed of the machine. When SPEED was originally developed, the fastest machines required about 100 ms to execute this algorithm--so the 1 ms precision of our timing yardstick produced a maximum error of about 1% which translated into about 0.1 MHz on a 10 MHz reading--which not long ago represented the state of the art. With ever faster machines becoming available, some 80386 machines are now able to execute this algorithm in 30 ms or less; since the accuracy of our timing yardstick is about 1 ms, this implies about a 3% error rate on a 32 MHz reading--which means that the MHz reading could bounce around a full 1 MHz. In order to achieve more stable readings, particularly on the higher speed 80386 machines, SPEED now dynamically scales the duration of the actual test based on the results of the most recent test. For example, SPEED may sometimes double the amount of work required to execute the algorithm, and then divide the resulting time by 2. The net result is that the time required to execute the scaled algorithm is always about 200 ms for any machine that's running at least as fast as a 6 MHz IBM AT. Consequently, the maximum error has been reduced to about half of 1%, regardless of how fast the machine may operate. Thus the maximum variation even on a 40 MHz reading should now be about 0.2 MHz. So the MHz reading should now be much more stable on fast 80386 machines. In all cases the new, more stable reading should be within the range displayed by earlier versions of SPEED. For the benefit of users who are accustomed to earlier versions of SPEED, the millisecond figure at the bottom right of the screen now shows what the duration of the test would have been if we weren't scaling it dynamically. [b]CHANGES IN SPEED VERSION 1.08[] Minor cosmetic changes to the screen appearance. | | | - 4 - | | |-2 | | | | | [b]CHANGES IN SPEED VERSION 1.07[] Added the '$' (COST) function key option that shows the cost of the program, the usage restrictions and tells how to determine if you have a legitimate copy of the program. { [b]CHANGES IN SPEED VERSION 1.06[] In the default high-precision mode, SPEED now restores the original channel 0 countdown value that was in effect when SPEED began rather than restoring the value that BIOS installed at boot time. This could in theory be necessary if some other program has reprogrammed the channel 0 timer. } [b]CHANGES IN SPEED VERSION 1.05[] If necessary, SPEED will switch into 25-line mode at the beginning of the program and will restore the original font upon exit. { [b]CHANGES IN SPEED VERSION 1.04[] SPEED now uses a logarithmic scale to extend the maximum MHz reading from about 15 MHz to nearly 25 MHz. For even faster machines--such as some of the 20 MHz 80386 systems-- the MHz and 'x' readings will be accurate and the bar will simply stop at the far right edge of the screen. Thus accurate readings are possible for machines up to 40 MHz or even higher. } { [b]CHANGES IN SPEED VERSION 1.03[] SPEED now makes sure that the current video page is 0 at the beginning of the program--assures compatibility with the /Q=1 option of Fansi-Console. } | | | | | | | | | | | | | | | - 5 - | | |-2 | | | | | { [b]CHANGES IN SPEED VERSION 1.02[] [b]More Accurate 'x times as fast' Readings[] One of the primary applications for the SPEED program is on IBM AT's and compatibles that have a variable clock rate-- especially those that permit the clock rate to be changed from within an application program such as SPEED. In order to function nicely in such an environment, the speed shown must respond quickly to changes in the clock rate. That means that the duration of the benchmark used must be short-- say around a tenth of a second on AT class machines. } { It isn't trivial to time short durations accurately. There are normally only 18.2 ticks per second, so there are about 55 milliseconds between ticks--about one twentieth of a second. Obviously if we try to measure something that's only 1/10th of a second long with a clock that has only 1/20th of a second resolution, we'll find that the results often won't vary when we change the clock rate and will bounce around erratically at other times. Very unsatisfactory. } There is a way of achieving greater accuracy: Speed up the number of ticks we can count, but do it in a way that won't affect the time of day clock. That's what SPEED has always done in its default mode. We speed things up by a factor of 64, which means that there's a bit less than 1 millisecond between our fast ticks. This gives us plenty of accuracy for timing a 100 ms benchmark. The fast ticks would seem to solve all of our timing problems, but they don't. Here's why: With the normal 18.2 tick rate, the work required for the system to process the ticks is negligible. Even on an IBM PC running at 4.77 MHz, tick processing takes far less than 1% of the machine's capacity. But this situation changes dramatically when we increase the tick rate by a factor of 64. Now the tick processing takes about 18% of a PC's capacity, so the entire machine slows down by about 22%. In contrast, on an AT class machine, the tick processing takes less than 10% of capacity, so 6 MHz AT's only slow down by about 7%. The result is that the relative speed of an AT vs. a PC changes when we use the faster tick rate--the measurement process affects the results. For example, using the normal tick rate, a 6 MHz AT is 3.0 times as fast as a 4.77 MHz PC. But with the fast ticks, we get a factor of 3.5 times--because processing the faster tick rate slows down the PC more than it does the AT. To compensate for this, we've developed an adjustment formula which converts the fast tick results to approximately what we would have gotten with the normal tick rate--while retaining the greater accuracy that the fast tick rate provides. This adjustment formula makes its debut in SPEED version 1.02. As a result, you may notice that the 'x times as fast' readings from SPEED 1.02 are lower than with earlier | | | - 6 - | | |-2 | | | | | versions of SPEED; the 'MHz' readings remain unchanged except for some very minor tweaking. You can check out the effectiveness of this new adjustment procedure by comparing the results of SPEED's default mode--which uses fast ticks plus the adjustment formula--versus SPEED's new network compatible "P-" (non- precision) mode which uses a much longer benchmark and doesn't change the tick rate. Both modes should produce the same results--indeed the desire to have both modes produce the same results was the primary motivation for developing and implementing the adjustment formula. [b]Network Compatibility[] If you've experienced difficulty using SPEED in a network environment, there's now a simple solution: just type SPEED P- to invoke the new 'non-precision' mode which makes SPEED compatible with all networks. Most networks find it necessary to reprogram the timer in much the same way that SPEED does in its default mode (discussed above). Unfortunately the architecture doesn't lend itself to having two programs attempting to reprogram the timer. The result is often a crash. Therefore we've added a new mode which does not reprogram the timer at all. Because the purpose of the "P-" mode was to achieve network compatibility, we have to use the standard tick rate of 18.2 per second. In order to achieve acceptably stable results in the "P-" (non-precision) mode despite this poor timing resolution, we inevitably had to drastically increase the duration of the benchmark: the benchmark takes 12 times longer than in the default mode. For example, on a 4.77 Mhz PC, it takes about about 6 seconds for each test in the "P-" mode vs. about half a second in the default mode. Even so, the results are about 5 times less precise: Remember that the resolution is only 55 ms vs. less than 1 ms in the precision mode; we'd have to increase the duration by a factor of 64 to achieve the same precision. So you may notice that the readings are less stable in the "P-" (non- precision) mode. { Although the "P-" mode is very unresponsive to speed changes, it works fine if you're just trying to see how fast the terminals of a multi-user system are functioning. } | | | | | | - 7 - | | |-2 | | | | | { [b]DESQview Compatibility[] When running SPEED under DESQview, the "P-" non- precision mode is required for accurate (though erratic) readings--otherwise SPEED will produce unrealistically high readings due to DESQview's manipulation of the timer. Specify "SPEED P-" as the command to start the program. Specify that the program writes directly to the screen (and hence can only be run in a full-screen-size window) and that the window should be closed upon exit to DOS. Unfortunately all this implies that you'll only be able to see the speed of the foreground window. But at least you'll be able to see how fast the foreground operates with various other tasks running in the background. And, if necessary you can note the number of tests performed while the program was operating in the background. If the SPEED screen becomes garbled, try toggling to the HELP screen and then back to the main SPEED screen. } [b]Using SPEED's Reliability Test[] In addition to showing how fast your system is running, SPEED also contains two reliability tests that are performed automatically. If your system fails either test, an additional line of data will appear immediately below the 'Current test' line near the bottom of the screen. This will show the cumulative number of malfunctions and a breakdown between the two different types of malfunctions that SPEED can detect. The first type of malfunction involves the conversion of real numbers to strings. If this occurs, a 'System Malfunction' message will appear briefly within the horizontal bar; the line of malfunction info will appear beneath the 'Current test' line; the malfunction count will be incremented; and the count of 'str' (string) errors will be incremented. The second type of malfunction is involves simple integer arithmetic. If this occurs, a 'SYSTEM MALFUNCTION' message (all caps) will appear briefly within the horizontal bar; the line of malfunction info will appear; the malfunction count will be incremented; and the count of 'counter' errors will be incremented. If you have a continuously variable speed switch, you can demonstrate that SPEED is able to detect malfunctions without hanging: Turn up the speed to within about .2 MHz of the speed where the system hangs. Then turn up the speed in extremely small increments. Usually you'll see a 'System Malfunction' or 'SYSTEM MALFUNCTION' message flash in the horizontal bar before the system hangs. Even after the 'System Malfunction' message appears, often you'll be able to turn down the speed enough to eliminate the malfunctions without having the system hang. | | | - 8 - | | |-2 | | | | | Once you decide on a maximum speed, we recommend that you run SPEED overnight with the system running at your chosen speed. If the system is still running in the morning and there is no 'malfunction' count at the bottom of the screen, then the odds of reliable operation at that speed are good. We also recommend that you run the IBM Advanced Diagnostics for the AT overnight at the chosen speed, testing the system board and the installed memory. [b]On Programs that Perform a Special CTRL-ALT-DEL[] As explained above, SPEED normally reprograms the timer to increase the tick rate (without affecting the time of day calculations); upon normal termination (i.e., when you press the ESC key), SPEED reestablishes the normal tick rate. Even if you exit from SPEED by pressing CTRL-ALT-DEL, all is normally well since the standard warm boot process reestablishes the default tick rate. However, some resident utilities watch for CTRL-ALT-DEL and upon detection perform a special 'partial' warm boot. For example, the Tall Tree Systems JBOOT driver does this in order to be able to preserve the contents of a ram disk through a warm boot. If you have a 'partial boot' utility installed and if you press CTRL-ALT-DEL while running SPEED in the default high-precision mode, the warm boot may fail because the 'partial boot' may not reestablish the normal tick rate. Therefore, if you use a 'partial boot' resident utility, you should always exit from SPEED by pressing the ESC key, not by pressing CTRL-ALT-DEL. Once you have returned to the DOS prompt, you can of course use CTRL-ALT- DEL with no problem. (If you forget, the 'partial warm boot' will likely hang the system, requiring use of the BRS--Big Red Switch.) { [b]Compatibility with Other Programs[] Except for the precision timing feature of SPEED--which can be turned off by using the 'P-' option on the command line--SPEED should coexist peacefully with everything. } When the default precision timing feature is being used, SPEED increases the tick rate by a factor of 64 and installs its own interrupt 8 handler which, once every 64 invocations, calls the standard interrupt 8 handler. Thus the standard interrupt 8 handler gets called at the normal rate, hence the time-of-day clock is accurately maintained. Upon exit from SPEED, the channel 0 timer is reprogrammed to whatever countdown value was being used initially; and the standard interrupt 8 handler is reinstalled. All this is a rather standard, widely-used technique for precision timing. | | | - 9 - | | |-2 | | | | | { A very small number of programs cannot cope with the commonly used precision timing technique used by SPEED. We only know of two such programs: } Although most versions of Fansi-Console work fine with SPEED, Fansi-Console 2.00D, 2.00E and 2.00F contained major changes which conflicted with SPEED. These versions, although they didn't reprogram channel 0, assumed that nothing else would reprogram channel 0. Consequently the first keystroke within SPEED was very likely to hang the machine. While usually the first keystroke was the ESC to return to DOS, you could easily verify that just toggling to and from the help screen would hang the system within the first few keystrokes if you were using one of those three versions of Fansi-Console. These problems were resolved starting with Fansi-Console 2.00G which once again works fine with SPEED. We have also had reports of similar problems with Super PC Kwik, a caching program that, although it doesn't reprogram the channel 0 timer, does install its own interrupt 8 handler. While in theory this should not necessarily be a problem, there reportedly is a conflict here. As in all such cases, the 'P-' option can circumvent the problem. [z][g]Landmark Software[] [b]1142 Pomegranate Court[] [b]Sunnyvale, CA 94087[] [b]408-733-4035[] | | | | | - 10 - | | |-