Re: [9fans] alarm handling and suspended machines

Re: [9fans] alarm handling and suspended machines

[F.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 761 bytes --]

In any case, I now think that it would be better to prevent alarm(2)
from resuming a suspended machine; otherwise the user would need to be
careful not to start any periodic-alarm program (listen, etc.).

By the way, I have just compiled a kernel that has /dev/resume and
allows a write to set up a wake up timer. My problem now is that the
bitsy is ignoring the RTC alarm I set. I'm trying to see what I did
wrong...


One thing I think we need is to unify the apm interface.  It would be
nice to have a single set of files in /dev supplying the interface to
suspend/resume/battery status.  Right now my stats has to try twice to
display the battery status, since it has to work both with /mnt/apm and
with /dev/battery.

Any plans on this?


[-- Attachment #2: Type: message/rfc822, Size: 1707 bytes --]

From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] alarm handling and suspended machines
Date: Tue, 12 Jun 2001 23:27:34 -0400
Message-ID: <20010613110506.64C19199E3@mail.cse.psu.edu>

we were about to do that on the pc's for a different reason.  The
mechanism should extend to the other architectures.  I've got to
figure out how to restart time when the fast clock stops running.
I can do a quick guess from the rtc and then use ntp to do the
rest but the timesync process will have to know when the
cycle clock becomes meaningless.

Re: [9fans] alarm handling and suspended machines

[F.J.Ballesteros]

