[SGVLUG] linux uptimes

[Claude Felizardo]

On 3/31/06, Michael Proctor-Smith <mproctor13 at gmail.com> wrote:
> On 3/31/06, Claude Felizardo <cafelizardo at gmail.com> wrote:
> > was looking at the linux counter website...
> >
> > http://counter.li.org/reports/uptimestats.php
> >
> > Top ten long-running machines
> > DAYS         KERNEL                 CPU
> > =======================================
> > 1624.5      2.2.13-7mdk            Cyrix 486
> > 1572.0      2.2.20-rs                 Intel 386
> > 1344.2      2.4.18-grsec-1.9.4   Intel Celeron
> > 1223.5      2.4.7-10                  Intel PentiumIII
> > 1206.3      2.4.21-pre1             Intel Pentium
> > 1133.6      2.4.18-686              Intel PentiumII
> > 1108.1      2.4.20                     Intel PentiumII
> > 1087.4      2.4.18                     Intel Pentium III
> >  976.1       2.4.18                     Intel Pentium III
> >  956.4       2.4.18-14                Intel PentiumIII
> >
> > More info about his stats at the website.  Other stats such as kernel
> > versions and system stats:  http://counter.li.org/reports/
> >
> > Looks like the Cyrix is running an older mandrake, hopefully behind a
> > firewall.  My boxes currently have 60 and 41 days.  The machine where
> > I have my alumni website, also running mdk, has been up 96 days.  One
> > of the linux boxes here at work has been up 329 days.  Most of the
> > solaris boxes have been up 90-120 days.  And just because, my Netgear
> > router has been running 899 days, DSL connection up for 805 days.
> >
>
> Lies all lies, jk
> Linux uptime rolls over some where in the 400-500 day range so the
> only way to know is to check logs or just know. Simply running uptime
> command will not tell you. I have had some RHEL3 boxes in the 600 day
> range.

ah, but if you read the notes at the bottom of that first link...
-----------------
NOTE: The Linux kernel (at least up to 2.4.2) has a flaw: It computes
the result of the "uptime" based on the internal "jiffies" counter,
which counts the time since boot, in units of 10 milliseconds.
This is typecast as an "unsigned long" - on the Intel boxes, that's an
unsigned 32-bit number.
Well, it turns out that in a 32-bit number, you can store 497.1 days
before the number wraps. So all the numbers higher than this on this
list are because:

    * They are not Intel architectures
    * They have sent in updates on both sides of the wrap, and my
scripts have successfully correlated them and concluded that it was a
wrap, not a reboot.