7 Mar
2018
7 Mar
'18
12:11 a.m.
From: Dave Horsfall
When did sleep(2) become sleep(3)? Was it V7, or some
BSD?
Before V7. The MIT system (~PWB1) says, on the man page for sleep (II), "As of
this writing the system call is still available although the C routine
implmeneting the function uses 'alarm' and 'pause' (II). It will be
withdrawn
when convenient."
Probably left the system call there for compiled commands, etc which used it?
Noel
7 Mar
7 Mar
2:53 a.m.
New subject: Sleep()y musings
I'm pretty sure it was in TS also, but I'm willing to bet it was PWB1
first. Have to ask someone like Mashey.
FWIW: The issue on time for BSD was somewhat forced by the ARPA community.
The 60th (or 50th) of second (much less 1 second) started to not be fine
enough for many applications. I remember a big argument at a system
seminar circa 82/83 about it. IIRC it was Mike Powell (DEMOS fame) that
was bitching at Joy about it. In the end, BSD4.2 ended up with new time
calls because of that community and started doing things in 100th of second
- which again IIRC was the best the Vax could do.
I've forgotten what the time resolution on the PDP-10s were, but the Crays
and CDC boxes of the day, were much more fine grained than the Vaxen.
Joy was trying to bring Unix closer to what the labs wanted, since they
were paying a lot of the bills.
ᐧ
On Tue, Mar 6, 2018 at 1:11 PM, Noel Chiappa <jnc(a)mercury.lcs.mit.edu>
wrote:
From: Dave
Horsfall
When did sleep(2) become sleep(3)? Was it V7, or
some BSD?
Before V7. The MIT system (~PWB1) says, on the man page for sleep (II),
"As of
this writing the system call is still available although the C routine
implmeneting the function uses 'alarm' and 'pause' (II). It will be
withdrawn
when convenient."
Probably left the system call there for compiled commands, etc which used
it?
Noel
3:39 a.m.
New subject: Sleep()y musings
On 3/6/18, Clem Cole <clemc(a)ccc.com> wrote:
FWIW: The issue on time for BSD was somewhat forced by the ARPA community.
The 60th (or 50th) of second (much less 1 second) started to not be fine
enough for many applications. I remember a big argument at a system
seminar circa 82/83 about it. IIRC it was Mike Powell (DEMOS fame) that
was bitching at Joy about it. In the end, BSD4.2 ended up with new time
calls because of that community and started doing things in 100th of second
- which again IIRC was the best the Vax could do.
Yes--the resolution of the interval timer on the VAX was 10
microseconds (1/100 of a second).
-Paul W.
10:33 p.m.
New subject: Sleep()y musings
On 6 Mar 2018 16:39 -0500, from paul.winalski(a)gmail.com (Paul Winalski):
Yes--the resolution of the interval timer on the VAX
was 10
microseconds (1/100 of a second).
Surely you just mistyped milliseconds?
--
Michael Kjörling • https://michael.kjorling.se • michael(a)kjorling.se
“The most dangerous thought that you can have as a creative person
is to think you know what you’re doing.” (Bret Victor)
8 Mar
8 Mar
12:54 a.m.
New subject: Sleep()y musings
On 3/6/18, Clem Cole <clemc(a)ccc.com> wrote:
In the end, BSD4.2 ended up with new time
calls because of that community and started doing things in 100th of second
- which again IIRC was the best the Vax could do.
When all else fails, RTFM. :-)
According to the VAX Architecture Reference Manual (1987), the
Interval Clock Register, which is used by OSes to keep track of real
time, is a 32-bit unsigned value incremented at 1-microsecond
(0.000001 second) intervals.
VAX also has a Time-of-Year Clock Register (colloquially called the
TOY clock), a 32-bit unsigned value whose LSB represents a resolution
of 10 milliseconds (0.01 second). All VAX models except the
VAX-11/730 provided battery backup for the TOY clock so that it
continued to operate even when the system was powered off. A VAX can
thus be powered off for about 497 days and still remember the
date/time.
I think Clem was remembering the TOY clock. It would be the Interval
Clock Register that was used by BSD to implement sleep() and other
time-related services.
-Paul W.
2263
days inactive
2264
days old
4 comments
4 participants
participants (4)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu -
Michael Kjörling -
Paul Winalski