[-- Attachment #1: Type: text/plain, Size: 295 bytes --]

I'm not even a Lord of my RTC chip, which refuses to interrupt my cpu
even though I keep on asking it to do so. 

It's weird, I write 0x4 to the status register (to ask for an interrupt
to be sent), and when I print that register on the next line of code,
it keeps on printing `0'. sic.


[-- Attachment #2: Type: message/rfc822, Size: 1444 bytes --]

From: rog@vitanuova.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] alarm handling and suspended machines
Date: Wed, 13 Jun 2001 16:59:58 +0100
Message-ID: <20010613155121.BD91B199E4@mail.cse.psu.edu>

gsyc.escet.urjc.es!nemo wrote:
> I'm not a time guru

are you then perhaps a Time Lord?
inquiring minds wish to know.

Re: [9fans] alarm handling and suspended machines

[rog]

gsyc.escet.urjc.es!nemo wrote:
> I'm not a time guru

are you then perhaps a Time Lord?
inquiring minds wish to know.

Re: [9fans] alarm handling and suspended machines

[F.J.Ballesteros]

Perhaps this is a stupid idea, but what could be done is to
let each driver than can (rtc, cicle counter, ntp, whatever)
implement a #X/time file. Then it would be a matter of
binding them in the right order to let the user choose.
Regarding how to recover tod after suspends, if one of those
drivers knows that it will loose the time after a suspend,
it could read the time from another #X/time file to recover.

What I dislike about this is that time files would need to be
provided by different drivers. What I like is that the user could

test -e '#1/time' && bind -b '#1/time' /dev/time
test -e '#2/time' && bind -b '#2/time' /dev/time

and the #X/time implementation itself could try 
also to step through a set of preferred time recover sources 
in very much the same way.

Nevertheless, I'm not a time guru and this idea could be just 
a nonsense. 

Re: [9fans] alarm handling and suspended machines

[Russ Cox]

[-- Attachment #1: Type: text/plain, Size: 176 bytes --]

I think of /mnt/apm as temporary until we
figure out the right way to handle the
interface and the driver itself (and perhaps
avoid the clumsy BIOS calls as well).

Russ

[-- Attachment #2: Type: message/rfc822, Size: 3997 bytes --]

[-- Attachment #2.1.1: Type: text/plain, Size: 761 bytes --]

In any case, I now think that it would be better to prevent alarm(2)
from resuming a suspended machine; otherwise the user would need to be
careful not to start any periodic-alarm program (listen, etc.).

By the way, I have just compiled a kernel that has /dev/resume and
allows a write to set up a wake up timer. My problem now is that the
bitsy is ignoring the RTC alarm I set. I'm trying to see what I did
wrong...


One thing I think we need is to unify the apm interface.  It would be
nice to have a single set of files in /dev supplying the interface to
suspend/resume/battery status.  Right now my stats has to try twice to
display the battery status, since it has to work both with /mnt/apm and
with /dev/battery.

Any plans on this?


[-- Attachment #2.1.2: Type: message/rfc822, Size: 1707 bytes --]

From: presotto@plan9.bell-labs.com
To: 9fans@cse.psu.edu
Subject: Re: [9fans] alarm handling and suspended machines
Date: Tue, 12 Jun 2001 23:27:34 -0400
Message-ID: <20010613110506.64C19199E3@mail.cse.psu.edu>

we were about to do that on the pc's for a different reason.  The
mechanism should extend to the other architectures.  I've got to
figure out how to restart time when the fast clock stops running.
I can do a quick guess from the rtc and then use ntp to do the
rest but the timesync process will have to know when the
cycle clock becomes meaningless.

Re: [9fans] alarm handling and suspended machines

[presotto]

The rtc's on the pc's are pretty good.  They are clearly as good
a starting point as anything else.  They only give second time
which is a bit of a pain if you're trying to sync machines to
the millisecond but they make a good last resort time.

For a real clock on the different systems, we use the cycle
clock if there is one and use NTP measurements to calculate
the frequency and drift of that clock.  This an work well,
on our servers we can stay synced to within .0001 seconds
by just doing 1 ntp query an hour.  When we do measurements
that are time critical, we can keep within .000001 seconds
if we have to.

On the bitsy, I've been ignoring the real time clock till
you got power management working because the bottom switch
resets the RTC.

However, this scheme loses on systems that vary their cycle speed
for power management.  Timesync can never get a handle on the
clock speed.  I need a way to fix that, perhaps using the HZ
timer on those systems instead of the cycle counter.  On
systems that stop or reset the cycle counter when they sleep,
I need some way to get that info to timesync so that it doesn't
avg over the off time.

In addition, on PC's we dual boot.  Microsoft, in their infinite
wisdom, keep the RTC on local time rather than GMT.  In addition,
they handle their own clock jumps for daylight savings time.
That means that whenever we boot Plan 9, we have to guess at
what time the RTC is telling us.

My biggest problem is the cycle clock changing speed.  I should
be able to use either the RTC or the interval timer to decide
if the cycle timer is changing freq and act accordingly.
Timesync can do that if it can read all three.  I also
need to tell the kernel which timer to use to base time
on.  I may also have the kernel leave a flag in /dev/*time to tell
things like timesync that something has happened and that it
should recalibrate.

Re: [9fans] alarm handling and suspended machines

[Boyd Roberts]

> In addition, on PC's we dual boot.  Microsoft, in their infinite
> wisdom, keep the RTC on local time rather than GMT.

yes, that can be really messy.  i remember building some
stupid dos boot floppy to fix this problem for various
un-synced unix machines that had been shutown/moved/booted.

Re: [9fans] alarm handling and suspended machines

[presotto]

we were about to do that on the pc's for a different reason.  The
mechanism should extend to the other architectures.  I've got to
figure out how to restart time when the fast clock stops running.
I can do a quick guess from the rtc and then use ntp to do the
rest but the timesync process will have to know when the
cycle clock becomes meaningless.

Re: [9fans] alarm handling and suspended machines

[Lucio De Re]

On Tue, Jun 12, 2001 at 11:27:34PM -0400, presotto@plan9.bell-labs.com wrote:
> 
> we were about to do that on the pc's for a different reason.  The
> mechanism should extend to the other architectures.  I've got to
> figure out how to restart time when the fast clock stops running.
> I can do a quick guess from the rtc and then use ntp to do the
> rest but the timesync process will have to know when the
> cycle clock becomes meaningless.

The first step should presumably be to update the RTC on shutting
down, or is it kept up to date by timesync?

I get often irritated by alarm clocks that sync to the mains until
failure, then switch to the stand-by battery powered clock and in
all devices I have had to deal with, inevitably race way ahead.
By the time you get to correct it you have to trip right around 24
hours (or somewhat less).

Point is, if the clock manufacturers all have a good reason to
adopt such an annoying approach, one would similarly hope the RTC
is very exact (I have some interesting spread of accuracy in my
office) or fast.

I know I often overlook the obvious: in this case I don't quite
get the issue with the timesync?  If it's got to do with noticing
that the fast clock has been shut down, you may want timesync to
do the shutting down itself, in some safe fashion.  I assume that
is not impossible.

++L

PS: I'm sure I missed something obvious, yet again, but I may never
find out what it is if I don't ask, this mailing list is often
extremely cerebral :-(

Re: [9fans] alarm handling and suspended machines

[Mike Haertel]

>we were about to do that on the pc's for a different reason.  The
>mechanism should extend to the other architectures.  I've got to
>figure out how to restart time when the fast clock stops running.
>I can do a quick guess from the rtc and then use ntp to do the
>rest but the timesync process will have to know when the
>cycle clock becomes meaningless.

If by "cycle clock" you mean processor's time stamp counter,
using it for time keeping is a Bad Idea.  Nowdays there are
machines with variable speed processor clocks that get adjusted
for power saving reasons.  For example, I have a laptop
that automatically cuts the clock frequency when the battery
drops below 50%, apparently no matter what I do to the
power management settings in the BIOS.

[9fans] alarm handling and suspended machines

[F.J.Ballesteros]

When a process calls alarm(2), it is noted into the
alarms list by port/alarm.c. Since checkalarms checks the list
once per tick, the hw is unaware that there's an alarm scheduled.

My question is, couldn't alarm.c call to something like
wakeup_timer(time) with the time up to the next user alarm.

I ask this because if I want my ipaq to automatically resume from
suspend mode and warn me about an appointment or something, it must
have an RTC alarm set. This is not feasible if the portable
implementation doesn't let the mdep part know.

So, what about adding  wakeup_timer() calls in procalarm, and
implementing it in pc/ bitsy/ ... as either
- nothing
- (re)set a hw timer for the given time if suspend is supported.

The mach dep part could ignore the timer whenever it expires.

Any better suggestion?

BTW, although some commands use periodic alarms that could
wake up the machine if sysalarm(2) is changed, after a quick
grep under /sys/src/cmd, it seems that only network services are
doing so. Anyone knows of an obvious command that is likely to
be used on standalone bitsies and to schedule periodic alarms?