Time Keeping in dosemu


Basic Choices

This is a short guide to the time modes supported in dosemu, you can get a more detailed description of how and why they operate in the advanced timekeeping page.
There are three modes currently supported in the dosemu.conf file:
They are configured by editing (or adding) the $_timemode variable in dosemu.conf to one of the following options:
$_timemode = "bios"
$_timemode = "pit"
$_timemode = "linux"
Most users will only ever have a need for either BIOS or LINUX mode, and the decision comes down to the two basic characteristics:
The PIT mode is an odd compromise, it provides BIOS-like time (settable, decoupled from host time), but with slightly higher accuracy. In summery, if you need accurate time, choose LINUX mode, otherwise if you need time setting capabilities or close 'real' PC emulation, choose BIOS mode.

Using Timezones

A reasonable question for some applications is "how do I get accurate UTC time?", of course, the more general question is about running the emulated DOS session in a different timezone and/or with differing "daylight saving" options to the host computer.
This is quite simple in fact, just start dosemu with the environment variable TZ set to the required zone, and don't forget to have the corresponding command in the DOS autoexec.bat file (otherwise Microsoft products all assume -8 hours PST!). The dosemu emulation of file system access is also based on the local timezone it is running in, so you will get consistent file time stamps compared to the emulated time.
So in the UTC case, you would start dosemu in a shell with TZ=GMT0, and have a line in autoexec.bat with "set TZ=GMT0" before any of your programs are run.

Keeping the Host Time Correct

Having the dosemu time-of-day clock matching the host system's clock (by using the $_timemode = "linux" setting) is only part of the problem, the other is to keep the host time correct.

The best way to do this is to run the NTP daemon, properly configured to get the time from two or more trusted sources (if they are over a long delay network), or from a local GPS clock. You can find information on the NTP home, also look for specific data on reference clocks if you need network independence.

NOTE: To use NTP from a network source, you must allow UDP packets on port 123 (and not just TCP/IP) through any firewalls.

We use the Trimble Acutime2000 (ref clock type 29) as a local clock, but note that it needs a special connection (RTS of host PC to Port A RXD of GPS) to make use of the high accuracy 'event capture' method, and of course the RS232/422 converter and DC power supply to work from the PC's serial port. Trimble do a synchronization kit which we presume has this included.

Then learn to use and understand the ntpq program for querying the status of the daemon, typically you just run "ntpq -p" to print a summary of its status, but it requires some reading to interpret the results properly. A typical response looks like:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*GPS_PALISADE(1) .GPS.            0 l   12   16  377    0.000   -0.003   0.001
+dux             134.36.2.1       3 u   85  256  377    0.610   -0.085   0.170
+ntp1.ja.net     .GPS.            1 u    9   64  377   13.900   -0.098   0.201
 LOCAL(0)        LOCAL(0)        10 l   38   64  377    0.000    0.000   0.001

Very briefly, the '*' in the first column indicates the source used for synchronization, in this case the local GPS. The '+' or '#' indicates a candidate that is good but currently unused. A space indicates 'unusable' (unreachable, synchronized to this server, or outrageous synchronization distance), while a 'x' or '-' or '.' indicates a clock rejected due to its time keeping being suspect.

The 'st' column indicates the stratum level of the source, generally the lower the better with 0=local (assumed perfect) time source. Most NTP sources you would chose use are stratum level 2 or 3 and note that you should be a good NTP citizen and check the terms of use for any NTP server(s) you are intending on using. In most cases, the use of NTP pool servers is the best approach. If you really worry about not being connected to stratum 1 servers, then buy a GPS!

A final word of warning, if you shift the host time forwards or backwards by a large amount (several seconds can do it) you will find that it can hang dosemu. Sometime it restarts once time catches up with the past value, but it is a bad thing all round. Setting the configuration option to use the CPU cycle counter can help:

$_rdtsc = "on"

However, with changes in 1.3.x of dosemu to avoid the effects of varying the CPU clock (a power saving feature on some systems, e.g. laptops) this no longer guarantees monotonic time within dosemu. This is why the NTP daemon is a good solution, as after initial setting, it trys to vary the system's clock speed to adjust the time, and avoids applying a step adjustment.


PSC Home Page

(c) Paul Crawford, 2nd March 2012