The 940 hardware provided time service by providing an interrupt 60 times per second, as defined by the power supply. The principle effect of the interrupt was to increment a 24 bit binary counter called T. There was a system call to read T.
I wrote a very small user observer program to read T as quickly as possible until it changed, at which point I would record how much it had changed and also how many times I had read the unchanged clock. These two numbers were tabulated in two histograms.
The long durations were typically due to the scheduler giving the machine to someone else. The short observed intervals were typically due to IO interrupts serving other users.
I ran the observer on their system along with other programs making known demands on the system. Very quickly we had good information about detailed timing of interrupts to service disk IO, terminal IO, and a few other miscellaneous activities. Of course the histograms had bogus spikes corresponding to combined interrupts but these, being largely uncorrelated, were largely predictable and thus discountable. A small amount of human pattern matching soon produced confidence that we had indeed identified each of the real spikes in the histograms while only using normal user privilege.
A similar attempt on the IBM 370 158 was less successful. There is a hardware clock that ticks faster than instructions and is readable in user mode, but the main signal was from the cache, which was interesting, especially its recursive interaction with the histogram. We did observe what IBM calls “break ins” where the micro-engine, which performs micro-code to provide architected instructions, takes time out to do I/O functions every few microseconds.