axpbox loses time

[athornton]

I started axpbox at 11:37 AM; by 2:10 PM the clock had lost 11-1/2 minutes (these commands were run within a second of each other):

Host:

adam@t410:~$ ps ugax | grep axp | grep -v grep; date
root      9682  101  1.5 1321572 122020 pts/3  Sl+  11:37 155:11 ./axpbox run -f es40.cfg
Mon Mar 15 14:10:50 MST 2021

Guest (OpenVMS 8.4-2L1):

$ show time
  15-MAR-2021 13:59:18

It's a slow host machine but not that slow (snappier than a Pi, anyway): model name : Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz w/8GB RAM (the emulated Alpha is only a 1024MB machine).

[athornton]

Running commit 7d6ad44f2abc283e1740fc8705ff1fba9a86846b

[RaymiiOrg]

There have been some time-related code changes recently. Does this behavior also occur if you run the latest release (downloaded from GitHub) or, an earlier commit like https://github.com/lenticularis39/axpbox/commit/30480ef992ff71b553c05885498110f56b303580 ?

[athornton]

Trying https://github.com/lenticularis39/axpbox/commit/30480ef992ff71b553c05885498110f56b303580 now....

Which eventually gets Unknown opcode: 14.299 and seems to hang. I'll try 1.0.0.

[athornton]

Issue is there in 1.0.0 as well:

adam@t410:~/git/axpbox/build$ ps ugaxwww | grep axp | grep -v grep; date
root     12823  101  1.4 1321560 118492 pts/3  Sl+  14:05  27:56 ./axpbox run -f es40.cfg
Tue Mar 16 14:32:35 MST 2021

$ show time
  16-MAR-2021 21:32:00

Thus, it lost a bit more than a second a minute while booting.

[RaymiiOrg]

Thank you for trying an earlier commit. I haven't seen this on my system yet, but that is quite a powerful recent i7. I'll see if I can reproduce it on an older system.

[mvorl]

@athornton Just a shot in the dark: what is the CPU speed setting in your config file? Looking at the code, this setting governs how many instructions are executed before timer interrupts are delivered. My guess is that If it's set too high, timer interrupts start to lag (and the VMS clock is just a timer interrupt every 10ms). But I could as well be wrong.

[athornton]

  cpu0 = ev68cb
  {
    speed = 800M;
    icache = false;
    skip_memtest_hack = true;
  }

It's on Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz and /proc/cpuinfo reports 4 cores, which I think is 2 2-thread cores. What value should I try instead?

I knocked it down to 500M and have maybe lost a second over several minutes? So that seems to be the answer. I bet if I do it at 266M everything is fine.

[mvorl]

Good to hear it improved the situation. There are other things - also inside VMS - that can have an effect on the clock timer interrupt, e.g. problems on the PCI or IDE bus. 500M is the default speed value. I have mine running at 833M on an Intel Core i7 2.8GHz dual-core MacBook Pro, and did not notice any VMS clock lag.

[Gremlinsz]

Running on a RaspberryPi 4 and have tried values from 500-900 and it loses time no matter what :(