Re: Clock Error

On 2023-12-19 23:54, Ken Wellsch wrote:
>>> It probably is a crazy thought, but I am curious whether you have enabled
>>> a network device and have it active or not.
>>
>> Yes, networking is on, and I'm usually telnetting in to the simulated VAX
>> running NetBSD.
>>
>> You do not have networking on the simulated machine?
> 
> No.  I have tested creating a tun network device and that works, but I
> was not able to find a way to successfully run SIMH as non-root doing so.

I'm just directly hooking into the physical ethernet. No trickery. And I 
have no issues running as root.

> Other than running ntpdate, I really don't need the network.  So, for
> the build I am running, the XQ device is disabled in SIMH.

Since I want to connect to the machine from multiple places, as well as 
transferring files, networking is more than a little useful.

> I have telnet via dz/simh enabled - that is using networking to the host
> machine and talking to SIMH that is then emulating a serial connection
> via a DZ port on the running VAX OS image. :)

I do not like the telnet simulation on serial ports. But it is an 
option, yes.

> I have been doing the build from the console interface rather than a telnet
> session as I wasn't sure whether SIMH is also emulating the DZ port baud
> rate too.  The console does not appear to be doing so anyway.

I think with simh v3, you don't have any of that trickery. It's all in 
v4. And there is equally applies to the console, I seem to remember.

> Also I don't have any packages installed, so no screen to cover my
> behind if I were to loose the telnet session during the long build...

Not using screen either.

/usr/src/build.sh build >& m.log &

and then I can check the progress from anything, anywhere. And it won't 
abort unless there is an error. And I do have the output from whatever 
happened preserved.

Running directly, interactively, seems to me to be something not so 
desireable. If I want to see what happens in real time, I just do a 
"tail -f /usr/src/m.log"

> I mentioned emulating networking as I have a vague recollection that DEC
> really wants your network card as close the the CPU as possible. That
> makes me wonder, to what length is the NetBSD network device driver going
> to avoid missing an interrupt etc if in fact the DEQNA is that "delicate."

That should/could not be an issue. The clock is internal to the CPU. You 
can never get the network closer. But proximity to the CPU also only 
matters when you have several devices at the same interrupt level on the 
Unibus or Qbus. In my case, since my emulation is of a 8650, it's a 
Unibus (so emulating a DELUA). But the clock is still CPU internal, and 
not on any bus at all.

But it's also a case of what interrupt level this has on the CPU. I 
can't remember what the clock interrupt sits at, but it seems very 
unlikely that interrupts would be locked out long enough that interrupts 
were missed, if that is even possible inside simh. I haven't looked at 
the simh code, but I suspect it might actually try to ensure that 
interrupts aren't lost. There is a lost clock interrupt status bit, 
which would get set if an interrupt is generated while another is still 
pending. So the simulator knows if it would in fact loose the interrupt. 
And since simh needs to twiddle clock interrupts anyway, I would expect 
it to be smart around this.

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: [email protected]             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol