Pentium-specific issues in dosemu This section written by Alberto Vignani <> , Aug 10, 1997 The pentium cycle counter On 586 and higher CPUs the 'rdtsc' instruction allows access to an internal 64-bit TimeStamp Counter (TSC) which increments at the CPU clock rate. Access to this register is controlled by bit 2 in the config register cr4; hopefully under Linux this bit is always off, thus allowing access to the counter also from user programs at CPL 3. The TSC is part of a more general group of performance evaluation registers, but no other feature of these registers is of any use for dosemu. Too bad the TSC can't raise an interrupt! Advantages of the TSC: it is extremely cheap to access (11 clock cycles, no system call). Drawbacks of using the TSC: you must know your CPU speed to get the absolute time value, and the result is machine-class specific, i.e. you can't run a binary compiled for pentium on a 486 or lower CPU (this is not the case for dosemu, as it can dynamically switch back to 486-style code). How to compile for pentium There are no special options required to compile for pentium, the CPU selection is done at runtime by parsing /proc/cpuinfo. You can't override the CPU selection of the real CPU, only the emulated one. Runtime calibration At the very start of dosemu the bogospeed() function in base/init/config.c is called. This function first looks for the CPUID instruction (missing on 386s and early 486s), then looks for the CPUSPEED environment variable, and at the end tries to determine the speed itself. The environment variable CPUSPEED takes an integer value, which is the speed of your processor, e.g.: export CPUSPEED=200 The last method used is the autocalibration, which compares the values of gettimeofday() and TSC over an interval of several hundred milliseconds, and is quite accurate AFAIK. You can further override the speed determination by using the statement cpuspeed div mul in your configuration file. The integer ratio (mul/div) allows to specify almost any possible speed (e.g. 133.33... will become '400 3'). You can even slow down dosemu for debugging purposes (only if using TSC, however). The speed value is internally converted into two pairs of integers of the form {multiplier,divider}, to avoid float calculations. The first pair is used for the 1-usec clock, the second one for the tick(838ns) clock. Timer precision I found no info about this issue. It is reasonable to assume that if your CPU is specified to run at 100MHz, it should run at that exact speed (within the tolerances of quartz crystals, which are normally around 10ppm). But I suspect that the exact speed depends on your motherboard. If you are worried, there are many small test programs you can run under plain DOS to get the exact speed. Anyway, this should be not a very important point, since all the file timings are done by calling the library/kernel time routines, and do not depend on the TSC. Additional points The experimental 'time stretching' algorithm is only enabled when using the pentium (with or without TSC). I found that it is a bit 'heavy' for 486 machines and disallowed it. If your dosemu was compiled with pentium features, you can switch back to the 'standard' (gettimeofday()) timing at runtime by adding the statement rdtsc off in your configuration file.