DECstation 5000/200 timekeeping

I've got a DECstation 5000/200 (the case calls it that, and I'm
inclined to believe it because the boot ROMs call it a KN02).  I've
finally got a relatively stable system on it - it was a bit of a
struggle, because the machine has no network except 10base2, and the
only 10base2 cable I have at ready hand turned out to have an open in
the shield.  (I got network working by taking a 10baseT hub with a
10base2 uplink, putting T connectors on it and the DECstation with a
terminator on each, resting the hub so it's partly supported by the two
T connectors, thereby creating a shield connection, then sticking a
piece of wire into the connectors to connect the centre conductors.
The impedance is all wrong, of course, but it's only 10 Mbit and the
entire "segment" is all of a few inches long, so echos from the
impedance bump die out long before they matter.  (Then, of course, I
connect one of the 10baseT ports of the hub to the relevant part of my
house network.)

So I've got my mutant 5.2 running on it.  Cross-built, at this point; a
native build, which I will probably do at some point, I would expect to
take on the order of a week.

But the reason I'm writing now is timekeeping.  With the machine
sitting idle, doing nothing, it keeps decent time: ntp syncs and
ntp.drift says -0.926.

But as soon as I type into the ssh session to it, look at a few files,
ls a few directories, timekeeping drifts severely - I have another
machine querying its ntpd every 64 seconds and I saw it drift by over
11 seconds between two successive queries.  I stopped typing into the
ssh and it stabilized again.  I then started some computation
(comparing files on the 5000/200 with what should be identical files
elsewhere) and it started drifting again - not as severely, but still
pretty bad (multiple seconds per minute)  And this is running ntpd with
-N, (manually) reniced to -20 as well.

This really looks to me as though the clock interrupt is low enough
priority to get locked out by SCSI, serial, and/or Ethernet interrupts;
it reminds me of running NetBSD/mac68k, years ago.  Is that accurate?
If so, is that an attribute of the hardware, or is it something that
can be fixed in software?  I'm wondering if it can be fixed or if I'll
just have to give up on decent timekeeping on this hardware.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		[email protected]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B