Monday, November 30, 2009

Re: [BLUG] uptime no reset at 1024

I stand corrected.

It might be interesting to see how 'uptime(1)' gets the information.

A man of times(2) shows the return value (a clock_t) was the time when
the system was booted for 2.4 series kernels, but that's no longer the
case for 2.6 kernels.

Cheers,
Steven Black

On Mon, Nov 30, 2009 at 05:12:03PM +0000, Mark Krenz wrote:
>
> Your Occam's Razor smack down has been canceled out by evidence.
>
> Linux kernels USED TO wrap around their uptime at 497 days. This was
> due to how the uptime was stored in the kernel. As a measument of
> jiffies. Jiffies used to be set to 100 per second, but can now be
> adjusted to even 1000 per second. This is what that 100Hz, 250Hz, 1000Hz
> setting is in the kernel config. Thus the time stored in the uptime
> used to be limited to 2^32 seconds / 100jiffies / 86400 sec/day = 497days
>
> I noticed once that the shell server at Kiva, which is still running
> on the 2.2 kernel, wrapped around its uptime at 497 days like this.
>
>
> Anyways, I had heard offhand comments that the number of days might
> wrap around at 1024 days, so I was curious if something might happen at
> 1024 days. It wasn't really based on the above, it was just based on
> heresay and anecdotal evidence.
>
> After all, I found that the load average itself wraps around at
> 1024.0 on 2.4 kernels at least. And yes, I did see a machine reach a 1
> minute load average of over 15000. I had to determine this by using some
> logs I had that showed that it was wrapping around. The machine in
> question wasn't really using that much CPU, it was load that was based
> on deadlocking samba processes that were trying to run 'df' on a machine
> with hung NFS mounts.
>
> Mark
>
> On Mon, Nov 30, 2009 at 04:43:58PM GMT, Steven Black [blacks@indiana.edu] said the following:
> > Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
> > down.)
> >
> > The uptime is a time, so it is likely stored in a time_t. This means it
> > would normally be subject to the same year 2038 Unix Epoch wrap provided
> > the system used 32-bit time_t values.
> >
> > However, it is stored as a relative time, so the that the beginning of
> > this particular epoch was when the machine was started up. This means it
> > wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
> > you started it up. And again, this is only if it is a 32-bit machine
> > with a 32-bit time_t.
> >
> > Cheers,
> > Steven Black
> >
> > On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
> > >
> > > # w
> > > 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
> > >
> > > I was wondering if the days would wrap around at 1024 days. I guess
> > > they don't.
> > >
> > >
> > > --
> > > Mark Krenz
> > > Bloomington Linux Users Group
> > > http://www.bloomingtonlinux.org/
> >
> > _______________________________________________
> > BLUG mailing list
> > BLUG@linuxfan.com
> > http://mailman.cs.indiana.edu/mailman/listinfo/blug
> >
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug

--
Cheers,
Steven Black

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] uptime no reset at 1024

Your Occam's Razor smack down has been canceled out by evidence.

Linux kernels USED TO wrap around their uptime at 497 days. This was
due to how the uptime was stored in the kernel. As a measument of
jiffies. Jiffies used to be set to 100 per second, but can now be
adjusted to even 1000 per second. This is what that 100Hz, 250Hz, 1000Hz
setting is in the kernel config. Thus the time stored in the uptime
used to be limited to 2^32 seconds / 100jiffies / 86400 sec/day = 497days

I noticed once that the shell server at Kiva, which is still running
on the 2.2 kernel, wrapped around its uptime at 497 days like this.


Anyways, I had heard offhand comments that the number of days might
wrap around at 1024 days, so I was curious if something might happen at
1024 days. It wasn't really based on the above, it was just based on
heresay and anecdotal evidence.

After all, I found that the load average itself wraps around at
1024.0 on 2.4 kernels at least. And yes, I did see a machine reach a 1
minute load average of over 15000. I had to determine this by using some
logs I had that showed that it was wrapping around. The machine in
question wasn't really using that much CPU, it was load that was based
on deadlocking samba processes that were trying to run 'df' on a machine
with hung NFS mounts.

Mark

