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.
Does this mean I get a first post? ;)
/proc/uptime. (I'm not sure if that is what it is under Linux, but the functional equivalent.)
A friend of mine has a machine up for over two years. I haven't seen the "uptime" to "proove" it, but I trust him.
An easy test would be to spew 2+ year time_t to
With stats like these, who gives a shit? 0 users, load average: 0.01, 0.07, 0.01
Well, there is also the quality issue -- I too have worked with old IBM equipment that had been on so long that the people who had powered it up had only bounced it twice in 20 years -- but the power supplies are of very good quality and have several redundant units. You can buy PC power supplies like that -- they just cost $600 each for 300 watts. When I built my big, honking, I-Have-A-HUUUGE-Penis dual PII that I was, at the time, justifiably proud of), I got a nice dual unit from Mag-Tech out in El Paso (they manufacture for CalPC and PC Power and Cooling (to go with my CalPC case -- they manufacture for PC Power and Cooling) and I paid $1400 for it. But I suspect that I will have one of the last running 32 bit boxes around, if need be!
There was a thread in comp.os.linux.development.system about this very thing called "497.2 days ought to be enough for everybody".
The consensus was that the kernel was okay, except some drivers may still have problems (2.0.x I think). To be on the safe side to get over the 497.2 day "hump", you could unload modules and turn off some daemons, IIRC.
Check it out here
In another /. article a long time ago there was a similar discussion. Someone suggested looking at the starting time of init to determine the uptime (when it wraps around).
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?
BTW: the command to determine the starting time of init is
init u 1
It's getting too late.. (i DID use the preview)
The correct command is: "ps u 1"
printf("int: %d bits\nlong int: %d bits", sizeof(int)*8, sizeof(long int)*8);
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.
A good UPS that outputs a sinewave power at a small voltage range will help a lot to reduce and/or eliminate most power supply problems. I recommend getting one just for that reason, even if you don't worry about uptime due to power loss.
at least it isn't 49 days! :)
--
9:43am up 492 days, 22:48, 0 users, load average: 0.01, 0.07, 0.01
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
Your computer will not crash. Don't panic or reboot. As long as your kernel is older than.. Umm... I don't remember. Ask Alan Cox. (Who you should have been asking about this anyway!) But I believe that your uptime values will wrap around. The report will say one day. If you are REALLY concerned about it, get a screen shot of being in X Windows or something with an uptime of one second. (Sure, it might have crashed, but did it really reboot in 1 second?)
This
That explains some stuff. I got an APC Back UPS Pro and my system stability improved immensely, but then again, in my dorm at Valpo U IN, when I turned on the coffee pot the wing would have a brown out! Also explains part of teh fried m-board in my old machine! I Like my new machine too, and the partially fried one still kicks well!
Laugh, it's good for you!
Well, one may have heard something similar before, but 38 years seems to be enough time even for intel to get out 64bit architectures, where the problem doesn't exist anymore AFAIK.
But you're right, if easy to accomplish, this problem should be corrected now, esp. considering linus' "linux for embedded systems" offensive
Who really wants a high uptime anyways? I, for one, derive a beautiful pleasure from rebooting my box. :)
Having thought about this a bit more, and checked some drivers, this is not exactly the case. In fact all the code I have looked at will exit immediately on a wrap-around condition. Counting jiffies is not too common, though.
Therefore at around the roll-over time, some device drivers may fail temprarily.
At my old university a sequent box (Dynix - weird UNIX flavour) had an uptime of 10 YEARS.
:)
The really weird thing is that a Sequent Symetry can do SMP with 386's (and manage rather more than 4 CPU's)
At my old university a sequent box (Dynix - weird UNIX flavour) had an uptime of 10 YEARS. If Linux stands by most UNIX conventions, it should show uptimes until 2038 without skipping a beat. I've seen kernel uptimes of 2+years with Linux but not more than that.
Now that we have that answered, we can get to the important question: what does nt use to remember uptime in seconds? short integers?
(no, this is not flamebait. it's a joke. laugh.)
-----
Do you even know anything about perl? -- AC Replying to Tom Christiansen post.
I don't have a clue to what you are saying, but 300 Billion years seems longer than a root canel. For my part, I'll keep reading and learning. Thanks, moon
It's all about Friday
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.