Author Topic: Longest computer up time?  (Read 7628 times)

Blicj11

  • Storm
  • *****
  • Posts: 2996
    • EW3808
    • KUTHEBER6
    • Timber Lakes Utah
  • Station Details: Davis Vantage Pro2 Plus | WeatherLinkIP™ Data Logger | iMac (late 2013), 3.5 GHz Intel Core i7, 24 GB RAM, macOS High Sierra | Sharx SCNC2900 Webcam | Supportive Wife
Re: Longest computer up time?
« Reply #30 on: June 15, 2016, 09:49:30 PM »
Great thread, guys! Enjoyed the read on "why VMS chooses to treat the year 2000 as a leap year." Best and most detailed explanation I've seen, so far.

Amen! Thanks for a pleasant read and the requirement for a healthy think.
Blick


elagache

  • Global Moderator
  • Storm
  • *****
  • Posts: 4968
    • DW3835
    • KCAORIND10
    • Canebas Weather
  • Station Details: Davis Vantage Pro-2, MacBook Pro (Early 2011), macOS 10.13.6, WeatherCat 3
Best to reboot before kernel panic! (Re: Longest computer up time?)
« Reply #31 on: June 15, 2016, 11:32:54 PM »
Dear X-Air, dfw, and WeatherCat computer science observers,

Seconds from the Epoch?

That is the UNIX standard and because of that we will have yet another Y2K mess in 2032.  Here is a Wikipedia article about it:

https://en.wikipedia.org/wiki/Year_2038_problem

Of course, there are good reasons to reboot your computer from time to time.  I was getting desperately short of memory yesterday but I had a ton of things to do so I kept right on working . . . . . until my computer crashed with a kernel panic!   [banghead]

Oh well, . . . . Edouard

xairbusdriver

  • Storm
  • *****
  • Posts: 2174
    • EW7115 (E7115)
    • KTNGERMA20
    • Mid-South Weather
  • Station Details: Davis VP2 wireless + remote Anemometer/2014 Mac min - 10.13.4/WC 3.0
Re: Longest computer up time?
« Reply #32 on: June 16, 2016, 03:27:01 AM »
Quote
until my computer crashed with a kernel panic!
Obviously not one of those HP servers... "I need more nodes... or was it <more cowbell>?"

Michel

  • Gentle Breeze
  • **
  • Posts: 38
    • MichelsWunderland
  • Station Details: WH3080 - See website for details
Re: Longest computer up time?
« Reply #33 on: June 16, 2016, 09:16:09 AM »
Quote from: xairbusdriver
Which one of those guys was you?! [lol]
I would have loved been the director, but... much to my chagrin I wasn't involved with it all.  :(

Quote
BTW, Ouachita County, Arkansas is the home of the <Arkansas Law Enforcement Training Academy>,
probably the actual location for this "disaster".

'Interesting' institution/authority.

Quote
I'm impressed (even though no macOS [note new designation protocol] software was used)!

Probably like I was by the Mac and its ease of use when I acquired it compared
to what I previously was used to at work produced in Redmond ...
"There is something fishy in the Pacific Northwest, but it ain't Salmon"  ;D
Well, every system has its pros and cons.

Quote
However, the credulity of the video is stretched a bit by the claim that
"no animals" were harmed, despite Blaze, Sparky, and Little Smokey 'returning'
to their aquarium. I find it extremely hard to believe that those fish were not
harmed by having such horrible 'puny' names!!!

No objections, nothing to add on my part.  [tup]
Glad we seem to share the same kind of humour.

Quote
Obviously, HP has no concern for the mental cruelty to Animalia: Chordata: Pisces!!

Excellent biological classification, xairbus !
But then, HP has no concern for the mental cruelty to mankind either
given parts of their portfolio...

Quote from: Bull Winkus
Enjoyed the read on "why VMS chooses to treat the year 2000 as a leap year."
Best and most detailed explanation I've seen, so far.

I absolutely do agree. DIGITAL always delivered substantiated answers
to customer/user requests/complaints.
In another answer they explain why OpenVMS regards November 17, 1858 as
the beginning of time:
 
   The modified Julian date adopted by SAO (Smithsonian
   Astrophysical Observatory) for satellite tracking is Julian Day
   2400000, which turns out to be November 17, 1858.
 
   SAO started tracking satellites with an 8K (nonvirtual) 36-bit
   IBM 704 in 1957 when Sputnik went into orbit. The Julian
   day was 2435839 on January 1, 1957. This is 11225377 octal,
   which was too big to fit into an 18-bit field. With only 8K
   of memory, the 14 bits left over by keeping the Julian date
   in its own 36-bit word would have been wasted. They also
   needed the fraction of the current day (for which 18 bits gave
   enough accuracy), so it was decided to keep the number of
   days in the left 18 bits and the fraction of a day in the right
   18 bits of one word.
 
   Eighteen bits allows the truncated Julian day (the SAO day)
   to grow as large as 262143, which from November 17, 1858,
   allowed for 7 centuries. Possibly, the date could only grow as
   large as 131071 (using 17 bits), but this still covers 3 centuries
   and leaves the possibility of representing negative time. The
   1858 date preceded the oldest star catalogue in use at SAO,
   which also avoided having to use negative time in any of the
   satellite tracking calculations.


