Minix-on-Bochs time problems

modified: 12 Jan 2003

Kees Bot told me he saw problems with the Bochs clock running fast in his experiments with Minix on Bochs, and I can confirm that the problem remains in Bochs 2.0.1, just released in Jan 2003. I downloaded Bochs 2.0.1 from http://twtelecom.dl.sourceforge.net/sourceforge/bochs/Bochs-2.0.1.exe on 2003-01-10 and have tested with the Minix 2.0.3 image posted on the Bochs site at http://prdownloads.sourceforge.net/bochs/minix203.tar.gz?download.

Under my test conditions (Bochs 2.0.1 on W2K, AMD K6-450 CPU) there seems to be about a 30x speedup of the Minix clock. If I enter the command sequence

  # date; sleep 300; date
the second date command executes about 10 seconds after the first, showing a time 5 minutes later than the first.

Running the dhrystone benchmark on Bochs does not provide meaningful results. Bochs emulates the real time clock hardware by referring to the ips (instructions-per-second) parameter in the bochsrc configuration file. Bochs generates simulated clock interrupts based on how many emulated instructions are executed. Since dhrystone counts instruction loops executed during a fixed time it is useless if the "fixed" time is also generated by counting instructions.

Bochs gets its starting time from the system real time clock (RTC), but then doesn't refer to the RTC again. If the Minix clock runs excessively fast any files modified on the emulated Minix system will be dated in the future. With a 30x speedup, if I work on a Minix programming project for an hour and do a compilation, then come back a day later and make further source code changes, the make command can easily become very confused and use older files instead of the most recently edited ones.

In the bochsrc provided with the Minix 2.0.3 image I used, ips is set at 1,000,000. Increasing ips makes things better, but Bochs time still flies ahead with an ips value of 10,000,000. Increasing it another 10x to 100,000,000 makes the response of Minix very sluggish.

There is a response to this issue on the Bochs site, in the response to feature request #5362329 (http://sourceforge.net/tracker/index.php?func=detail&aid=536329&group_id=12580&atid=362580). The Bochs source now includes support for three different ways to determine real time:

There is a reason why the instruction-counting method is the default -- an important use for emulator is debugging, and with this method runs are reproducible. This method also gives the best performance. As noted in the feature request response:

"What it comes down to is this:
Reproducibility, host-time correlation, performance: choose two."

Unfortunately, at present the options to change the way Bochs determines time are compile-time options, and, at least for the Windows platform, the available pre-compiled binary provides the instruction-counting method. Since Minix is first and foremost designed to be a tool for learning how an OS works, I would expect the major interest in Minix-on-Bochs would come from Windows users, most of whom do not have the ability to compile their own Bochs.

If someone reading this could compile a Bochs executable for Windows with a better timing method, this would be a useful contribution. Even better would be to modify Bochs so the timing method could be configured in the bochsrc file or determined by a command line flag.


Mail comments on this page to: Al Woodhull <awoodhull@hampshire.edu>

[Valid HTML 4.0!]

created by mkhtml: Jan 1 20:10