[Simh] DECwindows issues

[Hans Hübner]

Hi,

I am trying to use SIMH to run VAX LISP on VMS in graphical mode, which has
proven to be kind of challenging and I'm now at a point where I wonder if
someone else can help me with some issues (some genuinely SIMH issues, some
more in the VMS/DECwindows area). I'm using FreeBSD 11.2 as host with both
SIMH V3.9-0 and V4.0-0 Current git commit id: 097eb7b6. V4.0-0 is a little
unstable so I'm often reverting to V3.9-0 if I don't need the qvss
framebuffer.

I'm using VMS 5.5H2 with this SIMH configuration:

load -r ka655x.bin
attach nvr nvram.bin
set cpu 64m
set cpu idle
set qvss enable
set rq0 ra92
set rq1 ra92
set rq2 ra92
set rq3 cdrom
attach rq0 sys55.dsk
attach rq1 user.dsk
attach rq2 data.dsk
set rl disable
set xq mac=08-00-2B-AA-BB-CC
attach xq tap:tap0
dep bdr 0
boot cpu

Here are the issues that I have;

If I run DECwindows on the qvss frame buffer backed by Xorg, the mouse
cursor jumps around erratically. I wonder if this is related to the fact
that DECwindows switches the screen resolution of the qvss framebuffer.
When the system initially starts, the black qvss windows only occupies part
of the Xorg screen, but when DECwindows starts, it expands the window to
the full resolution of the X display.

Often enough, I get a "?53 2 0A FF 00 0000" message in the KA655-B monitor
and cannot boot. I recall that this was mentioned recently in this list.
To me, it happens quite often.

During normal system operation with V4.4-0, the simulator sometimes halts
with messages like "Invalid argument, PC: 806EEB6A (MOVL 4(SP),(SP))" or
"Invalid argument, PC: 00083C16 (BEQL 83C35)". If I type "c" at the "sim>"
prompt, the system continues to run. Unfortunately, I could not figure out
how to cause this issue.

Starting simh V4.0-0 takes something like three seconds before the iniitial
"MicroVAX 3900 simulator V4.0-0 Current git commit id: 097eb7b6"
message is printed. V3.9-0 starts much faster (not a big deal, just
wondering).

Running DECwindows on a remote X Server (Xorg or Xquartz) kind of works,
but for some reason, only some of the DEC fonts which I've extracted using
getbdf from the VMS X Server are listed in xlsfonts. In particular, the
menu font that VAX LISP uses is missing.

Overall progress is quite nice, though. Here's a screen shot of DECwindows
and VAX LISP running on Xorg: Loading Image... :)

-Hans

[Mark Pizzolato]

Hi Hans,

Post by Hans Hübner
I am trying to use SIMH to run VAX LISP on VMS in graphical mode,
which has proven to be kind of challenging and I'm now at a point
where I wonder if someone else can help me with some issues
(some genuinely SIMH issues, some more in the VMS/DECwindows
area).  I'm using FreeBSD 11.2 as host with both SIMH V3.9-0 and 
V4.0-0 Current git commit id: 097eb7b6.  V4.0-0 is a little unstable
so I'm often reverting to V3.9-0 if I don't need the qvss framebuffer.
[...]
Here are the issues that I have;
If I run DECwindows on the qvss frame buffer backed by Xorg, the
mouse cursor jumps around erratically. 

This is a known issue on some host platforms. A fix to this is pending
Integration into the master branch. When that is done, this should
work as expected.

Post by Hans Hübner
I wonder if this is related to the fact that DECwindows switches the
screen resolution of the qvss framebuffer.  When the system initially
starts, the black qvss windows only occupies part of the Xorg screen,
but when DECwindows starts, it expands the window to the full
resolution of the X display.

I haven't seen that. The QVSS device simulation specifically simulates
the very basic QVSS framebuffer which is constantly at 1024x864 and
since that is what the original QVSS was capable of interfacing with,
there is no provision for dynamically changing those dimensions.

