Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Linux Software

Is there an Uptime Limit? 33

Posted by Cliff from the say-it-ain't-so dept.
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.
This discussion has been archived. No new comments can be posted.

Is there an Uptime Limit? More

Is there an Uptime Limit?

Comments Filter:
  • 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?

  • The command (Score:1)

    by ESD ( 62 )
    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.
  • Even if it didn't wrap...

    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?)
  • open a shell window.
    type "uptime".
    press enter.
    if that fails, you can always cat /proc/uptime
  • 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!
  • 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.
  • It could be that uptime is smart enough to interprete this value as an unsigned integer. In that case you would notice it only after 980 days.

  • nt? (Score:1)

    by emmons ( 94632 )
    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.)

    -----
  • 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

  • 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).
  • 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 (Score:3)

    by jmalicki ( 1764 ) on Sunday October 17, 1999 @07:49AM (#1607811)
    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

  • Re:Yes, it will wrap (Score:3)

    by Pascal Q. Porcupine ( 4467 ) on Sunday October 17, 1999 @12:08PM (#1607812) Homepage
    Jiffy rapping?

    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)

    by yorkie ( 30130 ) on Sunday October 17, 1999 @01:04AM (#1607813)
    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.

  • Relevant bits... (Score:5)

    by trims ( 10010 ) on Sunday October 17, 1999 @12:39AM (#1607814) Homepage
    ... are in the procps package. Specifically, in the proc/sysinfo.c file.

    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...

Slashdot Top Deals

"When the going gets tough, the tough get empirical." -- Jon Carroll

Close