Is there an Uptime Limit? 33
Juniks[for dumminger asks: "O'Reilly's Linux Device Drivers states that:
'When the timer interrupt occurs, the jiffies values is incremented. jiffies is thus number of clock ticks since the operating system was booted; it is decleared in "linux/sched.h" as unsigned long volatile, and it will overflow in one and a third year of continuous operation.' So, will I lose my beloved uptime? I am almost there, and all my dignity will go down the drain if this is true. And not to mention my reputaition at work..." I might be mistaken, but I thought Linux took a time_t value during boot as reported by the RTC and used that for uptime computations. Can someone clarify?
For those that don't know GCC, time_t is the ANSI datatype for date/time storage.
Other way to determine uptime (Score:1)
It seems to be working, but I have noticed that (at least) Debian (2.1) is able to restart init when it is upgraded.
Does anybody know if this will affect its starting time?
The command (Score:1)
init u 1
Woops.. error in the command (Score:1)
The correct command is: "ps u 1"
Re:Long ints (Score:1)
This will produce...
int: 32 bits
long int: 32 bits
Proof positive. I seem to remember Borland C/C++ producing a different value...
Yep, just checked it (I actually still have Borland C++ 3.1 on my MSDos 486 PC). It reports 'int' to be 16 bits, and 'long int' to be 32 bits.
Anyway, 68 years will bring us past February 2038, so it'll do.... for now.
Re:You've got the most reliable hamsters... (Score:1)
Even if... (Score:1)
at least it isn't 49 days! :)
--
Hate to brag . . . (Score:1)
Kernel 2.0.34, I remember reading in a newsgroup of Alan Cox saying that the rollover was 490 days, but it doesn't seem like that yet. We'll see.
- hal9k
What will happen when the jiffies wrap around: (Score:1)
Re:First? (Score:1)
type "uptime".
press enter.
if that fails, you can always cat
UPS....uptime...hmm... (Score:1)
Re:Long ints (Score:1)
But you're right, if easy to accomplish, this problem should be corrected now, esp. considering linus' "linux for embedded systems" offensive
Who wants it? (Score:1)
Re:Not a severe problem. (Score:1)
Therefore at around the roll-over time, some device drivers may fail temprarily.
Re:you aint seen nothin yet. (Score:1)
The really weird thing is that a Sequent Symetry can do SMP with 386's (and manage rather more than 4 CPU's)
you aint seen nothin yet. (Score:1)
Re:Hate to brag . . . (Score:1)
nt? (Score:1)
(no, this is not flamebait. it's a joke. laugh.)
-----
Re:Relevant bits... (Score:1)
Was in 1.2.13 (Score:2)
I don't know if anyone ever reached it, but in kernel version 1.2.x and before there was a roll over at about 490 days. Linus said back then that he'd get around to fixing it if anyone accually complained about the limit. (Yes this disscussion has come up before)
AFAIK the limit was fixed in the 1.3.x series, about 1.3.60 if I remember right. I think someone else was buged by the theroetical limit and fixed it.
Yes, it will wrap (Score:2)
val.uptime = jiffies / HZ;
Thusly, if your jiffies wrap, your uptime will too.
If your box does anything mission critical, maybe its time for a reboot? There are still the occasional problems in the kernel with jiffy rapping.
btw - My first thoughts when I saw this was; "hmm, I'm sure this has been answered before in other places", but I did a search and couldn't find any references to uptime wrapping. (admitidly I didn't search too hard).
jiffies' overrun (Score:2)
immediate personal issue, as they frequently boot
their new code and reset the jiffy counter.
Because of this, there were occasionally bugs in
handling the overflow back to zero. There were no
showstopper bugs, mind you. At worst, you'd have
to reinitialize the code (unload and reload a
module containing bad code).
However, being clever people, for several versions
of the kernel we set the jiffies to MAXINT-6000,
so that jiffies would overrun after about ten
minutes. The bugs that existed were actually
debuggable, and most (if not all) of jiffy-related
bugs were cleaned up.
Since then, it's become more of a visible issue,
and code that is submitted is prolly checked for
clean handling of jiffy overflow.
You might have a version that has buggy code, but
it certainly won't Micros~1 on you.
- chad
You've got the most reliable hamsters... (Score:2)
Only a double-conversion UPS.. (Score:2)
A full-time UPS, also called double-conversion, wastes a lot of energy because it rectifies the input to DC and inverts it again. However, it produces a ridiculously stable output.
FYI, telecom equipment runs on constantly-charged DC battery supplies. If the city power fails, they go from float to discharging, but the equipment never notices. Any equipment in the office that runs on AC gets it from inverters, so they never see a bump either.
Re:Relevant bits... (Score:2)
ive got a strong 31 days going heheheh
god that would be cool but very very impossible
Anyone wanna bet MS will hear of this (Score:2)
Long ints (Score:3)
What is worth worrying about is that the time_t for absolute date will overflow in 2038
Re:Yes, it will wrap (Score:3)
I am the Jiffyman, I'm here to say,
Jiffies gotta go about their normal day!
Word up to the clockticks, yo,
Bein' a Jiffy's da only way ta go! Werd up.
---
"'Is not a quine' is not a quine" is a quine.
Not a severe problem. (Score:3)
Some drivers perform waits by monitoring jiffies until it reaches a calculated value. If one of these loops starts just before jiffies wraps around, then the value calculated should also wrap around, providing the correct data-type is used. Therefore such a loop should still exit normally.
If you're feeling paranoid, search the source of all the drivers you use in your version of the kernel.
Relevant bits... (Score:5)
I gave it a cursory look over, and yes, the time is read directly from /proc/uptime. OK, so where do these values get set? (and the values in /proc/uptime are in seconds).
So we peek at the kernel source... Lo and Behold, in include/linux/kernel.h we find that uptime is a long int. 64-bits, that is. An even better explanation of the jiffies vs. seconds calculations are in fs/proc/array.c.
The final answer is: uptime is a long integer (2^63, since it seems to be signed), with values in seconds. So, it should wrap around after being up for 2.9e11 years or so ( almost 300 billion years).
I wouldn't worry.
-Erik
If you have the source, all things become transparent...