Post by Hans Hübner
Often enough, I get a "?53 2 0A FF 00 0000" message in the KA655-B
monitor and cannot boot.  I recall that this was mentioned recently
in this list.  To me, it happens quite often.

This is a failure in the boot ROM's diagnostics when it tests some
aspect of the simulated system's timing capabilities. Since it is timing
related attempts to track down the subtle case when this happens are
affected by Heisenberg and don't happen when reasonable information
is being gathered. I hope to get a clear failure I can work from some time.

Meanwhile, when you get that error, you can actually boot the system,
but the ROM won't autoboot. You should still be able to "BOOT DUA0"
when at the ">>>" prompt.

Post by Hans Hübner
During normal system operation with V4.4-0, the simulator sometimes
halts with messages like "Invalid argument, PC: 806EEB6A (MOVL 4(SP),(SP))"
or "Invalid argument, PC: 00083C16 (BEQL 83C35)".  If I type "c" at the
"sim>" prompt, the system continues to run.  Unfortunately, I could not
figure out how to cause this issue. 

I can't yet either. I don't see this with the current code, but the most
recent commits (today) in the github/simh/simh master branch will produce
more contextual error messages that should help tracking down the root cause.
Please pick up the latest code and if you see messages like this again, let me
know directly or create an issue at https://github.com/simh/simh/issues

Post by Hans Hübner
Starting simh V4.0-0 takes something like three seconds before the iniitial
"MicroVAX 3900 simulator V4.0-0 Current        git commit id: 097eb7b6"
message is printed.  V3.9-0 starts much faster (not a big deal, just wondering).

This is by design, and is due to attempts to more precisely measure the timing
parameters of your host system environment. Like you said, not a big deal.

Post by Hans Hübner
Running DECwindows on a remote X Server (Xorg or Xquartz) kind of works,
but for some reason, only some of the DEC fonts which I've extracted using
getbdf from the VMS X Server are listed in xlsfonts.  In particular, the menu
font that VAX LISP uses is missing.

I can't speak to why your local X server might not interpret these fonts, but
there may have been some DEC specific font format details which never made
it back to Xorg. Hopefully you won't need to deal with at all once you can
use the QVSS to as a display with DEC's X server leveraging its local fonts.

- Mark

[Hans Hübner]

Hi Mark,

thanks for your reply!

Post by Hans Hübner
I wonder if this is related to the fact that DECwindows switches the

screen resolution of the qvss framebuffer. When the system initially
starts, the black qvss windows only occupies part of the Xorg screen,
but when DECwindows starts, it expands the window to the full
resolution of the X display.

I haven't seen that. The QVSS device simulation specifically simulates
the very basic QVSS framebuffer which is constantly at 1024x864 and
since that is what the original QVSS was capable of interfacing with,
there is no provision for dynamically changing those dimensions.

This was actually me not looking closely. DECwindows puts the retro black
and white pattern onto the screen which perfectly blends with the -retro
background of Xorg, so the resolution has not changed at all, I just failed
to see that the QVSS window is smaller than the actual screen (and the
jumping mouse kind of concealed that further).

Post by Hans Hübner
During normal system operation with V4.4-0, the simulator sometimes

halts with messages like "Invalid argument, PC: 806EEB6A (MOVL

4(SP),(SP))"

or "Invalid argument, PC: 00083C16 (BEQL 83C35)". If I type "c" at the
"sim>" prompt, the system continues to run. Unfortunately, I could not
figure out how to cause this issue.

I can't yet either. I don't see this with the current code, but the most
recent commits (today) in the github/simh/simh master branch will produce
more contextual error messages that should help tracking down the root cause.
Please pick up the latest code and if you see messages like this again, let me
know directly or create an issue at https://github.com/simh/simh/issues

Will do!

Post by Hans Hübner

Running DECwindows on a remote X Server (Xorg or Xquartz) kind of works,
but for some reason, only some of the DEC fonts which I've extracted

using

getbdf from the VMS X Server are listed in xlsfonts. In particular, the

menu

font that VAX LISP uses is missing.

I can't speak to why your local X server might not interpret these fonts, but
there may have been some DEC specific font format details which never made
it back to Xorg. Hopefully you won't need to deal with at all once you can
use the QVSS to as a display with DEC's X server leveraging its local fonts.

I still hope to somehow get the DEC fonts into Xorg as I really like them
beautiful colors :)

Cheers,
Hans

[Paul Koning]

...

Post by Hans Hübner
During normal system operation with V4.4-0, the simulator sometimes
halts with messages like "Invalid argument, PC: 806EEB6A (MOVL 4(SP),(SP))"
or "Invalid argument, PC: 00083C16 (BEQL 83C35)". If I type "c" at the
"sim>" prompt, the system continues to run. Unfortunately, I could not
figure out how to cause this issue.

I don't know if it applies to VAX, but for many machines the PC is incremented as part of the fetch. So by the time the emulation complains about something being wrong with the instruction, you're pointing at the next one. In other words, to find the offending instruction you have to back up the PC. On a VAX that's tricky because of the variable length instructions. A nice answer is to enable CPU History, even just a few entries; then you can ask for the CPU history display to see how you got to the error.

paul

[Mark Pizzolato]

Post by Hans Hübner

...

Post by Hans Hübner
During normal system operation with V4.4-0, the simulator sometimes
halts with messages like "Invalid argument, PC: 806EEB6A (MOVL

4(SP),(SP))"

Post by Hans Hübner
or "Invalid argument, PC: 00083C16 (BEQL 83C35)". If I type "c" at the
"sim>" prompt, the system continues to run. Unfortunately, I could not
figure out how to cause this issue.

I don't know if it applies to VAX, but for many machines the PC is incremented
as part of the fetch. So by the time the emulation complains about something
being wrong with the instruction, you're pointing at the next one. In other
words, to find the offending instruction you have to back up the PC. On a VAX
that's tricky because of the variable length instructions. A nice answer is to
enable CPU History, even just a few entries; then you can ask for the CPU
history display to see how you got to the error.

Absolutely true. However, the failure here is happening within a device unit
service routine and not from instruction execution. The specific instruction
that might be executing isn't particularly relevant to the problem that is
happening since this is occurring 'between' instructions that are executing.

I found and fixed a problem a few weeks ago that could cause this type of
problem, but some folks either haven't picked up the more recent changes,
or there are more cases that I'm not seeing personally. Given that, today
I added some more contextual information that is displayed when this
type of error is reported, so that the root cause(s) can be located.

- Mark

[Matt Burke]

Post by Hans Hübner
If I run DECwindows on the qvss frame buffer backed by Xorg, the mouse
cursor jumps around erratically.

You may be able to get around this problem by using captured input mode:

sim> set qvss capture

You need to do this before enabling the QVSS. Click in the video window
to capture the mouse cursor and use Ctrl+Right Shift to release it.

Matt

[Hans Hübner]

Post by Matt Burke

Post by Hans Hübner
If I run DECwindows on the qvss frame buffer backed by Xorg, the mouse
cursor jumps around erratically.

sim> set qvss capture
You need to do this before enabling the QVSS. Click in the video window
to capture the mouse cursor and use Ctrl+Right Shift to release it.

This solved the erratic mouse behavior, but now (with V4.0-0 Current
15fd71b9) running VMS 5.5-2 and DECwindows on QVSS, I see either one of the
DECwindows processes (window or session manager) use more than 50% of the
VAX CPU or, if I kill both processes, the emulator taking up 100% of its
host CPU with no VAX process showing up in MONITOR PROC/TOPCPU. The
emulated system is too slow to be used, effectively.

I don't see that behavior when running DECwindows on a remote display, so
it seems to be connected to QVSS. If I can provide any additional
information to diagnose, let me know.

Thanks,
Hans

