I'm seeing a pattern. All you guys so far reporting these 1 y uptimes seem to've been running KA's. Must have been a good batch of transistors.
--
[Specific learning difficulties:]
>Rolling resistance for a [80 kph] bike with average tyres is [...] 2.2 kW.
>On a bike with rider in tuck position air resistance with no wind
>is something like .4 * v^3 Watts [...] 4.3 kW.
** For Christ's sake - go learn some basic physics, dickhead.
The drag experienced by the solar car or a cyclist is almost entirely due to
AIR resistance.
And that is not a linear function of speed.
-- "[NPD?] Phil Allison" , 9 Jan 2011 13:28 +1100
We have had a couple of electrical brownouts/disconnections for maintenance work over those years, but the server is an old Dell laptop, so the battery works as a built-in UPS.
Terje
--
-
"almost all programming can be viewed as an exercise in caching"
I once worked on a Univac that had a jump indirect bit. When it got into a jump loop stopping it was interesting.
First option was to hit the Stop button. It ran to the end of the current instruction which meant that it kept running.
Second option was to power down which meant that it did an save state at the end of the current fetch cycle and restore the current state on power up. No joy.
Third option hit stop button and ground the a wire from the instruction register to the console forcing it to think it was decoding a different instruction on the next indirect jump in the loop.
You go away for a couple of days and return inside a time machine. Or a rest home.
I remember a big dispute between the customer and FS concerning UC Berkeley's PDP 6. The customer wanted PM time counted as downtime and FD didn't. Memory margins and oiling the teletype. The good old days.
I sent a famous service request to Prime sometime in 1987, complaining that the uptime counter; incrementing 330 times a second, wrapped around in it's
32 bit container after 150 or so days.
They framed the complaint and put it on the wall.
Modern, well designed servers don't have many problems. You have to do the occasional upgrade and reboot as part of meintenence, but the MTBF of single servers are around 5 years. More, if you go for redundancy everywhere and hot-swap parts.
OS crashes in Linux, BSD etc from LTS releases that happen except for hardware issues are also very rare.
That must have been the uptime for an entire VAX cluster. Individual machines could have been booted several times, but at least one machine has been running all the time.
To upgrade the OS on the VAX cluster, take one machine off the cluster, upgrade that machine to the next version and then join the cluster. Repeat for the other machines.
In the cluster the machines could have OS version separated by one step, thus several cycles of this rolling updates had to be made, if a large number of versions is needed to upgrade at once.
On Tue, 11 Jan 2011 11:17:33 -0500, Walter Banks wrote: [...]
Our APL timesharing system ran on an IBM 370/155. Since it did cause its share of OS failures, the timesharing system support group tended to be called first when OS/360 MVT hung. One day the system operator called us in to find out why nothing was working and we were astounded to see that hitting the STOP button had no visible effect.
The 370/155 was one of the last of the IBM mainframes that still had one of those huge Panel-o-Lamps display panels, and normally they would display (e.g.) the current instruction address and the perhaps the status of various data buses in what appeered to be fairly random patterns. Not this time -- they were _pulsing_, and in _groups_, like some sort of Holywood special effect. This, added to the suddenly non-operational STOP button, gave us a _very_ strange feeling for a few moments. Then someone hit SYSTEM RESET, the other "stop" button, and the machine finally stopped.
On the 370/155 all instructions were multiples of two bytes long,
16-bit "halfwords" in IBM-speak. It seems that somehow the Program Check New PSW, the pointer that got loaded when some random instruction tried to (e.g.) divide by zero, had been overwritten and had an odd address in it.
The next time a Program Check exception occurred the 370/155, following its carefully-programmed microcode instructions, loaded its Machine Check New PSW. Immediately -- before the instruction _at_ that address was loaded -- the odd address was recognized as a Program Check condition, and the Program Check New PSW was loaded. Immediately -- before the instruction _at_ that address...
In other words, the machine was caught in a microcode loop less than one S/370 instruction long, and apparently the microcode test for the STOP button had been left out of that loop.
Ah, I miss Das Blinkenlights...
We now return you to your previous discussion.
Frank McKenney
--
`It's all about bossing computers around. Users have to say
"Please". Programmers get to say "Do what I want NOW or the
hard disk gets it".'
-- Richard Heathfield on the nature of programming
I remember the strange feeling with the first home brew computer I built that did not have a blinking light and switches console. I was convinced that it would never be able to run or debug anything.
The feeling went away soon enough.
I could still key in the boot code on a pdp11 with my eye's closed.
That would depend on how hard it was to get access to the initial peripherals!
I once had a Fortran compiler for testing that had no I/O support. No input, no output and no file access. I did check that it used Fortran 77 DO-loop semantics and told the salesman it was useless. When I had explained why, he then asked "Other than that, what did you think of it?"
I suspect that being faced with a peripheral-free CPU would be very comparable :-)
Dunno, but I know how I did - being a mad hacker from way back, as you know :-) I used a ternary output mechanism: it stopped normally, it crashed horribly, or it looped forever.
What debugger? :-)
But, without any peripherals, how do you connect it? :-)
Nice try, but no banana. It used a C-incompatible calling sequence, and there was no assembler. I baulked at creating object decks using the available tools - such as ed and cat - especially with no specification.
I said "useless" and I meant just that! That's what I told the salesdroid, too.
And what does the BIOS do with no peripherals? Contemplate its own magnificence?
Seriously. Frank McKenney was talking about a generation of systems before you could assume that everything comes with a more-or-less functional run-time executive (which is what a BIOS is). What I was talking about was the sort of embedded system where the BIOS IS the application, and how you start loading it. Think hearing aids, not PCs in a box.
In a microcomputer environment, so long as you had access to the BIOS and could call an assembly language routine (or even a machine language routine, if necessary), then what the language did or did not support didn't matter. What the BIOS and/or OS supported did (and still does).
I faced a number of odd situations using Fortran in microprocessor environments in which the compiler did not support the necessary I/O correctly. I eventually stopped using native Fortran I/O so that I could use my own uniform interface on different platforms. All I had to change was my own I/O library.
Saying that the language does not natively support the necessary I/O is different from having a peripheral-free CPU. Hard [to get access to peripherals, in this case] and impossible are not the same. That's the essence of non-trivial engineering.
I remember about 30 years two DEC engineers[1] went to Norway and the railroad ran on a dual PDP-11/70 system, where the code was wrong so did not run in failsafe, so needed both systems running. Field Service had to guess which part to change shut down the whole network to try a change then bring the whole lot back up.
They went to fix so serial driven colour graphics systems, for mimic displays and had to cross marshalling yards, go up the stairs in a signalling tower, past the banks of Victorian relays still working after 100 years, but the embedded systems running the graphics were needing fixing after less than 3 months.
[1] When I worked at the division of DEC in UK and got the stories from the engineers who went to Norway.
--
Paul Carpenter | paul@pcserviceselectronics.co.uk
PC Services
Timing Diagram Font
GNU H8 - compiler & Renesas H8/H8S/H8 Tiny
For those web sites you hate
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.