VAX clock drift about simh HOT 25 CLOSED

I'll look into this, but more details are necessary. There are many factors which influence the consistency of the clock ticks and thus the drift which may be observed. Which way are you seeing drift (guest clock is slow or fast)? How much drift over how big a period of time? What is your config, are you running with IDLE enabled? Is the host system doing anything else? Is the guest system busy or mostly idle?

Meanwhile, I had made changes more than a year ago about how the VAX TODR works. I added support for generic OS values of the TODR instead of the VMS specific values which Bob had originally implemented. This difference of behavior is linked to whether you ATTACH the clock to a clock battery state file. If you don't attach it, then the values presented behave as they originally did with SIMH, while if you attach the clock device, then things reflect the behavior of real hardware. In any case, while adding this, I also changed what the TODR represents. Originally it merely represented the number of clock ticks/interrupts which had been generated with the VMS standard time of year offset. Now it represents the actual Time of Year without regard to the clock ticks/interrupts which have been issued. This means that the TODR tracks wall clock time not simulator time.
Given this new behavior, clock drift can be managed on any VAX system (except the MicroVAX I which doesn't have a TODR) merely by periodically setting the system time from the TODR. I have a DCL command procedure (below called SYS$STARTUP:TODR_SYNCH.COM), which is invoked in the SYSTARTUP_VMS.COM with the following line:

$ @sys$STARTUP:TODR_SYNCH BACKGROUND

$! TODR_SYNCH.COM
$!
$! This procedure starts a detached process to set the Operating System's
$! time from the Battery Backedup Clock once every minute.
$!
$! The Operating system time is advanced by counting clock ticks which
$! should occur every 10ms. The precision of the clock ticks isn't nearly
$! as high as the time available from the external clock.
$!
$! Input Arguments:
$! P1 - Any non null value causes a detached process to be run which
$! is running this procedure.
$!
$! If this procedure is invoked without any arguments, it will
$! loop forever synching the clock once every minute.
$!
$ OldPrivs = F$SetPriv("ALL")
$ If P1.eqs."" Then GoTo Synch
$ Run Sys$System:LoginOut.exe -
/Detach -
/Process_Name="TODR Synch" -
/Output=NLA0: -
/Error=NLA0: -
/Input='F$Environment("PROCEDURE")
$ OldPrivs = F$SetPriv(OldPrivs)
$ Exit
$Synch: Set Time
$ Wait 00:01:00
$ GoTo Synch

This will mitigate any drift (or do nothing) on any VMS system running on any version of simh.

from simh.

El 09/03/2013, a les 18:38, Mark Pizzolato [email protected] va escriure:

I'll look into this, but more details are necessary. There are many factors which influence the consistency of the clock ticks and thus the drift which may be observed. Which way are you seeing drift (guest clock is slow or fast)? How much drift over how big a period of time? What is your config, are you running with IDLE enabled? Is the host system doing anything else? Is the guest system busy or mostly idle?

• The clock runs slower than real time.
• I run with IDLE=VMS
• This is one of the related configs (the VAX730 one):

set cpu conhalt
set cpu idle=vms
set cpu 4M
;set console telnet=buffered=65536
;set console telnet=33023
set console log=console.log

set rp disable
set rl disable
set rb disable
set hk disable
set ry disable
set cr disable
set td disable

set rq enable
set rq0 ra80
att rq0 RA80.000
set rq1 disable
set rq2 disable
set rq3 CDROM

set tq1 disable
set tq2 disable
set tq3 disable

set xu enable
set xu mac=08:00:2b:07:00:75
attach xu vde:/tmp/vde.ctl

set dz disable

set vh enable
set vh lines=4
set vh0 modem
set vh0 hangup
set vh1 disable
set vh2 disable
set vh3 disable
attach vh 32123

att lpt ./vms-printer.txt

echo Booting VMS 5.5 from RQ0 (DUA0)
boot rq
:

Meanwhile, I had made changes more than a year ago about how the VAX TODR works. I added support for generic OS values of the TODR instead of the VMS specific values which Bob had originally implemented. This difference of behavior is linked to whether you ATTACH the clock to a clock battery state file.

I didn't even know you could/should attach the clock :) On the other hand I just noticed the HELP text for TODR is wrong:

        ... This mode is enabled by attaching the CLK to a battery backup state file for the TOY clock (i.e. sim> attach CLK TOY_CLOCK). (...)

I guess that 'CLK' should be 'TODR'.

If you don't attach it, then the values presented behave as they originally did with SIMH, while if you attach the clock device, then things reflect the behavior of real hardware. In any case, while adding this, I also changed what the TODR represents. Originally it merely represented the number of clock ticks/interrupts which had been generated with the VMS standard time of year offset. Now it represents the actual Time of Year without regard to the clock ticks/interrupts which have been issued. This means that the TODR tracks wall clock time not simulator time.

Given this new behavior, clock drift can be managed on any VAX system (except the MicroVAX I which doesn't have a TODR) merely by periodically setting the system time from the TODR. I have a DCL command procedure (below called SYS$STARTUP:TODR_SYNCH.COM), which is invoked in the SYSTARTUP_VMS.COM with the following line:

I have copied and started the code. But in my opinion this just hides the problem. Oh, by the way, the PDP11 runs fine.

from simh.

• The clock runs slower than real time.
• I run with IDLE=VMS

How much slower does it run per hour?

Do you have similar behavior if you do not run with idle detection?

I didn't even know you could/should attach the clock :) On the other hand I just noticed the HELP text for TODR is wrong:

      ... This mode is enabled by attaching the CLK to a battery backup state file for the TOY clock (i.e. sim> attach CLK TOY_CLOCK). (...)

I guess that 'CLK' should be 'TODR'.

You are correct. This is due to there being separate device implementations for the system internal devices for each simulator and different simulators have different device names. I copied the clock help around without noticing this detail. I'll fix.

Given this new behavior, clock drift can be managed on any VAX system (except the MicroVAX I which doesn't have a TODR) merely by periodically setting the system time from the TODR. I have a DCL command procedure (below called SYS$STARTUP:TODR_SYNCH.COM), which is invoked in the SYSTARTUP_VMS.COM with the following line:

I have copied and started the code. But in my opinion this just hides the problem.

It does hide the problem, but even real hardware had clock drift, so some external means of clock synchronization was always necesary. This allows a guest system which doesn't have a network stack and therefore can't run NTP to get time which is as good as the host system's view of time.

Oh, by the way, the PDP11 runs fine.

I'm not familiar with the IDLING details on the PDP11. I suspect that some of what you are seeing is IDLING related. Are you running with IDLE detection on the PDP11?

from simh.

El 09/03/2013, a les 19:29, Mark Pizzolato [email protected] va escriure:

How much slower does it run per hour?

Do you have similar behavior if you do not run with idle detection?

I'll do some experiments and will report the results. It will take some hours, though.

from simh.

OK, here are the results.

• VAX8600, with IDLE=VMS: In 23 hours and 30 minutes (1410 minutes) the clock has lost 25 minutes.
• 11/780, with NO IDLING, it has lost LESS THAN A MINUTE (if anything at all).
• uVAX 3900, with IDLE=VMS, it has lost LESS THAN A MINUTE (if anything at all).

So it seems the problem is limited to "full vaxen" with idle enabled. I could set up a microvax 2 and check if it also drifts, if necessary. Right now I'm running your fix on all my systems (excepting the 3900), with an update interval of 10 minutes.

from simh.

All of these VMS systems you ran on separate host machines, and all of them were not really doing anythnig (i.e. the systems were truly idle)? The host systems were basically idle as well, right?

The VAX8600 lost 25/1410 or about 1.7%. Given how the current calibration mechanisms work and how idling works I think this is within expected behavior.

Meanwhile, I've thought about the problem. I'll elaborate later.

from simh.

Since this issue is idle dependent, some idle control details are relevant. Specifically what is the output of:

sim > EXAMINE TIMER OS_SLEEP_MIN_MS

On each of the host systems and simulators you tested?

Thanks

from simh.

For reference, this one is the uVAX 3900 (which works OK):

sim> examine timer os_sleep_min_ms
OS_SLEEP_MIN_MS: 2

This one is the 8600, running in a macbook on Linux x64 (actually, the same host as the 3900 above):

sim> examine timer os_sleep_min_ms
OS_SLEEP_MIN_MS: 2

Now the 780 and 730, running in the raspberry Pi:

780:

sim> examine timer os_sleep_min_ms
OS_SLEEP_MIN_MS: 2

730:

sim> examine timer os_sleep_min_ms
OS_SLEEP_MIN_MS: 2

The value is the same in all the machines.

from simh.

Hi Jordi,

There has been some latent code in the current code base which wasn't yet enabled. This code is enabled when compiling with SIM_ASYNCH_CLOCKS.

When built with SIM_ASYNCH_CLOCKS defined, the simulator will process clock ticks in an asynchronous thread and deliver those ticks to the instruction execution thread when the proper clock tick interval of time has actually occurred. This should be idle independent. You should not need to use the TODR_SYNCH.COM procedure, although it won't hurt and TODR_SYNCH.COM will properly set/reset the time if a simulator happens to be run after a SAVE/RESTORE set of operations. In any case you may want to not use the TODR_SYNCH.COM while testing the asynch clock tick mechanisms so you can get useful clock drift measurements.

To build a simulator from the current code base with this feature enabled you can merely:

$  make vax CFLAGS_G=-DSIM_ASYNCH_CLOCKS

Be sure to pull the latest code since I just fixed a couple of things in this area.

This functionality hasn't been extensively tested, so I haven't made it the default for any simulator builds yet.

from simh.

El 07/05/2013, a les 20:24, Mark Pizzolato [email protected] va escriure:

When built with SIM_ASYNCH_CLOCKS defined, the simulator will process clock ticks in an asynchronous thread and deliver those ticks to the instruction execution thread when the proper clock tick interval of time has actually occurred. This should be idle independent. You should not need to use the TODR_SYNCH.COM procedure, although it won't hurt and TODR_SYNCH.COM will properly set/reset the time if a simulator happens to be run after a SAVE/RESTORE set of operations. In any case you may want to not use the TODR_SYNCH.COM while testing the asynch clock tick mechanisms so you can get useful clock drift measurements.

Nice one! I have just (re)built my test environment to exercise the asynch DECNET issues, so I will be able to do some testing without disturbing my... ehrrmmm... "production" instances.

By the way, last week I wrote a substitute for the TODR_SYNCH.COM as an executable program... in BLISS-32. Why BLISS? Just because I wanted to try to do something useful in that language (no, I didn't use it profesionally when I was working with VAXen :)). It just became redundant :).

I'll compile simh with -DSIM_ASYNCH_CLOCKS and I'll tell you how it works (after some hours, of course).

from simh.

El 07/05/2013, a les 20:24, Mark Pizzolato [email protected] va escriure:

Hi Jordi,

There has been some latent code in the current code base which wasn't yet enabled. This code is enabled when compiling with SIM_ASYNCH_CLOCKS.

I have tested that, and it seems to work ok. The clock drift is minimal without the periodical $SET TIME. Nice work!

I have checked it in the 780 and 3900 simulators; on the other hand, the 3900 used to work OK before this. Tell me if you want me to do any other tests related to this issue (I'll send you another mail about the DZ stuff to not mix-up the different things9.

from simh.

If you recall, I think we observed the real drift issues when you were running with SET CPU IDLE=VMS. Did you test this case?

Keeping good time will be hard no matter what we do if the host system is very busy. I believe that the SIM_ASYNCH_CLOCKS will still do a much better job here as well.

I'm not quite ready to make this a default behavior yet, but at least you can see it is an option which has been pretty well fleshed out.

from simh.

Yes, I tested with idle enabled. That is on the other hand my "default" simh configuration.

from simh.

Oh, as a crazy idea perhaps simh could embed a ntp client so it can correct itself...

from simh.

We count on the host system to be doing the NTP thing. Given that, then the $SET TIME procedure will leverage the host's well synchronized time.

from simh.

El 12/05/2013, a les 21:16, Mark Pizzolato [email protected] va escriure:

We count on the host system to be doing the NTP thing. Given that, then the $SET TIME procedure will leverage the host's well synchronized time.

If the guest OS is openVMS... I'm not sure the BSDs, Ultrix or the other (?) VAX OSs can do that.

from simh.

Other guest OSes all query the TODR at startup (like VMS does). They may or may not have a means to dynamically reset the clock using the TODR. If they don' t have this ability, then they'd have to run NTP.

The SIM_ASYNCH_CLOCKS capabilities will 'help' all guest OS situations. It can't avoid clock drift in every case and it can't fix things across a SAVE/RESTORE, so either a "$ SET TIME" mechanism or a guest NTP client is recommended.

from simh.

Fixed, see previous entries.

from simh.

This compile option appears to work perfectly for Ultrix 4.5 on the vax/microvax3900. The severe clock drift (while idle) that I was having seems to have stopped completely.

There was, however, a rather worrying warning during the compile...

sim_timer.c:898:3: warning: initialization from incompatible pointer type
   { MTAB_VDV,          MTAB_VDV, "ASYNC", "ASYNC",   &sim_timer_set_async, &sim_timer_show_async, NULL, "Enables/Displays Asynchronous Timer operation mode" },
   ^
sim_timer.c:898:3: warning: (near initialization for ‘sim_timer_mod[0].valid’)
sim_timer.c:898:3: warning: initialization from incompatible pointer type
sim_timer.c:898:3: warning: (near initialization for ‘sim_timer_mod[0].disp’)
sim_timer.c:899:3: warning: initialization from incompatible pointer type
   { MTAB_VDV,                 0,    NULL, "NOASYNC", &sim_timer_clr_async, NULL,                  NULL, "Disables Asynchronous Timer operation" },
   ^
sim_timer.c:899:3: warning: (near initialization for ‘sim_timer_mod[1].valid’)

I don't think I want to try to change the config option 😄

On a related note, the difference between the way that VMS and Ultrix treat the "TOY" clock seems to be that VMS stores local time in it and Ultrix stores UTC.

from simh.

@rdebath Please put your full name on your GitHub profile (no public email necessary).

Can you provide:

1. Details about the host platform you're seeing these compile warnings on?
2. Can you provide the FULL OUTPUT produced when you 'make vax'.

from simh.

Okay, full make vax is this

S2p4(robert)simh$ make vax CFLAGS_G=-DSIM_ASYNCH_CLOCKS
lib paths are: /lib/ /lib/i386-linux-gnu/ /lib/i386-linux-gnu/i686/cmov/ /lib/x86_64-linux-gnu/ /lib64/ /libx32/ /usr/X11R6/lib/ /usr/i486-linuxaout/lib/ /usr/lib/ /usr/lib/i386-linux-gnu/ /usr/lib/i386-linux-gnu/fakechroot/ /usr/lib/i386-linux-gnu/i586/ /usr/lib/i386-linux-gnu/i686/cmov/ /usr/lib/i386-linux-gnu/i686/sse2/ /usr/lib/i386-linux-gnu/libfakeroot/ /usr/lib/i386-linux-gnu/sse2/ /usr/lib/i486/ /usr/lib/i586/ /usr/lib/i686/cmov/ /usr/lib/i686/sse2/ /usr/lib/x86_64-linux-gnu/ /usr/lib64/ /usr/libx32/ /usr/local/lib/
include paths are: /usr/include
using libm: /usr/lib/i386-linux-gnu/libm.so
using librt: /usr/lib/i386-linux-gnu/librt.so
using libpthread: /usr/lib/i386-linux-gnu/libpthread.so /usr/include/pthread.h
using libpcreposix: /usr/lib/i386-linux-gnu/libpcreposix.so /usr/include/pcreposix.h
using libdl: /usr/lib/i386-linux-gnu/libdl.so /usr/include/dlfcn.h
using libpng: /usr/lib/i386-linux-gnu/libpng.so /usr/include/png.h
using mman: /usr/include/sys/mman.h
using libSDL: /usr/include/SDL/SDL.h
using libpcap: /usr/include/pcap.h
using libvdeplug: /usr/lib/libvdeplug.so /usr/include/libvdeplug.h
***
*** vax Simulator being built with:
*** - compiler optimizations and no debugging support. GCC Version: 4.9.2.
*** - dynamic networking support using Linux provided libpcap components.
*** - Local LAN packet transports: PCAP VDE TAP NAT(SLiRP)
*** - video capabilities provided by libSDL (Simple Directmedia Layer).
***
*** git commit id is 3d7c4dc510b75e43fa6a4c8a169c90333e5e4d46.
***
mkdir -p BIN
gcc -std=gnu99 -U__STRICT_ANSI__ -DSIM_ASYNCH_CLOCKS -O2 -finline-functions -fgcse-after-reload -fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow -Wno-unused-result -DSIM_GIT_COMMIT_ID=3d7c4dc510b75e43fa6a4c8a169c90333e5e4d46 -DSIM_COMPILER="GCC Version: 4.9.2" -I . -D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO  -DHAVE_PCREPOSIX_H -DHAVE_DLOPEN=so -DHAVE_LIBPNG -DHAVE_GLOB -DHAVE_SHM_OPEN  sim_BuildROMs.c -o BIN/BuildROMs
BIN/BuildROMs
rm -f BIN/BuildROMs
mkdir -p BIN
gcc -std=gnu99 -U__STRICT_ANSI__ -DSIM_ASYNCH_CLOCKS -O2 -finline-functions -fgcse-after-reload -fpredictive-commoning -fipa-cp-clone -fno-unsafe-loop-optimizations -fno-strict-overflow -Wno-unused-result -DSIM_GIT_COMMIT_ID=3d7c4dc510b75e43fa6a4c8a169c90333e5e4d46 -DSIM_COMPILER="GCC Version: 4.9.2" -I . -D_GNU_SOURCE -DUSE_READER_THREAD -DSIM_ASYNCH_IO  -DHAVE_PCREPOSIX_H -DHAVE_DLOPEN=so -DHAVE_LIBPNG -DHAVE_GLOB -DHAVE_SHM_OPEN  VAX/vax_cpu.c VAX/vax_cpu1.c VAX/vax_fpa.c VAX/vax_io.c VAX/vax_cis.c VAX/vax_octa.c  VAX/vax_cmode.c VAX/vax_mmu.c VAX/vax_stddev.c VAX/vax_sysdev.c VAX/vax_sys.c  VAX/vax_syscm.c VAX/vax_syslist.c VAX/vax_vc.c VAX/vax_lk.c VAX/vax_vs.c VAX/vax_2681.c PDP11/pdp11_rl.c PDP11/pdp11_rq.c PDP11/pdp11_ts.c PDP11/pdp11_dz.c PDP11/pdp11_lp.c PDP11/pdp11_tq.c PDP11/pdp11_xq.c PDP11/pdp11_vh.c PDP11/pdp11_cr.c PDP11/pdp11_td.c PDP11/pdp11_io_lib.c scp.c sim_console.c sim_fio.c sim_timer.c sim_sock.c sim_tmxr.c sim_ether.c sim_tape.c sim_disk.c sim_serial.c sim_video.c sim_imd.c sim_card.c -DVM_VAX -DUSE_INT64 -DUSE_ADDR64 -DUSE_SIM_VIDEO -I VAX -I PDP11 -DHAVE_PCAP_NETWORK -I/usr/include/ -DBPF_CONST_STRING -DUSE_SHARED -DHAVE_VDE_NETWORK -DHAVE_TAP_NETWORK -Islirp -Islirp_glue -Islirp_glue/qemu -DHAVE_SLIRP_NETWORK -DUSE_SIMH_SLIRP_DEBUG slirp/*.c slirp_glue/*.c -DHAVE_LIBSDL -DUSE_SIM_VIDEO `/usr/bin/sdl-config --cflags` `/usr/bin/sdl-config --libs` -o BIN/microvax3900 -lm -lrt -lpthread -lpcreposix -ldl -lpng -lvdeplug -Wl,-R,/usr/lib/ -L/usr/lib/
sim_timer.c:898:3: warning: initialization from incompatible pointer type
   { MTAB_VDV,          MTAB_VDV, "ASYNC", "ASYNC",   &sim_timer_set_async, &sim_timer_show_async, NULL, "Enables/Displays Asynchronous Timer operation mode" },
   ^
sim_timer.c:898:3: warning: (near initialization for ‘sim_timer_mod[0].valid’)
sim_timer.c:898:3: warning: initialization from incompatible pointer type
sim_timer.c:898:3: warning: (near initialization for ‘sim_timer_mod[0].disp’)
sim_timer.c:899:3: warning: initialization from incompatible pointer type
   { MTAB_VDV,                 0,    NULL, "NOASYNC", &sim_timer_clr_async, NULL,                  NULL, "Disables Asynchronous Timer operation" },
   ^
sim_timer.c:899:3: warning: (near initialization for ‘sim_timer_mod[1].valid’)
cp BIN/microvax3900 BIN/vax
S2p4(robert)simh$

This is the System Information generated for the distro package, I've already raised a bug with them complaining that it's version 3.8.

Debian Release: 8.4
  APT prefers stable-updates
  APT policy: (700, 'stable-updates'), (700, 'stable'), (690, 'oldstable'), (50, 'oldstable-updates')
Architecture: i386 (x86_64)
Foreign Architectures: amd64, armhf, powerpc, mips

Kernel: Linux 3.16.0-4-amd64 (SMP w/8 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages simh depends on:
ii  libc6       2.19-18+deb8u4
ii  libpcap0.8  1.6.2-2

from simh.

Thanks. Still no full name though... :-(

In any case, the SIM_ASYNCH_CLOCKS functionality isn't yet enabled by default since it has numerous operational issues. A rework of that project is in progress but is still not ready for daylight. When it is, the default build will include asynch clocks for all simulators that can leverage it (VAX and PDP11 and PDP10 are absolutely candidates).

As for the point/concern you raised about:

On a related note, the difference between the way that VMS and Ultrix treat the "TOY" clock seems to be that VMS stores local time in it and Ultrix stores UTC.

You should try adding the following to your configuration file:

sim> ATTACH CLK TOY_CLOCK_FILE

This won't affect clock drift, but it should address things like UTC or not.

If you still observe inconsistent/unreasonable TOY behavior, please create a separate issue.

Thanks.

• Mark

from simh.

Actually, the full name is in lots of commit messages, but I prefer it to be a bit harder than "on the front page" when web scrapers try to find it.

Re: sim> ATTACH CLK TOY_CLOCK_FILE

Yup found that, it works too, but I don't need to do it, if I do this instead:
$ TZ=UTC simh ultrix-setup-file.ini
The time Ultrix sees is exactly correct.
Would you like me to put that into a "wishlist" issue?

I assume the warnings will be a 'WONTFIX' as the code is being replaced, so I won't make that a new issue.

• Robert

PS: I turned up the resolution of my clock checking ... offset -0.007319 seconds/hour, unless the "operational problems" are make it completely crash-happy that's a win.

from simh.

As for name... OK I guess.

As for:

Yup found that, it works too, but I don't need to do it, if I do this instead:
$ TZ=UTC simh ultrix-setup-file.ini
The time Ultrix sees is exactly correct.
Would you like me to put that into a "wishlist" issue?

The real solution is the ATTACH mechanism which then has the clock behave as the real hardware did and have the TOY register behave as various OS code expects which is to store the programmed value and increment it every 10ms and overflow when it will naturally overflow.

As for:

I assume the warnings will be a 'WONTFIX' as the code is being replaced, so I won't make that a new issue.

Yes, WONTFIX is the right answer, the current latent SIM_ASYNCH_CLOCKS code will be almost completely replaced.

from simh.

increment it every 10ms and overflow when it will naturally overflow.

hmm; overflow ... right, turn it on before the end of April, then it knows it should increment the year.
Reset the clock back to zero and it gets all worried and confused.

Okay, I won't use the timezone then.

Thankyou.
• • • Robert

from simh.