load -r ka655x.bin
attach nvr nvram.bin
set cpu 64m
set cpu idle
set qvss capture
set qvss enable
set rq0 ra92
set rq1 ra92
set rq2 ra92
set rq3 cdrom
attach rq0 sys55.dsk
attach rq1 user.dsk
attach rq2 data.dsk
set rl disable
set xq mac=08-00-2B-AA-BB-CC
attach xq tap:tap0
dep bdr 0
boot cpu

[Matt Burke]

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU. The emulated system is too
slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5). I just
installed VAX/VMS 5.5-2 and DECwindows (from AG-PSA5B-RE - VMS
REMASTERED V5.5-2 BIN CDROM) using your configuration file but I only
see about 10% of the host CPU being used by Simh when logged into
DECwindows.

The only slight difference is that I'm PCAP for the Ethernet connection
rather than TUN/TAP. Do you have anything else running in the background
(DECnet, UCX, clustering etc.)? I will try to setup the same.

Matt

[Hans Hübner]

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU. The emulated system is too
slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related to
that.

Post by Matt Burke
installed VAX/VMS 5.5-2 and DECwindows (from AG-PSA5B-RE - VMS

REMASTERED V5.5-2 BIN CDROM) using your configuration file but I only

Post by Matt Burke
see about 10% of the host CPU being used by Simh when logged into
DECwindows.

I've used the original VAX/VMS 5.5 distribution and then installed the MUP
and 5.5-2 upgrade packages (all from the same hobbyist distribution CD).

Post by Matt Burke
The only slight difference is that I'm PCAP for the Ethernet connection
rather than TUN/TAP. Do you have anything else running in the background
(DECnet, UCX, clustering etc.)? I will try to setup the same.

I have UCX 4.2 running.

Thanks!
Hans

[Mark Pizzolato]

Hans,

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU.  The emulated system is too
slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related to that.

 
It might be related to the host OS.

Please let it get to the state you're complaining about and then:
^E
sim> SHOW VERSION
sim> CLOCK
sim> SHOW CPU

and send the output produced back here.

- Mark

[Hans Hübner]

Hi Matt,

Post by Hans Hübner

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU. The emulated system is

too

Post by Hans Hübner

Post by Matt Burke

slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related

to that.
It might be related to the host OS.
^E
sim> SHOW VERSION
sim> CLOCK
sim> SHOW CPU
and send the output produced back here.

Here you go:

sim> show version
VAXStation 3900 (KA655) simulator V4.0-0 Current
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Host Platform:
Compiler: GCC 6.4.0
Simulator Compiled as C arch: x64 (Release Build) on Jul 18 2018 at
07:32:15
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: SDL Version 2.0.7
PCRE RegEx (Version 8.42 2018-03-20) support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 20ms
OS: FreeBSD vaxhost 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510:
Fri Jun 22 04:32:14 UTC 2018
***@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC
amd64
git commit id: 15fd71b9
git commit time: 2018-07-17T22:05:05-0700
sim> show clock
Minimum Host Sleep Time: 20 ms (50Hz)
Host Clock Resolution: 1 ms
Execution Rate: 1,358,783,530 cycles/sec
Idling: Enabled
Time before Idling starts: 20 seconds
Calibrated Timer: Internal Timer
Catchup Ticks: Enabled for clocks ticking faster than 50 Hz
Calibration: Always

