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.

Comments

Long ints

[jmalicki]

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

[Pascal Q. Porcupine]

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.

[yorkie]

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

[trims]

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