In a discussion of timekeeping on emulated VAXen, over on port-vax@, I mentioned that I've found that, on 4.0.1, 5.2, and 9.1, and, based on a report on port-vax@, apparently 9.3 as well, there's a bug in ITIMER_REAL signals (possibly on only some hardware - I've seen it on amd64 and i386, and, if my guess below is correct, it should manifest on various others as well).
Specifically, under a kernel built with HZ=100, requesting signals at 100Hz actually delivers them at 50Hz. This is behind the clock running at half speed on my VAX emulator, and quite likely behind similar behaviour from simh (which emulates VAXen, among other things) on 9.3. I suspect it will happen on any port when requesting signals one timer tick apart (ie, at HZ Hz). In case anyone wants it, I wrote a small test program. It requests 100Hz signals, then, in the signal handler, takes a gettimeofday() timestamp. After taking 6000 timestamps (which ideally should take 60.00 seconds), it then prints out all the timestamps, thus indicating the actual rate signals were delivered at. It's on ftp.rodents-montreal.org (which supports HTTP fetches as well as FTP) in /mouse/misc/test-alrm.c for anyone interested. On machines with the half-speed bug, it takes two minutes rather that one, and the timestamps average about 20ms apart, instead of 10ms. ("About" because in most of my tests there is usually at least one interval that is slightly longer than it should be.) I don't _know_ what's behind it. But today I went looking, and, in 5.2, there is code which looks suspicious. I don't know where the analogous code is in 9.x, but presumably plenty of people here do. Speaking of 5.2, then: in kern/subr_time.c, there is tvtohz(), which has code } else if (sec <= (LONG_MAX / 1000000)) ticks = (((sec * 1000000) + (unsigned long)usec + (tick - 1)) / tick) + 1; which looks suspicious. If sec is zero and usec is tick, that expression will return 2 instead of the 1 I suspect it needs to return. I haven't yet actually tried changing that. Holiday preparations and observations are likely to occupy much of my time for the next week or so, but I'll try to fit in the time to change that and see if it helps any. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B