[TUHS] Sleep()y musings

[TUHS] Sleep()y musings

[Noel Chiappa]

    > 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

[TUHS] Sleep()y musings

[Clem Cole]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1570 bytes --]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20180306/187a6fa6/attachment.html>

[TUHS] Sleep()y musings

[Paul Winalski]

On 3/6/18, Clem Cole <clemc at 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.

[TUHS] Sleep()y musings

[Michael Kjörling]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]

On 6 Mar 2018 16:39 -0500, from paul.winalski at 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 at 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)

[TUHS] Sleep()y musings

[Paul Winalski]

On 3/6/18, Clem Cole <clemc at 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.

[TUHS] Sleep()y musings

[Rudi Blom]

>Date: Wed, 7 Mar 2018 13:54:32 -0500
>From: Paul Winalski <paul.winalski at gmail.com>
>To: Clem Cole <clemc at ccc.com>
>Cc: The Eunuchs Hysterical Society <tuhs at tuhs.org>
>Subject: Re: [TUHS] Sleep()y musings
>Message-ID:
>        <CABH=_VTO7sdgGypp3U7zQoWdJ3HsGUUjrk->6_Rf5VE5gyNGD7g at mail.gmail.com>
>Content-Type: text/plain; charset="UTF-8"
>
>...
>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.

Also in AlphaServers we still have this TOY, the clock and the battery that is.
From a DS10 running Digital Unix 4.0G, /var/adm/messages file, I only
removed the BEL characters

Dec 12 03:01:27 br0011 vmunix: You must reset the system time manually
Dec 12 03:01:27 br0011 vmunix: Time of year (TOY) clock returned zero
as the current time
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: WARNING: preposterous time in TOY clock
-- CHECK AND RESET THE DATE!!
Dec 12 03:01:27 br0011 vmunix:
Dec 12 03:01:27 br0011 vmunix: i2c: Server Management Hardware Present
Dec 12 03:01:27 br0011 vmunix: datalink: links=128, macs=6
Dec 12 03:01:27 br0011 vmunix: NOTE: dxb_configure: Configure values:
dxb, ffffffffffffff9d, ffffffff90bfbf80, ffffffff90bf9a20
Dec 12 03:01:27 br0011 vmunix: WARNING: dxb_configure:
configure_driver error = 22
Dec 12 03:01:28 br0011 vmunix: Node ID is 00-10-64-30-ae-38 (from device tu0)
Dec 12 03:01:28 br0011 vmunix: WARNING: Time of year (TOY) clock
battery is dead, time and NVR contents ignored
Dec 12 03:01:28 br0011 vmunix:
Dec 12 03:01:28 br0011 vmunix: You must reset the system time manually

Cheers,
uncle rubl

[TUHS] Sleep()y musings

[Dave Horsfall]

Back when the dinosaurs were using card readers (and yes, I've used a card 
reader on Unix; I think it was a desktop CDC model, and the driver would 
handle two modes: strict 80-column i.e. one 12-bit column per 16-bit word 
and you got 80 of 'em on a DMA channel, or ASCII NL-terminated after last 
non-blank column, and no, I have no idea whether it handled EBCDIC or CDC 
etc, but I digress as usual).

Where was I?  Oh yes, sleeps...

Back when sleep(3) was sleep(2) (yes, Virginia, sleep() used to be a 
system call, then it became alarm()/pause(), and now it seems to be 
nanosleep(), and I'm wandering again), you never called sleep(1) because 
its granularity was +/-1 second (and all the way up to +infinity, 
actually, on a really busy machine), thus it could return right away, with 
ensuing hilarity.

So, I'm curious:

When did sleep(2) become sleep(3)?  Was it V7, or some BSD?  Or Babbage 
help me, SysVile?

When did the caveat about sleeping for 1 second become known?  I don't 
think that I ever saw it documented, but was one of those "lore" things 
passed around at Unix conferences and the like.

And when did it start using nanosleep() instead of alarm()/pause()?  I see 
that my Penguin box has a bet both ways; it "may" use SIGALRM[a] (thus 
"mixing calls to alarm(2) and sleep() is a bad idea" (well, I've used 
both), and also refers to nanosleep().

[a]
Alpine's spell-checker suggested "SICKROOM" here; pretty close when 
dealing with timed-out reads on a TTY connection[ii] :-)

[ii]
Have you tried this with Perl?  You can't rely on EINTR[3], so you have to 
use eval{} blocks instead, and it starts getting pretty fugly...

[3]
And here it suggested "ENTREE".

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."

[TUHS] Sleep()y musings

[Dave Horsfall]

OK, I've generated some discussion (both public and private) so after the 
dust settles I'll summarise the responses.

-- 
Dave Horsfall DTM (VK2KFU)  "Those who don't understand security will suffer."