quote:

Originally posted by RogueJSK:

quote:

Originally posted by bendable:
should we be doing something on this 9 y.o. computer?

Depends. Are you the kind of person who shuts down their computer after using it, and it remains off until you need to use it again? Or do you leave your computer running 24/7?

If you leave your computer running 24/7, you should be restarting it daily, or at least every few days.

But if you only turn it on when you need it, and then shut it down afterwards, you're already achieving that same effect.

Well damn, mine's been up for 116 days so far.

Guess I'm overdue.

I suspect it'll go a while longer yet.

As mentioned, consumer level items have cheap components that often "glitch out" and a reboot fixes. Another problem is excess heat that can cause devices to act up. I saw network devices stacked on top of each other all the time and a lot of heat often built up that way. One time I found a network router in a home under a bed on shag carpeting LOL.

Real Cisco products like their Catalyst line are expensive but they really worked well especially when they had a quality UPS /line conditioner.

I will say I have been very pleased with my Apple Airport Extreme I bought 3 years ago as it rarely gives me a problem.

quote:

Originally posted by sigmonkey:
Back in my Netware days, I picked up a new client who needed a printer installed. Did a site visit. They walked me to a "mop closet" and in the back corner, covered in dust and cobwebs, was a server with a small monitor and keyboard resting on end against the side of the server. Picked it up and pressed the Shift key and the monitor came up, orange text.

Netware 2 and uptime 964 days. It was a "record" for me, so I wrote in in my notebook.


Netware Netware 2.15/uptime 964 days.
286/4MB RAM
2 each 210MB drives mirrored.
126MB free.

They had the server about 5 years, and replaced it about 6 months later with Netware 4 and Windows for Workgroups 3.11 desktops.

Great story. You didn't bounce it before it hit 1000 days, did you? I'm reminded of George Castanza and the Frogger machine.

When I was still working at Novell, a story circulated about an organization that had lost one of its servers. Not that it had quit working, but that they couldn't physically locate it. It was on the network, but lost. Anyway, they traced wire and found that it had been enclosed in a dead space during a remodel. After busting it out, they found that the up time was nearly eight years. IIRC, it was a 386 running Netware 3. Its amazing that it hadn't had a hardware failure in all that time. I wish I had saved the details of that story.

The idea that devices need to be restarted to keep working is a result of the ubiquitous Microsoft takeover of the 1990's. Windows 95 memory-leaked so bad that frequent restarts were absolutely necessary. It doesn't have to be that way, though. High quality software running on high quality hardware can have very long up-time. The Mac in my office hasn't been restarted in over a year, and it just keeps plugging along. The last restart was to install a new SSD.

I must admit that my computer at work, a newish Dell laptop running Windows 10, has proven to be very stable. It hasn't been restarted in a month. Windows has come a long way since the 90's, that's for sure.

Back in my IT days, probably around 2012 or so, I worked for a guy who was the best boss I've ever had, and probably the best I ever will. Don prided himself on doing things the right way and trying to run an Enterprise grade department at a small college that was sometimes less than "Enterprise". He'd been with the school a long time (35+ years), had worked his way up from technician to department head, and during his tenure there had been plenty of times where funds had been tight and he had to make do without the "Enterprise grade" solution that he wanted. Every now and then Id discover one of these long-forgotten solutions, and hilarity would ensue.

One day Don called me into his office and told me he hadn't been getting his weekly long-distance billing report from the phone system. I made my way over to the PBX room to see what was going on, and discovered that the old Gateway 386, which I knew to be somehow involved in reporting but in my 5 years there I'd never had to touch, was down.

So I started looking at this thing, and it appeared it wasn't getting power. I traced it back to the wall, and discovered it was plugged into a lamp timer. Turns out, this thing was set up to start every time power was restored, and Don had put it on a lamp timer to reboot every night. It would boot into a dos program he'd written to query the PBX then send a report to him of all long-distance calls made that day. Every night the lamp timer would cycle the power and the process would repeat.

It kept doing this without fail, until that fateful day when the power supply finally gave up the ghost. I was struggling with how to accomplish the reporting using current hardware (which was going to be a pain because the thing was using a serial connection and replacing it with something that would interface with new hardware would likely involve a complete rewrite of the script), when an idea dawned on me. Rick, the head of our academic IT programs, had a closet full of old junk that Don had been grouching at him for years to get rid of. I went digging through Rick's closet, and found an old Gateway with the same power supply, replaced the bad one, and hooked everything back up to the lamp timer. It worked just fine like that for another 3 years until we implemented a VOIP system and the PBX went away for good .

 
At my first job in IT, our company had two Class C IP address ranges assigned by our ISP. Internally, we used them as separate networks, with a router in between (no firewalls then, all machines live on the Internet). The internal router was a very old desktop (one of the flat ones), running DOS and a HAM radio program called KA9Q, the benefit of which was that KA9Q had a TCP/IP stack so could be configured to route. The machine was on the floor of the server room in a corner, and occasionally would hang, obviously causing communications stoppage between the two networks. The solution was to go touch one's toe to the reset button on the front of the machine, which was called "kicking the router". The newbies were taught the "process" and assigned to go kick the router when the issue arose.

The other good things that happen in power-cycling, in addition to cleaning out memory leaks in RAM are that when power is first applied, most systems do a self-check, reinitialize the on-board systems (CPU, RAM, chipset, stuff connected to the motherboard, etc.), and reload all the driver software, which usually then re-initializes all connected peripherals. (One of the first tech companies I worked did PC-BIOS work...had a blast there.)

So you start off with a clean slate. It's not always necessary, but it is a good thing and when you are seeing surprising behavior, it's a great first thing to try (may work, doesn't take long and doesn't cost anything.)

Programs may or may not have been tested in a messy, arbitrarily complicated environment with 152 processes active (just checked my PC) and RAM and virtual memory all fragmented, but it's a very good bet they were tested and debugged in a clean-slate environment.

There's really no practical downside these days to powering off when inactive - the tradeoff is that it takes time to power back on, especially if there are HDDs. With SSDs, a cold boot can be pretty swift.

quote:

Originally posted by Nismo:

quote:

Originally posted by kz1000:
Because Sanjay at the tech support call center says so...

I always get a Thomas or a George.

On Tuesday his name is Thomas, Thursday it's George...