Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site watcgl.UUCP
Path: utzoo!watmath!watcgl!dmmartindale
From: dmmartindale@watcgl.UUCP (Dave Martindale)
Newsgroups: net.unix-wizards,net.bugs.4bsd
Subject: Re: The correct clock fix in 4bsd
Message-ID: <1153@watcgl.UUCP>
Date: Sun, 4-Dec-83 03:41:37 EST
Article-I.D.: watcgl.1153
Posted: Sun Dec  4 03:41:37 1983
Date-Received: Sun, 4-Dec-83 04:50:07 EST
References: <219@raybed2.UUCP>
Organization: U of Waterloo, Ontario
Lines: 15

Ah, nostalgia.  I found that bug when first bringing up 4.1BSD two years
and some ago.  I had written a DUP11 driver, and to avoid getting an
overrun or underrun, interrupt requests had to be handled within 1
millisecond (at 9600 baud).  Even on an otherwise-unused machine, 
these happened consistently.  Looking at the data going by with a
serial analyzer showed that successful transmissions never lasted
more than a second.  So, what happens once a second?  Softclock has
a lot more work to do.  But how can softclock be running with
a priority which locks out interrupts from the device?  Aha! There
it is.  It only took an hour or so to find when the symptom was
"spending too long at high priority" rather than "clock loses time".

Somebody else must have found this very early too;  I think it was mentioned
in a printed list of bug fixes Berkeley sent out, and I know it's been
posted to USENET several times over the years.