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:
- In BIOS mode, the dosemu session begins with the current (local)
date & time, and once running it behaves fully like an emulated PC.
You can set the date & time using the normal DOS methods as you
would expect. However, time keeping accuracy in the long term under DOS
was never very good, and under dosemu it is typically poorer.
- In LINUX mode, the emulated PC always reports the current host
time, and so you no longer have the option to set the DOS time (the
date can be set, which is odd, as this is kept in DOS and not in the
emulator). In this mode you get the long term accuracy of the host, so
if you are running NTP or similar, you always get accurate time.
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