Quote from: elagache
Quote from: dfw_pilot
Seconds from the Epoch?
That is the UNIX standard and because of that we will have yet another Y2K mess in 2032. 

2032 ? Sure ?

I'd tend to believe it's 2038, since the Unix Epoch is a 32- or 64-bit value
(long-/quadword, eventually unsigned; best as time_t) containing the number of
seconds since 01-JAN-1970 00:00, UTC. When interpreted as signed and unsigned
longword values, the upper bound for the C epoch is 19-Jan-2038 03:14:07 GMT or
7-Feb-2106 06:28:15 GMT, respectively.

Time on VMS is a 64-bit (quadword, eight-byte, little-endian) value
containing the numbers of 100 nanosecond intervals since 17-NOV-1858 00:00 (local).
This value is updated every 1/100 sec and its usage is common across the VAX,
Alpha and I64 Integrity Itanium platforms.
This quadword format works up through 31-Jul-31086 02:48:05.47 GMT.

But what is the year 31086 worth if the command line interface/interpreter
only can cope with 4 digits for the year ?  [rolleyes2]
Well, I guess engineering will take care of that in about 7975 years  [runoff]

 Regards !
 
   Michel


xairbusdriver

  • Storm
  • *****
  • Posts: 2174
    • EW7115 (E7115)
    • KTNGERMA20
    • Mid-South Weather
  • Station Details: Davis VP2 wireless + remote Anemometer/2014 Mac min - 10.13.4/WC 3.0
Re: Longest computer up time?
« Reply #34 on: June 16, 2016, 04:41:26 PM »
Quote
I guess engineering will take care of that in about 7975 years
Sounds like you were in management!! [banghead]

"After all, 'programming' is really just typing. What's your problem?!" [rolleyes2] [rockon] [lol]

Quote
Glad we seem to share the same kind of humour.
At my age, a sense of humor is one of the few that still works! [rockon]

Bull Winkus

  • Storm
  • *****
  • Posts: 782
    • EW0095
    • KARHORSE2
    • WU for Horseshoe Bend, Arkansas
  • Station Details: Davis Wireless Vantage Pro 2, iMac 24"
Re: Longest computer up time?
« Reply #35 on: June 16, 2016, 07:13:14 PM »
Another good one for sure! "why OpenVMS regards November 17, 1858 as
the beginning of time:"

I glean from it that all of these original format decisions were tied to necessary compromises in order to get the most out of what is still a somewhat limited means of measuring something as nearly infinite as engineers have ever encountered. Not being a professional programmer though, I wonder, why must the tracking word be on the smallest division of time? Why track bottom up, when the key word could be in hours from the epoch with all smaller divisions derived from calculation? There must be a reason, and I'm willing to bet that you know it.  ;)

 [cheers1]
Herb

Michel

  • Gentle Breeze
  • **
  • Posts: 38
    • MichelsWunderland
  • Station Details: WH3080 - See website for details
Re: Longest computer up time?
« Reply #36 on: June 16, 2016, 10:24:11 PM »
Quote from: xairbusdriver
Quote
I guess engineering will take care of that in about 7975 years
Sounds like you were in management!! [banghead]
[lol]
You know I meant to play a silly joke (on management)  ;)

Quote
At my age, a sense of humor is one of the few that still works!
And I'm willing to bet you are doing quite well at all given your postings here.
Despite your age - at least I hope so !

Quote from: Bull Winkus
Not being a professional programmer though,

I'm one neither...

Quote
I wonder, why must the tracking word be on the smallest division of time?
Why track bottom up, when the key word could be in hours from the epoch with
all smaller divisions derived from calculation?
There must be a reason, and I'm willing to bet that you know it.  ;)

In fact, I never bothered. But there are quite a few aspects...

Much like the randomness associated with different sorts of random number
generation and thus different uses and varying risks, there can be different
uses for differing precisions and differing accuracies of time.