VAXStation 3900 (KA655) clock device is CLK
Calibrated Timer 0:
Running at: 100 Hz
Tick Size: 10 msecs
Ticks in current second: 82
Seconds Running: 80 (1:20 minutes)
Real Time: 3144059812
Virtual Time: 3144059812
Next Interval: 1,000
Base Tick Delay: 5,000
Initial Insts Per Tick: 5,000
Current Insts Per Tick: 13,587,835
Initializations: 5
Ticks: 6,795
Total Ticks: 8,082
Peak Clock Skew: 825.867 msecs slow
Ticks Acked: 6,795
Tick Time: 1:07.95 minutes
Total Tick Time: 1:20.81 minutes
Catchup Ticks Sched: 6,065
Initialize Base Time: 07:53:37.188
Tick Start Time: 07:53:37.196
Wall Clock Time Now: 07:55:35.790
Catchup Tick Time: 07:54:56.606
Catchup Base Time: 07:53:48.656
Total Time Idled: 2.439 seconds
VAXStation 3900 (KA655) clock device is Internal Calibrated Timer(INT-TIMER)
Calibrated Timer 8:
Running at: 10 Hz
Tick Size: 100 msecs
Ticks in current second: 6
Seconds Running: 23 (23 seconds)
Calibration Opportunities: 23
Instruction Time: 1570864774
Real Time: 3144081177
Virtual Time: 3144082804
Next Interval: 1,500
Base Tick Delay: 90,585,569
Initial Insts Per Tick: 50,000
Current Insts Per Tick: 135,878,353
Initializations: 3
Ticks: 235
Tick Time: 23.5 seconds
Initialize Base Time: 07:53:37.180
Tick Start Time: 07:53:37.180
Wall Clock Time Now: 07:55:35.790
sim> show cpu
CPU idle=VMS, idle enabled, model=MicroVAX 3900 (KA655), NOAUTOBOOT
64MB, HALT to SIMH

Thanks!
Hans

[Mark Pizzolato]

Hi Hans,

Notice: “Time taken by msleep(1): 20ms”

Well, the simulator framework implements idling with sleeps. Meanwhile the simulated VAX has a clock which is architecturally defined to tick at 10ms intervals. If any call to sleep for 1 millisecond actually sleeps for 20 milliseconds, then whenever the system idles the clock is going to get far behind. Older simh versions would simply refuse to idle when the sleep granularity was too large. The current implementation tries to actually allow idling when the host system’s sleep is large and also tries hard to schedule catchup clock ticks so that simulated time tracks pretty closely with wall clock time.

This attempt to run with catchup clock ticks, hasn’t been extensively tested since only a few BSD systems actually have large scheduling clock ticks built into the kernel by default. Therefore, there may be problems. Most other systems (Windows, Linux, and OS X) have host system clock ticks on the order of 1-2ms so these systems don’t have this problem.
You can build a kernel for your BSD system by specifying or changing the value of HZ somewhere in the kernel configuration information, or you could try running on a different host platform.


- Mark
From: Hans HÃŒbner [mailto:***@gmail.com]
Sent: Friday, July 20, 2018 10:57 PM
To: Mark Pizzolato <***@infocomm.com>
Cc: Matt Burke <***@9track.net>; Simh <***@trailing-edge.com>
Subject: Re: [Simh] DECwindows issues

Hi Matt,

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU. The emulated system is too
slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related to that.

It might be related to the host OS.

Please let it get to the state you're complaining about and then:
^E
sim> SHOW VERSION
sim> CLOCK
sim> SHOW CPU

and send the output produced back here.

Here you go:

sim> show version
VAXStation 3900 (KA655) simulator V4.0-0 Current
Simulator Framework Capabilities:
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Host Platform:
Compiler: GCC 6.4.0
Simulator Compiled as C arch: x64 (Release Build) on Jul 18 2018 at 07:32:15
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: SDL Version 2.0.7
PCRE RegEx (Version 8.42 2018-03-20) support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 20ms
OS: FreeBSD vaxhost 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 ***@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC<mailto:***@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC> amd64
git commit id: 15fd71b9
git commit time: 2018-07-17T22:05:05-0700
sim> show clock
Minimum Host Sleep Time: 20 ms (50Hz)
Host Clock Resolution: 1 ms
Execution Rate: 1,358,783,530 cycles/sec
Idling: Enabled
Time before Idling starts: 20 seconds
Calibrated Timer: Internal Timer
Catchup Ticks: Enabled for clocks ticking faster than 50 Hz
Calibration: Always

