Hi,
I'd like to enquire about the following behaviour:
$ uptime && sudo hibernate && uptime
14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
I.e. the system was suspended to disk for 5 minutes, but the value
reported by 'uptime' has increased by as much, as if it had actually
continued running during that time.
I'm using Linux 2.6.16 with the latest version of the Suspend 2 patch
(2.2.1), but Nigel its maintainer says that this isn't actually related
to his suspend code, essentially the same would happen using the swsusp
code currently in the kernel, and therefore we need to ask the kernel
time code people about this issue.
I've been using suspend2 for a while now, and until some point in the
past it used to be the case that uptime would stand still during
hibernation, i.e. only counting the time during which the system was
actually up and running. This seems like more meaningful and desirable
behaviour to me.
The way it is now, one can essentially "cheat": suspend a machine, put
it in the cupboard for a couple of weeks, resume it and claim a
respectable uptime, because the uptime value only reflects how long ago
the system was first booted up, with no regard to how much of that time
it has actually been running.
Would it be possible to get the old behaviour back?
Greetings,
--
jonathaN
Hi,
On Saturday 25 March 2006 16:02, Jonathan Black wrote:
> I'd like to enquire about the following behaviour:
>
> $ uptime && sudo hibernate && uptime
> 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
> 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
>
> I.e. the system was suspended to disk for 5 minutes, but the value
> reported by 'uptime' has increased by as much, as if it had actually
> continued running during that time.
>
> I'm using Linux 2.6.16 with the latest version of the Suspend 2 patch
> (2.2.1), but Nigel its maintainer says that this isn't actually related
> to his suspend code, essentially the same would happen using the swsusp
> code currently in the kernel, and therefore we need to ask the kernel
> time code people about this issue.
Is your system an i386 or x86_64?
Rafael
On Sat, Mar 25, 2006 at 04:10:16PM +0100, Rafael J. Wysocki wrote:
> On Saturday 25 March 2006 16:02, Jonathan Black wrote:
> > I'd like to enquire about the following behaviour:
> >
> > $ uptime && sudo hibernate && uptime
> > 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
> > 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
> >
> > I.e. the system was suspended to disk for 5 minutes, but the value
> > reported by 'uptime' has increased by as much, as if it had actually
> > continued running during that time.
> >
> > I'm using Linux 2.6.16 with the latest version of the Suspend 2 patch
> > (2.2.1), but Nigel its maintainer says that this isn't actually related
> > to his suspend code, essentially the same would happen using the swsusp
> > code currently in the kernel, and therefore we need to ask the kernel
> > time code people about this issue.
>
> Is your system an i386 or x86_64?
It is an i386.
--
jonathaN
On Saturday 25 March 2006 16:18, Jonathan Black wrote:
> On Sat, Mar 25, 2006 at 04:10:16PM +0100, Rafael J. Wysocki wrote:
> > On Saturday 25 March 2006 16:02, Jonathan Black wrote:
> > > I'd like to enquire about the following behaviour:
> > >
> > > $ uptime && sudo hibernate && uptime
> > > 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
> > > 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
> > >
> > > I.e. the system was suspended to disk for 5 minutes, but the value
> > > reported by 'uptime' has increased by as much, as if it had actually
> > > continued running during that time.
> > >
> > > I'm using Linux 2.6.16 with the latest version of the Suspend 2 patch
> > > (2.2.1), but Nigel its maintainer says that this isn't actually related
> > > to his suspend code, essentially the same would happen using the swsusp
> > > code currently in the kernel, and therefore we need to ask the kernel
> > > time code people about this issue.
> >
> > Is your system an i386 or x86_64?
>
> It is an i386.
This seems to happen on my box either, which is an x86_64, so it looks like
this doesn't depend on the architecture. Investigating.
Rafael
On Sat, 2006-03-25 at 16:02 +0100, Jonathan Black wrote:
> I'd like to enquire about the following behaviour:
>
> $ uptime && sudo hibernate && uptime
> 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
> 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
>
> I.e. the system was suspended to disk for 5 minutes, but the value
> reported by 'uptime' has increased by as much, as if it had actually
> continued running during that time.
Yes, I don't know exactly when it was changed, but jiffies is now
updated when we return from suspend, which causes the uptime to
effectively increase while we are suspended.
[snip]
> The way it is now, one can essentially "cheat": suspend a machine, put
> it in the cupboard for a couple of weeks, resume it and claim a
> respectable uptime, because the uptime value only reflects how long ago
> the system was first booted up, with no regard to how much of that time
> it has actually been running.
Well, anyone can hack their kernel to say whatever uptime they want, so
I'm not to worried about cheating. Are you seeing an actual bug here?
> Would it be possible to get the old behaviour back?
Why exactly do you want this behavior? Maybe a better explanation would
help stir this discussion.
The question about the correct behavior is more relevant with
virtualization as well. Should the OS's uptime increase even when
another OS is running on the cpu? What is the proper interface to export
the OS's cpu time?
Right now I'm of the opinion that jiffies should be updated, as real
time has past and timer events that are queued should expire.
However with a good enough reason, we might want to add another counter
that keeps track of how much time we've been suspended as well.
thanks
-john
In article <1143484821.2168.16.camel@leatherman> you wrote:
>> Would it be possible to get the old behaviour back?
> Why exactly do you want this behavior? Maybe a better explanation would
> help stir this discussion.
I don't know why he wants it (uptime does not increase during
hibernation) but I want it so that I can tell if I should time out or
not on an alarm for inactivity in userspace! The alarm should fire if
there has been no activity for a while (30s) while activity is possible.
If the machine is suspended, no activity is possible, so the alarm
should not fire.
This is to counteract sysadamins playing with system time (e.g. syncing
with a net time server after bootup) which might cause artificial time
outs. Causing a timeout has nasty consequences when, for example, your
root fs is mounted over the net via daemons that do the network to-ing
and fro-ing from userspace. The only way they have of getting an
estimate of REAL time elapsed, without admin playing about messing
with them, is by surreptitiously snooping uptime, which more or less
represents kernel jiffies.
If you change uptime to not represente kernel jiffies, goodbye the last
hope for counting CPU time passed from userspace. False timeouts WILL
ensue, and root mounts will fail.
Peter
On Mon, 27 Mar 2006, Peter T. Breuer wrote:
> In article <1143484821.2168.16.camel@leatherman> you wrote:
>>> Would it be possible to get the old behaviour back?
>
>> Why exactly do you want this behavior? Maybe a better explanation would
>> help stir this discussion.
>
> I don't know why he wants it (uptime does not increase during
> hibernation) but I want it so that I can tell if I should time out or
> not on an alarm for inactivity in userspace! The alarm should fire if
> there has been no activity for a while (30s) while activity is possible.
> If the machine is suspended, no activity is possible, so the alarm
> should not fire.
>
> This is to counteract sysadamins playing with system time (e.g. syncing
> with a net time server after bootup) which might cause artificial time
> outs. Causing a timeout has nasty consequences when, for example, your
> root fs is mounted over the net via daemons that do the network to-ing
> and fro-ing from userspace. The only way they have of getting an
> estimate of REAL time elapsed, without admin playing about messing
> with them, is by surreptitiously snooping uptime, which more or less
> represents kernel jiffies.
>
> If you change uptime to not represente kernel jiffies, goodbye the last
> hope for counting CPU time passed from userspace. False timeouts WILL
> ensue, and root mounts will fail.
>
> Peter
Well uptime code can be modified to subtract the time (if any) in
hibernation. Then everybody is happy.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.15.4 on an i686 machine (5589.42 BogoMips).
Warning : 98.36% of all statistics are fiction, book release in April.
_
****************************************************************
The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or entities other than the intended recipient is prohibited. If you are not the intended recipient, please notify Analogic Corporation immediately - by replying to this message or by sending an email to [email protected] - and destroy all copies of this information, including any attachments, without reading or disclosing them.
Thank you.
On Mon, Mar 27, 2006 at 10:40:20AM -0800, john stultz wrote:
> > Would it be possible to get the old behaviour back?
>
> Why exactly do you want this behavior? Maybe a better explanation would
> help stir this discussion.
Well, if X session with xscreesaver was active when suspending,
screensacer will be activated just after resume. And if by chance
OpenGL hack will be run, X will freeze. Because running apps using
OpenGL or xvideo after resume freezes X (for me, at least).
--
Tomasz Torcz "God, root, what's the difference?"
[email protected] "God is more forgiving."
27.03.2006 21:53, Peter T. Breuer wrote/a écrit:
> In article <1143484821.2168.16.camel@leatherman> you wrote:
>>> Would it be possible to get the old behaviour back?
>
>> Why exactly do you want this behavior? Maybe a better explanation would
>> help stir this discussion.
>
> I don't know why he wants it (uptime does not increase during
> hibernation) but I want it so that I can tell if I should time out or
> not on an alarm for inactivity in userspace! The alarm should fire if
> there has been no activity for a while (30s) while activity is possible.
> If the machine is suspended, no activity is possible, so the alarm
> should not fire.
>
> This is to counteract sysadamins playing with system time (e.g. syncing
> with a net time server after bootup) which might cause artificial time
> outs. Causing a timeout has nasty consequences when, for example, your
> root fs is mounted over the net via daemons that do the network to-ing
> and fro-ing from userspace. The only way they have of getting an
> estimate of REAL time elapsed, without admin playing about messing
> with them, is by surreptitiously snooping uptime, which more or less
> represents kernel jiffies.
It seems that what you are really looking for in your application is a
monotonic clock. Linux has such thing since few releases. Using
CLOCK_MONOTONIC (cf "man 3 clock_gettime") may look much less hacky than
using the uptime ;-)
Now... concerning the suspend effect on this clock, I don't know. It's
probably the same problem as uptime: no official semantic has ever been
stated yet... Does anyone know?
Eric
Hi,
On Monday 27 March 2006 20:40, john stultz wrote:
> On Sat, 2006-03-25 at 16:02 +0100, Jonathan Black wrote:
> > I'd like to enquire about the following behaviour:
> >
> > $ uptime && sudo hibernate && uptime
> > 14:18:51 up 1 day, 4:12, 2 users, load average: 0.58, 3.30, 2.42
> > 14:23:46 up 1 day, 4:17, 2 users, load average: 20.34, 7.74, 3.91
> >
> > I.e. the system was suspended to disk for 5 minutes, but the value
> > reported by 'uptime' has increased by as much, as if it had actually
> > continued running during that time.
>
> Yes, I don't know exactly when it was changed, but jiffies is now
> updated when we return from suspend, which causes the uptime to
> effectively increase while we are suspended.
IIRC on x86_64 jiffies has always been updated in timer_resume(),
but this did not cause uptime to behave like that until recently.
There must have been an unrelated change somewhere in the time-handling
code that made this behavior appear, but I haven't found it yet.
> [snip]
> > The way it is now, one can essentially "cheat": suspend a machine, put
> > it in the cupboard for a couple of weeks, resume it and claim a
> > respectable uptime, because the uptime value only reflects how long ago
> > the system was first booted up, with no regard to how much of that time
> > it has actually been running.
>
> Well, anyone can hack their kernel to say whatever uptime they want, so
> I'm not to worried about cheating. Are you seeing an actual bug here?
>
> > Would it be possible to get the old behaviour back?
>
> Why exactly do you want this behavior? Maybe a better explanation would
> help stir this discussion.
Apparently it makes some people's setups break.
Greetings,
Rafael
"Also sprach Eric Piel:"
> It seems that what you are really looking for in your application is a
> monotonic clock. Linux has such thing since few releases. Using
> CLOCK_MONOTONIC (cf "man 3 clock_gettime") may look much less hacky than
> using the uptime ;-)
Likely. But I and others have to support all kernels and all operating
systems, and the code would look less hacky if it could use just one
thing, and continue using it. Uptime has been used this way for years
by many many applications. Read proc/sysinfo.c from procps...
/***********************************************************************
* Some values in /proc are expressed in units of 1/HZ seconds, where HZ
* is the kernel clock tick rate. One of these units is called a jiffy.
* The HZ value used in the kernel may vary according to hacker desire.
* According to Linus Torvalds, this is not true. He considers the values
* in /proc as being in architecture-dependant units that have no relation
* to the kernel clock tick rate. Examination of the kernel source code
* reveals that opinion as wishful thinking.
*
* In any case, we need the HZ constant as used in /proc. (the real HZ value
* may differ, but we don't care) There are several ways we could get HZ:
*
* 1. Include the kernel header file. If it changes, recompile this library.
* 2. Use the sysconf() function. When HZ changes, recompile the C library!
* 3. Ask the kernel. This is obviously correct...
*
* Linus Torvalds won't let us ask the kernel, because he thinks we should
* not know the HZ value. Oh well, we don't have to listen to him.
* Someone smuggled out the HZ value. :-)
*
* This code should work fine, even if Linus fixes the kernel to match his
* stated behavior. The code only fails in case of a partial conversion.
*
* Recent update: on some architectures, the 2.4 kernel provides an
* ELF note to indicate HZ. This may be for ARM or user-mode Linux
* support. This ought to be investigated. Note that sysconf() is still
* unreliable, because it doesn't return an error code when it is
* used with a kernel that doesn't support the ELF note. On some other
* architectures there may be a system call or sysctl() that will work.
*/
Etc.
How am I supposed to know on which installation what will work and what
will not? What do you propose? Try CLOCK_MONOTONIC and see if it returns
EINVAL, then fall back to uptime?
(and it'll be some years before my manpage documents the flag you give!
- I don't even have a man page for clock_gettime! Aahh ... I see it on a
more recent debian system ... yes, that looks good).
Sigh, more configure.in-ery.
On POSIX systems on which these functions are available, the symbol
_POSIX_TIMERS is defined in <unistd.h> to a value greater than 0. The
symbols _POSIX_MONOTONIC_CLOCK, _POSIX_CPUTIME, _POSIX_THREAD_CPUTIME
indicate that CLOCK_MONOTONIC, CLOCK_PROCESS_CPUTIME_ID,
CLOCK_THREAD_CPUTIME_ID are available.
This is getting as bad as bdflush.
> Now... concerning the suspend effect on this clock, I don't know. It's
> probably the same problem as uptime: no official semantic has ever been
> stated yet... Does anyone know?
Peter
"Also sprach Eric Piel:"
> monotonic clock. Linux has such thing since few releases. Using
> CLOCK_MONOTONIC (cf "man 3 clock_gettime") may look much less hacky than
> using the uptime ;-)
Actually, the man page does not say anything about the behavior across
suspends, and ...
CLOCK_REALTIME
System-wide realtime clock. Setting this clock requires appro-
priate privileges.
CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since
some unspecified starting point.
I'd understand both those wordings the same way! Well, I suppose
"cannot be set" means that at least humans can't willingly interfere with
it, but maybe something else can.
> Now... concerning the suspend effect on this clock, I don't know. It's
> probably the same problem as uptime: no official semantic has ever been
> stated yet... Does anyone know?
"Monotonic" means "always goes in the same direction", not "never
skips".
Peter
On Mon, Mar 27, 2006 at 10:40:20AM -0800, john stultz wrote:
> On Sat, 2006-03-25 at 16:02 +0100, Jonathan Black wrote:
> > The way it is now, one can essentially "cheat": suspend a machine,
> > put it in the cupboard for a couple of weeks, resume it and claim a
> > respectable uptime, because the uptime value only reflects how long
> > ago the system was first booted up, with no regard to how much of
> > that time it has actually been running.
>
> Well, anyone can hack their kernel to say whatever uptime they want,
> so I'm not to worried about cheating. Are you seeing an actual bug
> here?
Well, of course the uptime value reported by a hacked kernel cannot be
trusted to be accurate or meaningful. My problem is that with the
current behaviour, even the value reported by an *unhacked* kernel
cannot really be trusted, or at least is a lot less meaningful than it
was before, on a machine which uses suspend.
> > Would it be possible to get the old behaviour back?
>
> Why exactly do you want this behavior? Maybe a better explanation
> would help stir this discussion.
>
> The question about the correct behavior is more relevant with
> virtualization as well. Should the OS's uptime increase even when
> another OS is running on the cpu? What is the proper interface to
> export the OS's cpu time?
>
> Right now I'm of the opinion that jiffies should be updated, as real
> time has past and timer events that are queued should expire.
>
> However with a good enough reason, we might want to add another
> counter that keeps track of how much time we've been suspended as
> well.
Others have given some practical examples. I think there are probably
examples to be given of both: things that should behave as if the time
spent suspended has actually passed, and things that should behave as if
it had not. So maybe is a good idea to have both these notions available
somehow.
My initial point was really only that the value reported as the system's
"uptime" should be the latter kind of counter, as it seems silly to
include time during with the machine is completely powered off.
Greetings,
--
jonathaN