Slashdot Mirror
Is there an Uptime Limit?
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.
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.
A quick rgrep through the linux source for "uptime" reveals:
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).
I use to have a funny sig, but slash cut it off, and I forgot what the punchline was.
For kernel developers, uptime is rarely an
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
I shouldn't be surprised really, I work in telecom and there's equipment in some offices that's been continuously powered since before I was born. But still, PC power supplies aren't known for being reliable! Don't you ever have hardware failures?
Most UPSs sold today are standby-type. They filter the input power and pass it back out almost unchanged. The inverter and battery only come into play when necessary. Some nicer UPSs will also select the appropriate tap on a transformer to "buck or boost" the input voltage, but it's still not exactly stable.
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.
3 billion years eh?
ive got a strong 31 days going heheheh
god that would be cool but very very impossible
NT hasn't got the theoretical uptime limit of linux so is more mission critical. Expect to see it on their site within 3 days... :)
Long ints are the same size as normal ints on 32 bit platforms at least, such as 386. So that's 2^31 = 68 years - still nothing to worry about :)
What is worth worrying about is that the time_t for absolute date will overflow in 2038
The volatile variable jiffies is used in some kernel drivers as a quick and dirty counter. Jiffies is incremented every clock tick, which in the i386 kernel occurs 100 times a secound.
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.
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...
There are always four sides to every story: your side, their side, the truth, and what really happened.