VAXStation 3900 (KA655) clock device is CLK
Calibrated Timer 0:
Running at: 100 Hz
Tick Size: 10 msecs
Ticks in current second: 82
Seconds Running: 80 (1:20 minutes)
Real Time: 3144059812
Virtual Time: 3144059812
Next Interval: 1,000
Base Tick Delay: 5,000
Initial Insts Per Tick: 5,000
Current Insts Per Tick: 13,587,835
Initializations: 5
Ticks: 6,795
Total Ticks: 8,082
Peak Clock Skew: 825.867 msecs slow
Ticks Acked: 6,795
Tick Time: 1:07.95 minutes
Total Tick Time: 1:20.81 minutes
Catchup Ticks Sched: 6,065
Initialize Base Time: 07:53:37.188
Tick Start Time: 07:53:37.196
Wall Clock Time Now: 07:55:35.790
Catchup Tick Time: 07:54:56.606
Catchup Base Time: 07:53:48.656
Total Time Idled: 2.439 seconds
VAXStation 3900 (KA655) clock device is Internal Calibrated Timer(INT-TIMER)
Calibrated Timer 8:
Running at: 10 Hz
Tick Size: 100 msecs
Ticks in current second: 6
Seconds Running: 23 (23 seconds)
Calibration Opportunities: 23
Instruction Time: 1570864774
Real Time: 3144081177
Virtual Time: 3144082804
Next Interval: 1,500
Base Tick Delay: 90,585,569
Initial Insts Per Tick: 50,000
Current Insts Per Tick: 135,878,353
Initializations: 3
Ticks: 235
Tick Time: 23.5 seconds
Initialize Base Time: 07:53:37.180
Tick Start Time: 07:53:37.180
Wall Clock Time Now: 07:55:35.790
sim> show cpu
CPU idle=VMS, idle enabled, model=MicroVAX 3900 (KA655), NOAUTOBOOT
64MB, HALT to SIMH

Thanks!
Hans

[Hans Hübner]

Thank you for the explanation, Mark.

I've added the line "kern.hz=1000" to the file /boot.loader.conf and
rebooted. Now the system behaves much better and the issue went away.

-Hans

Post by Mark Pizzolato
Hi Hans,
Notice: “Time taken by msleep(1): 20ms”
Well, the simulator framework implements idling with sleeps. Meanwhile
the simulated VAX has a clock which is architecturally defined to tick at
10ms intervals. If any call to sleep for 1 millisecond actually sleeps for
20 milliseconds, then whenever the system idles the clock is going to get
far behind. Older simh versions would simply refuse to idle when the sleep
granularity was too large. The current implementation tries to actually
allow idling when the host system’s sleep is large and also tries hard to
schedule catchup clock ticks so that simulated time tracks pretty closely
with wall clock time.
This attempt to run with catchup clock ticks, hasn’t been extensively
tested since only a few BSD systems actually have large scheduling clock
ticks built into the kernel by default. Therefore, there may be problems.
Most other systems (Windows, Linux, and OS X) have host system clock ticks
on the order of 1-2ms so these systems don’t have this problem.
You can build a kernel for your BSD system by specifying or changing the
value of HZ somewhere in the kernel configuration information, or you could
try running on a different host platform.
- Mark
*Sent:* Friday, July 20, 2018 10:57 PM
*Subject:* Re: [Simh] DECwindows issues
Hi Matt,

Post by Hans Hübner

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU. The emulated system is

too

Post by Hans Hübner

Post by Matt Burke

slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related