Basically the fine gradation of nanoseconds is needed for process handling,
synchronisation and related operations. So dividing hours on the fly would
be..um.. counterproductive :)

If you want to know why applications want or need higher precision or higher accuracy,
that varies (precision describes random errors, a measure of statistical variability,
while accuracy describes systematic errors, a measure of statistical bias).

A 1/100 second is quite some instructions on contemporary processors -- in terms
of raw speed, a hundred trillion instructions per second or more is theoretically
possible -- though it would have to be stupid-simple and cache-resident to sustain
anywhere near that rate -- with a current x86-64 CPU running some
stupid-simple-dumb-fast cache-based application. For comparison, the classic
VAX-11/780 ( https://en.wikipedia.org/wiki/VAX-11 ) supposedly did a million
instructions per second with its 5 MHz clock  -- if memory serves me correctly
(non pun intended ;-) , it probably did about half that, but the instructions supposedly
performed about the same work as an IBM mainframe running a million instructions.
Nowadays Itanium can waste the equivalent of ~15000 instructions for an alignment fault.
SSD I/O rates run the range to as many as one or even ten million IOPS. 
Network connections and data rates are vastly faster, too.

http://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

 Regards !

   Michel

elagache

  • Global Moderator
  • Storm
  • *****
  • Posts: 4968
    • DW3835
    • KCAORIND10
    • Canebas Weather
  • Station Details: Davis Vantage Pro-2, MacBook Pro (Early 2011), macOS 10.13.6, WeatherCat 3
Sorry typo (Re: Longest computer up time?)
« Reply #37 on: June 16, 2016, 11:01:35 PM »
Dear X-Air, Michel, Herb, and WeatherCat speed forum posters,

Quote from: elagache
That is the UNIX standard and because of that we will have yet another Y2K mess in 2032. 

2032 ? Sure ?

You are correct.  I was typing too quickly.  The Wikipedia link is correct and lists 2038 as the "witching hour."

Never enough time to deal with all these forums . . . .  :(

Edouard

Bull Winkus

  • Storm
  • *****
  • Posts: 782
    • EW0095
    • KARHORSE2
    • WU for Horseshoe Bend, Arkansas
  • Station Details: Davis Wireless Vantage Pro 2, iMac 24"
Re: Longest computer up time?
« Reply #38 on: June 17, 2016, 06:04:07 AM »
Well, thanks for your insight Michel! I feel considerably enlightened, even though I still don't know… so… much.

I understand the need for timing precision within computer operations. I just don't understand the necessity of counting centi-seconds from the beginning of an epoch to the end, when for the purpose of linking all of those centi-seconds to human time, an hour based count would do.

It probably has a lot to do with core legacy issues. Meaning, if it ain't broke, don't fix it!  [rockon]

 [cheers1]
Herb

Michel

  • Gentle Breeze
  • **
  • Posts: 38
    • MichelsWunderland
  • Station Details: WH3080 - See website for details
Re: Longest computer up time?
« Reply #39 on: June 17, 2016, 01:56:59 PM »
Quote from: Bull Winkus
I just don't understand the necessity of counting centi-seconds from the beginning of an epoch to the end,
when for the purpose of linking all of those centi-seconds to human time, an hour based count would do.

I'm not sure whether I do understand you correctly...
A sort of chicken/egg problem perhaps ?

There is no 'necessity' to count centi-seconds for presenting the user with
a time. The related routines simply make use of what is existent anyway
on a given system (because it's needed for other operations) instead of
'reinventing the wheel' by introducing a further hour-based mechanism which
would put additional (read: needless) load onto the processor, memory and
mass storage.

IOW, it's easier to both use and maintain existing mechanisms instead of adding
not really needed ones.

I'm still not sure I got your point...

  Michel


Bull Winkus

  • Storm
  • *****
  • Posts: 782
    • EW0095
    • KARHORSE2
    • WU for Horseshoe Bend, Arkansas
  • Station Details: Davis Wireless Vantage Pro 2, iMac 24"
Re: Longest computer up time?
« Reply #40 on: June 17, 2016, 10:36:43 PM »
I suppose I'm placing too much emphasis on a need for eliminating the epoch doomsday limit, or future Y2K like issues. Since doing so is possible, I feel like it should be done. But, that ignores the amount of effort that might be involved, which could be very substantial.

You see, initially upon discovery of the Y2K issue, I was aghast that the architects of DOS would overlook the issue of such a shortcut in linking a limited system clock to time management. I felt that it was short sighted. I still feel that any century based term limit of such foundational programming is short sighted, because eventually (even though perhaps not in the programmer's lifetime) dealing with the limit will create an enormous work load for the developer community.

It struck me, however, that for the purpose of time and date management rather than incrementing in centi-seconds for the extent of the limits of the size of the word (64 bit?), that the word could increment in hours or uptick every 360,000 centi-seconds. Or better yet, since processor cycles and memory availability is so abundant, perhaps a separate word could be created that would be incremented by the system clock word at 360,000 count intervals, that could be linked to by higher level language for interpretation of time and date and whose epoch would be measured in thousands of years. But, I think that to do that a second additional word would have to be used to count up to 360,000 before resetting for the purpose of offering programmers greater than 1 hour precision in their calculations without linking to the original system clock. … Whew! … That's all.

 [sweat2]

But, it's really an academic question. The current revision of the calendar has only been in force for 434 years, so perhaps the question is as relevant as staring into the reflecting pool while musing about appearance and observation.

 [cheers1]
Herb

Michel

  • Gentle Breeze
  • **
  • Posts: 38
    • MichelsWunderland
  • Station Details: WH3080 - See website for details
Re: Longest computer up time?
« Reply #41 on: June 17, 2016, 11:47:46 PM »
Quote from: Bull Winkus
I suppose I'm placing too much emphasis on a need for eliminating the epoch doomsday limit, or future Y2K like issues.


I don't think so. You are simply right this should be rectified.

Quote
You see, initially upon discovery of the Y2K issue, I was aghast that the architects of DOS would overlook the issue of such a shortcut in linking a limited system clock to time management.

Let's face it, 30 or 25 years ago computer and software manufacturers were fighting other fires...
Hence they didn't focus on things they weren't affected by directly. Unfortunately, this POV hasn't changed much  :(

Quote
I felt that it was short sighted.

Welcome to the club !

Quote
It struck me, however, that for the purpose of time and date management rather than incrementing in centi-seconds for the extent of the limits of the size of the word (64 bit?), that the word could increment in hours or uptick every 360,000 centi-seconds. Or better yet, since processor cycles and memory availability is so abundant, perhaps a separate word could be created that would be incremented by the system clock word at 360,000 count intervals, that could be linked to by higher level language for interpretation of time and date and whose epoch would be measured in thousands of years. But, I think that to do that a second additional word would have to be used to count up to 360,000 before resetting for the purpose of offering programmers greater than 1 hour precision in their calculations without linking to the original system clock. … Whew! … That's all.

I think I've got you now. Thanks for the comprehensive description.
That's an indeed interesting approach.

Quote
But, it's really an academic question.

I tend to agree - especially when the system clock sucks (again) in the more or less near future
due to the known *nix Epoch limitations, the extra hour-based time value being valid until the
year xxxxxx won't help...


Blicj11

  • Storm
  • *****
  • Posts: 2996
    • EW3808
    • KUTHEBER6
    • Timber Lakes Utah
  • Station Details: Davis Vantage Pro2 Plus | WeatherLinkIP™ Data Logger | iMac (late 2013), 3.5 GHz Intel Core i7, 24 GB RAM, macOS High Sierra | Sharx SCNC2900 Webcam | Supportive Wife
Re: Longest computer up time?
« Reply #42 on: June 18, 2016, 01:00:01 AM »
Wonderful, unique photo for your banner, Michel.
Blick


Bull Winkus

  • Storm
  • *****
  • Posts: 782
    • EW0095
    • KARHORSE2
    • WU for Horseshoe Bend, Arkansas
  • Station Details: Davis Wireless Vantage Pro 2, iMac 24"
Re: Longest computer up time?
« Reply #43 on: June 18, 2016, 03:42:08 AM »
Thanks for listening Michel. Glad I could get that off my chest!

 [lol2]
Herb

xairbusdriver

  • Storm
  • *****
  • Posts: 2174
    • EW7115 (E7115)
    • KTNGERMA20
    • Mid-South Weather
  • Station Details: Davis VP2 wireless + remote Anemometer/2014 Mac min - 10.13.4/WC 3.0
Re: Longest computer up time?
« Reply #44 on: January 19, 2017, 10:43:33 PM »
Software Up-Time: 52 days, 3 hrs, 33 mins
OS update in progress. Mainly for the Security update to catch the ‘Fruitfly’ malware. As long as there are these types of updates, I don't think Mac users will set any records! OTOH, keeping things updated, especially in the security realm, is more important, in my opinion, anyway.

BTW, I tried to post this some ~25 minutes ago, but could not make contact with 'athena.trixology.com'. I've had that problem occasionally, usually several weeks apart, must be a busy server on the 'island'? Or maybe it's Putin tapping into one of the underwater cables...