Re: PSA: Clock drift and pkgin

> I gave it a quick try myself (i.e. not properly) and it seemed like
> the VMS clock was running at around half speed.  Maybe that is that
> "50% effect" that was mentioned earlier?

Maybe!  Where does simh get its clock from?  If SIGALRM, it very likely
is that effect.  The bug is that requesting SIGALRM (via setitimer
ITIMER_REAL) at 100 Hz, on a kernel built with HZ=100, actually
delivers signals at 50Hz, not 100Hz.  I conjecture that ITIMER_REAL
can't deliver a SIGARLM every tick, only every other tick at most, but
that's inference from the observed behaviour.  Or, perhaps, it divides
the interval by the tick interval and adds 1, or some such.  I haven't
dug into the reasons for it.  Most of my code uses timer sockets, which
don't have the analogous problem (though as seen on the list recently,
they have other, somewhat related, issues).

I wrote a small test program.  It requests SIGALRMs at 100Hz and, each
time one is delivered, records the time according to gettimeofday().
After 6000 signals have arrived - which ideally should take precisely
60.00 seconds, but one tick more or less wouldn't surprise me - it
dumps out the accumulated list of timestamps.

For anyone interested, the program is on ftp.rodents-montreal.org, in
/mouse/misc/test-alrm.c.

Testing onj four machines, all with hz=100 according to kern.clockrate:

1.4T+mouse/sparc on a basically otherwise idle SPARCstation-20:

$ date; ./test-alrm > test-alrm.out; date
Fri Dec 22 18:05:16 EST 2023
Fri Dec 22 18:06:18 EST 2023
$ sed -n -e 1p -e \$p < test-alrm.out
1703286316.364649
1703286376.356612
$ 

which is about as good as I could ask for.

5.2+mouse/amd64, on a two-core machine with load less than .07:

$ date; ./test-alrm > test-alrm.out; date
Fri Dec 22 17:56:42 EST 2023
Fri Dec 22 17:58:43 EST 2023
$ sed -n -e 1p -e \$p < test-alrm.out
1703285802.610712
1703285923.241680
$ 

and the samples in the file show a steady 50Hz tick.

5.2+mouse/i386, on a 4-core machine, otherwise very lightly loaded:

$ date; ./test-alrm > test-alrm.out; date
Fri Dec 22 18:52:40 EST 2023
Fri Dec 22 18:54:41 EST 2023
$ sed -n -e 1p -e \$p < test-alrm.out
1703289160.860519
1703289281.451973
$ 

Stock 9.1/amd64:

$ date; ./test-alrm > test-alrm.out; date
Fri Dec 22 20:40:46 EST 2023
Fri Dec 22 20:42:46 EST 2023
$ sed -n -e 1p -e \$p < test-alrm.out
1703295646.226685
1703295766.316362
$ 

So, the bug is still present as of 9.1, at least.  And your report
makes it seem likely it is present in 9.3 as well.

/~\ 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