to that.
It might be related to the host OS.
^E
sim> SHOW VERSION
sim> CLOCK
sim> SHOW CPU
and send the output produced back here.
sim> show version
VAXStation 3900 (KA655) simulator V4.0-0 Current
64b data
64b addresses
Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
Idle/Throttling support is available
Virtual Hard Disk (VHD) support
Asynchronous I/O support (Lock free asynchronous event queue)
Asynchronous Clock support
FrontPanel API Version 12
Compiler: GCC 6.4.0
Simulator Compiled as C arch: x64 (Release Build) on Jul 18 2018 at 07:32:15
Memory Access: Little Endian
Memory Pointer Size: 64 bits
Large File (>2GB) support
SDL Video support: SDL Version 2.0.7
PCRE RegEx (Version 8.42 2018-03-20) support for EXPECT commands
OS clock resolution: 1ms
Time taken by msleep(1): 20ms
/usr/obj/usr/src/sys/GENERIC amd64
git commit id: 15fd71b9
git commit time: 2018-07-17T22:05:05-0700
sim> show clock
Minimum Host Sleep Time: 20 ms (50Hz)
Host Clock Resolution: 1 ms
Execution Rate: 1,358,783,530 cycles/sec
Idling: Enabled
Time before Idling starts: 20 seconds
Calibrated Timer: Internal Timer
Catchup Ticks: Enabled for clocks ticking faster than 50 Hz
Calibration: Always
VAXStation 3900 (KA655) clock device is CLK
Running at: 100 Hz
Tick Size: 10 msecs
Ticks in current second: 82
Seconds Running: 80 (1:20 minutes)
Real Time: 3144059812
Virtual Time: 3144059812
Next Interval: 1,000
Base Tick Delay: 5,000
Initial Insts Per Tick: 5,000
Current Insts Per Tick: 13,587,835
Initializations: 5
Ticks: 6,795
Total Ticks: 8,082
Peak Clock Skew: 825.867 msecs slow
Ticks Acked: 6,795
Tick Time: 1:07.95 minutes
Total Tick Time: 1:20.81 minutes
Catchup Ticks Sched: 6,065
Initialize Base Time: 07:53:37.188
Tick Start Time: 07:53:37.196
Wall Clock Time Now: 07:55:35.790
Catchup Tick Time: 07:54:56.606
Catchup Base Time: 07:53:48.656
Total Time Idled: 2.439 seconds
VAXStation 3900 (KA655) clock device is Internal Calibrated
Timer(INT-TIMER)
Running at: 10 Hz
Tick Size: 100 msecs
Ticks in current second: 6
Seconds Running: 23 (23 seconds)
Calibration Opportunities: 23
Instruction Time: 1570864774
Real Time: 3144081177
Virtual Time: 3144082804
Next Interval: 1,500
Base Tick Delay: 90,585,569
Initial Insts Per Tick: 50,000
Current Insts Per Tick: 135,878,353
Initializations: 3
Ticks: 235
Tick Time: 23.5 seconds
Initialize Base Time: 07:53:37.180
Tick Start Time: 07:53:37.180
Wall Clock Time Now: 07:55:35.790
sim> show cpu
CPU idle=VMS, idle enabled, model=MicroVAX 3900 (KA655), NOAUTOBOOT
64MB, HALT to SIMH
Thanks!
Hans

[Johnny Billquist]

Post by Mark Pizzolato
Hi Hans,
Notice:      “Time taken by msleep(1): 20ms”
Well, the simulator framework implements idling with sleeps.  Meanwhile
the simulated VAX has a clock which is architecturally defined to tick
at 10ms intervals.  If any call to sleep for 1 millisecond actually
sleeps for 20 milliseconds, then whenever the system idles the clock is
going to get far behind.  Older simh versions would simply refuse to
idle when the sleep granularity was too large.  The current
implementation tries to actually allow idling when the host system’s
sleep is large and also tries hard to schedule catchup clock ticks so
that simulated time tracks pretty closely with wall clock time.
This attempt to run with catchup clock ticks, hasn’t been extensively
tested since only a few BSD systems actually have large scheduling clock
ticks built into the kernel by default.  Therefore, there may be
problems.  Most other systems (Windows, Linux, and OS X) have host
system clock ticks on the order of 1-2ms so these systems don’t have
this problem.

Note that the time resolution is not necessarily the same as the minimum
sleep time. This has to do with how many ticks take place between
context switches, and it is quite common for there to be several ticks
before a context switch takes place.

And as shown by Hans response, the clock resolution is 1ms, but minimum
sleep time (and thus probably context switches) are at 20ms.

Johnny

Post by Mark Pizzolato
You can build a kernel for your BSD system by specifying or changing the
value of HZ somewhere in the kernel configuration information, or you
could try running on a different host platform.
-Mark
*Sent:* Friday, July 20, 2018 10:57 PM
*Subject:* Re: [Simh] DECwindows issues
Hi Matt,