On Mon, Nov 30, 2009 at 04:43:58PM GMT, Steven Black [blacks@indiana.edu] said the following:
> Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
> down.)
>
> The uptime is a time, so it is likely stored in a time_t. This means it
> would normally be subject to the same year 2038 Unix Epoch wrap provided
> the system used 32-bit time_t values.
>
> However, it is stored as a relative time, so the that the beginning of
> this particular epoch was when the machine was started up. This means it
> wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
> you started it up. And again, this is only if it is a 32-bit machine
> with a 32-bit time_t.
>
> Cheers,
> Steven Black
>
> On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
> >
> > # w
> > 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
> >
> > I was wondering if the days would wrap around at 1024 days. I guess
> > they don't.
> >
> >
> > --
> > Mark Krenz
> > Bloomington Linux Users Group
> > http://www.bloomingtonlinux.org/
>
> _______________________________________________
> BLUG mailing list
> BLUG@linuxfan.com
> http://mailman.cs.indiana.edu/mailman/listinfo/blug
>

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Re: [BLUG] uptime no reset at 1024

Let's think realisticly. (Or, perhaps, provide an Occam's Razor smack
down.)

The uptime is a time, so it is likely stored in a time_t. This means it
would normally be subject to the same year 2038 Unix Epoch wrap provided
the system used 32-bit time_t values.

However, it is stored as a relative time, so the that the beginning of
this particular epoch was when the machine was started up. This means it
wouldn't be expected to wrap until (2038 - 1970 =) 68 years from when
you started it up. And again, this is only if it is a 32-bit machine
with a 32-bit time_t.

Cheers,
Steven Black

On Mon, Nov 30, 2009 at 01:49:10PM +0000, Mark Krenz wrote:
>
> # w
> 08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17
>
> I was wondering if the days would wrap around at 1024 days. I guess
> they don't.
>
>
> --
> Mark Krenz
> Bloomington Linux Users Group
> http://www.bloomingtonlinux.org/

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

[BLUG] uptime no reset at 1024

# w
08:48:11 up 1028 days, 0 min, 6 users, load average: 0.03, 0.19, 0.17

I was wondering if the days would wrap around at 1024 days. I guess
they don't.


--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Saturday, November 28, 2009

[BLUG] [rescue] FS: NeXT Cube

I'm selling a NeXT Cube I got in a palette of stuff. I've already got a
turbo color slab so I really don't need a cube :) I'm located in
Bloomington, IN and I'm not going to ship this!

NeXT Cube N1000A
P/N: 2115
S/N: ABA0003988

* 68040 @ 25MHz
* 64M RAM
* Floppy
* Broken 5.25 FH HD. Spins up then down. I'll supply a 2G HH Drive
* Non-ADB Keyboard
* Non-ADB Mouse -- damaged. It looks like someone let it sit in glue or
a solvent. The ball still rolls, but I can't open it to check to see if
the rollers work.
* Monochrome monitor. Readable, but like all monitors of that vintage
its a bit faded.

I'm asking $150

Brian
_______________________________________________
rescue list - http://www.sunhelp.org/mailman/listinfo/rescue

_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

[BLUG] FS: NeXT Cube

I'm selling a NeXT Cube I got in a palette of stuff. I've already got a
turbo color slab so I really don't need a cube :) I'm located in
Bloomington, IN and I'm not going to ship this!

NeXT Cube N1000A
P/N: 2115
S/N: ABA0003988

* 68040 @ 25MHz
* 64M RAM
* Floppy
* Broken 5.25 FH HD. Spins up then down. I'll supply a 2G HH Drive
* Non-ADB Keyboard
* Non-ADB Mouse -- damaged. It looks like someone let it sit in glue or
a solvent. The ball still rolls, but I can't open it to check to see if
the rollers work.
* Monochrome monitor. Readable, but like all monitors of that vintage
its a bit faded.

I'm asking $150

Brian


_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug

Friday, November 27, 2009

[BLUG] [OT] 36" Sony SD TV for free

Ok, sorry for the spam, but its not really spam since I'll give away
the TV to anyone on this list. Its a BLUG list special deal because you
are all so great.

I bought an HDTV and now I have my old standard def TV that I need to
get rid of. It still works great, its just 480 resolution.

The specific model is Sony KV-36FS10 36" Wega Trinitron TV. This is
one of the nice Sony TVs with a flat screen. Its not a flat panel TV,
but it does have a flat screen. I bought it in 1999 for $1300 and its
been a great TV. It still works and can be used for anything that has
RCA, S-video or Component output, which is pretty much everything.

I'd keep it, but I just don't have room for it. I tried to sell it on
craigslist for $100 and even $25. But I guess that's too much. :-/

So anyone on the BLUG list is welcome to have it for free, provided
that you come over and pick it up yourself and with someone else to help
you.

If you are interested, please write me directly.

--
Mark Krenz
Bloomington Linux Users Group
http://www.bloomingtonlinux.org/
_______________________________________________
BLUG mailing list
BLUG@linuxfan.com
http://mailman.cs.indiana.edu/mailman/listinfo/blug