Post by Matt Burke

I see either one of the DECwindows processes (window or session
manager) use more than 50% of the VAX CPU or, if I kill both
processes, the emulator taking up 100% of its host CPU with no VAX
process showing up in MONITOR PROC/TOPCPU.  The emulated system is too
slow to be used, effectively.

I don't seem to be able to reproduce this (on Debian 9.5).

I'm running SIMH on FreeBSD, but I can switch if the problem is related to that.

It might be related to the host OS.
^E
sim> SHOW VERSION
sim> CLOCK
sim> SHOW CPU
and send the output produced back here.
sim> show version
VAXStation 3900 (KA655) simulator V4.0-0 Current
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:TAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
        Compiler: GCC 6.4.0
        Simulator Compiled as C arch: x64 (Release Build) on Jul 18
2018 at 07:32:15
        Memory Access: Little Endian
        Memory Pointer Size: 64 bits
        Large File (>2GB) support
        SDL Video support: SDL Version 2.0.7
        PCRE RegEx (Version 8.42 2018-03-20) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 20ms
        OS: FreeBSD vaxhost 11.2-RELEASE FreeBSD 11.2-RELEASE #0
r335510: Fri Jun 22 04:32:14 UTC 2018
        git commit id: 15fd71b9
        git commit time: 2018-07-17T22:05:05-0700
sim> show clock
Minimum Host Sleep Time:       20 ms (50Hz)
Host Clock Resolution:         1 ms
Execution Rate:                1,358,783,530 cycles/sec
Idling:                        Enabled
Time before Idling starts:     20 seconds
Calibrated Timer:              Internal Timer
Catchup Ticks:                 Enabled for clocks ticking faster than 50 Hz
Calibration:                   Always
VAXStation 3900 (KA655) clock device is CLK
  Running at:                100 Hz
  Tick Size:                 10 msecs
  Ticks in current second:   82
  Seconds Running:           80 (1:20 minutes)
  Real Time:                 3144059812
  Virtual Time:              3144059812
  Next Interval:             1,000
  Base Tick Delay:           5,000
  Initial Insts Per Tick:    5,000
  Current Insts Per Tick:    13,587,835
  Initializations:           5
  Ticks:                     6,795
  Total Ticks:               8,082
  Peak Clock Skew:           825.867 msecs slow
  Ticks Acked:               6,795
  Tick Time:                 1:07.95 minutes
  Total Tick Time:           1:20.81 minutes
  Catchup Ticks Sched:       6,065
  Initialize Base Time:      07:53:37.188
  Tick Start Time:           07:53:37.196
  Wall Clock Time Now:       07:55:35.790
  Catchup Tick Time:         07:54:56.606
  Catchup Base Time:         07:53:48.656
  Total Time Idled:          2.439 seconds
VAXStation 3900 (KA655) clock device is Internal Calibrated Timer(INT-TIMER)
  Running at:                10 Hz
  Tick Size:                 100 msecs
  Ticks in current second:   6
  Seconds Running:           23 (23 seconds)
  Calibration Opportunities: 23
  Instruction Time:          1570864774
  Real Time:                 3144081177
  Virtual Time:              3144082804
  Next Interval:             1,500
  Base Tick Delay:           90,585,569
  Initial Insts Per Tick:    50,000
  Current Insts Per Tick:    135,878,353
  Initializations:           3
  Ticks:                     235
  Tick Time:                 23.5 seconds
  Initialize Base Time:      07:53:37.180
  Tick Start Time:           07:53:37.180
  Wall Clock Time Now:       07:55:35.790
sim> show cpu
CPU  idle=VMS, idle enabled, model=MicroVAX 3900 (KA655), NOAUTOBOOT
          64MB, HALT to SIMH
Thanks!
Hans
_______________________________________________
Simh mailing list
http://mailman.trailing-edge.com/mailman/listinfo/simh