All posts by Bob Igo

I am human.
Science, Technology

The Awesome Task of Recoating a Telescope Mirror

Leave a comment

If you enjoy pretty pictures of the universe, you owe it to yourself to learn how a common bit of maintenance is done on ESO’s VLT, or Very Large Telescope.

At some point, the reflector used in the VLT is beyond recovery, and they need to strip it of its mirror finish and recoat it.  This seems like it would be straightforward, but some of the most impressive robotics, machinery, engineering, and minds are applied to this task.  If anyone involved in the process is having a bad day, and they break the ceramic mirror base, the telescope would be out of commission for years until a replacement mirror is built.

I’ve worked on multiple critical systems in my career, but I’ve never seen anything quite like this.

Uncategorized

Daphne, 1 Year Old

Leave a comment

Thanks to Lon, we were able to get some great pictures of Daphne wearing her traditional “Korean girls have to wear this dress when they’re 1 year old” dress.  I haven’t edited out the background yet, but I wanted to put one up sooner rather than later.  We have more, but this one is my favorite.  Click the picture for a larger version.

Daphne, in her traditional Korean dress
Technology

Additional Treadmilldesk Criterion

9 Comments

Before I purchased the treadmill for my treadmill desk, I thought my criteria would yield good results.  For the most part, this is true; I’ve been using my treadmill desk for well over a year without issue.

Recently, my treadmilldesk’s treadmill started making some grinding noises that corresponded to the belt speed.  Technology never heals itself, so I opened up the workings to take a look.  After the usual dust cleaning, I isolated the source of the noise.  An important piece of plastic had warped from heat.

The speed sensor consists of a tiny piece of circuitry that counts how often some teeth pass through it.  The teeth are on a wheel attached to the main treadmill motor.  The sensor is on a plastic housing that sits directly on the metal motor.  Guess what happens as the motor heats up?  Yes, the sensor housing softens and sags, leading to a condition where the teeth rub against the housing as they move.

Under the “normal” usage scenario, which consists of someone buying the treadmill, using it for a week, then putting plants on it until they sell it used, this piece of plastic would never distort.  However, if you actually intend to use your treadmill as a treadmilldesk, as I do, walking at 2.5MPH for 3-8 hours a day, you might want to consider getting a higher-end model that will last.

I will fix the sensor mount problem somehow, but when this treadmill finally does fail, the next one I get will be designed for long-term use.

Programming, Quality Assurance, Technology

Car Disaster Avoided

Leave a comment

As we continue to make software a component of more technologies, software failures are evolving from losing the last 20 minutes of your work to losing the rest of your life.  I was recently reminded of something that happened to me years ago, in which I encountered a potentially life-threatening software failure.

In the winter, about 10 years ago, I had a major software failure in my 1997 Saturn SC2.  I was living near the top of a steep hill, with a road to match.  My drive to work required me to descend this steep road, which hit a low point before rising up again to touch the main road.  If you could look at the road from its side, it would resemble a check mark, with my house near the top of the longer stroke.  Now picture the road covered with a fresh, wet, slippery snow.

I descended the hill in low gear, to take advantage of engine braking, but I also had my foot on the brake.  The action of the ABS brakes caused the usual pulsation in the brake pedal, along with the typical rattling sound, as it kept my speed down.  So far, so good.  Then, after a few seconds of constant ABS activity, I lost the brakes, as my dashboard lit up with red lights.

“Hmm,” I thought.  The low gear was helping to slow me down, but it could only do so much without brakes.  My steering still worked, so my plan was to drift down the hill and rely on the braking power of the incline between me and the main road.  This was the plan for several seconds, until someone pulled onto the road from an adjacent apartment complex.  They were heading to the main road, too, and they were in front of me.

“Hmm,” I thought again.  I couldn’t rely on the other car moving fast enough to not be in my way, so I had to come up with a plan B.  I quickly thought about the failure, running through various scenarios.  While I wasn’t certain, I suspected that I had encountered a software failure, and that the hardware (the brakes and the ABS controller) were fine.  Ultimately, I decided to reboot the car.

This was a little scary.  Power steering would go away while I did this, even if only for a few seconds.  I’d also never started my car while the wheels were in motion.  Out of an obscure memory, I pulled information my dad told me once: “You can start a car with automatic transmission in either Park or Neutral.”  Park was out of the question, but Neutral would work just fine.  So, I turned the key into the Off position, shifted to Neutral, and then turned the car back on.  After the usual brief test period for indicator lights, all the red lights were gone.  The brakes had resumed their clicking noise, and this time, they kept working.  After shifting into low gear, everything was back to where I wanted it to be.

I considered contacting Saturn about this, but I didn’t think it would lead to any improvements.  My mindset at the time was that unless I had a way to consistently cause this failure, the report wouldn’t be acted upon.  In fact, I only encountered that failure once during the time I owned the car.  If it happened to me now, I think I would contact Saturn and anyone else who had an interest in making sure cars are safe to drive.

If there’s any life lesson here, it’s that the Hitchhiker’s Guide to the Galaxy was right: Don’t panic!

Economy, Technology

Forwarding Bank Account

4 Comments

To the category of things I can imagine but not do, add this: A bank account that does not exist, but merely points to one that does.  Analogous to forwarding email addresses that do nothing other than forward to real email addresses, the forwarding bank account would solve the conundrum of what you do when you have all your bills auto-debited from a checking account, and then you decide to switch checking accounts.

The only way that I know to solve this currently involves allocating money in both your legacy and your new bill-paying checking account, and keeping the legacy account open until the last auto-debit is taken out of it.  It’s doable, but it’s tedious, and most companies generate at least one bill that you need to manually pay when you switch accounts on them.  With a forwarding account, you would not switch accounts, as far as your creditors were concerned, so auto-debit would be smooth even when switching your underlying real checking account to another bank.

Can anyone with inside knowledge of how routing numbers and account numbers are actually used in the auto-debit process comment?  Is this feasible, as the system currently works, or would the notion of a forwarding account need to be built in from the ground up?

Economy, Programming, Strategy

Powering Off Computers Can Waste Money

9 Comments

Sometimes, the policy-makers in businesses don’t think through the full consequences of their policies.  A recent tweet reminded me of one instance that appears to be fairly common, namely the company policy of powering off computers at the end of the day.  If you’re a developer who has to spend time every day recovering from the consequences of this policy, here are some calculations that might allow you to explain it to your company’s management in terms that they understand: money.

For many job types, powering off computers at the end of the day may be appropriate, but for developers who may have reference material opened in Firefox, an IDE with multiple open tabs, maybe a time tracking application, maybe an IM client for collaborating with developers outside the company, it costs time for the computer, the OS, and the apps to be in the same state that they were before the computer was powered off.  As developers are generally expensive, this loss of time can be viewed as a loss of money; you’re effectively paying your developers a higher hourly rate by building inefficiencies into their work process.

It’s understandable that the 16 hours between day end and day start are targeted in the interests of saving electricity, and the cost savings, while small as a percentage of any organization’s expenses, are easy to obtain.  But let’s do some calculations to see if it makes sense to turn off a developer’s computer at the end of the day.

Scenario #0

The baseline, Scenario #0, is 100 developers leaving their computers powered on, but idle, 365 days a year.  This costs electricity, but there is no impact to developer efficiency.  Consider the baseline cost as $baseline, where developers spend $0 of their salaries recovering state.  Any effort to save money will be compared with this state.  Most nontechnical people would assume that any possible solution involving powering off unused equipment would save money, which is why so many nontechnical people advocate the “power off” policy.

Scenario #1

Scenario #1 will test the premise that powering off computers at the end of the work day saves money.  I assume 100 developers shutting down their computers at the end of their work days.  This costs less electricity than the baseline, but there is an impact to developer efficiency.  Developers are assumed to work 250 days a year (50 weeks of work; 2 weeks of vacation; no working weekends).  (I know this will amuse some developers, but the potential cost savings of powering down a computer are directly proportional to the number of days a developer works; if anything, I’m giving the idea a better chance.)  250 work days a year means that computers are unused for 16 hours a day during those 250 days and 24 hours a day during the remaining 115 days, for a total of 6760 hours a year.

The worst-case scenario I could find for average commercial utility cost was $0.1949 per kWhr, and that’s in Hawaii.  So let’s use $0.20 per kWhr as the electricity cost.  In order to know how much money it costs to keep a computer idle and powered on when it’s not used, we need to know how much power a computer draws when idle.  My 3-year-old Core2 Duo laptop draws between 34W and 40W when idle.  Let’s think the worst and imagine a computer that draws 100W when idle, more than doubling my real-world example.  Such a computer would burn 676,000 Watt-hours (or 676 kWhrs) per year during its unused time, costing $135.20 per year for the portion of time in which it’s unused.  If it were powered off during that time, the total savings over 100 developers would be $13,520 per year.  Electricity cost in Scenario #1 would be $baseline – $13,520.

Let’s now consider the time involved.  The best-case scenario for a useful developer may be ~$30,000 per year, though higher is surely more likely (especially in Hawaii).  Let’s also figure that it takes 5 minutes, at best, to restore a powered-off computer to the state it was in before it was powered off.  During our developer’s 250 annual work days, they spend 5 minutes recovering system and software state.  This works out to ~20.83 hours a year.  At $~14.42 per hour, a business could consider that, while they’re not paying a developer anything extra, $300.41 per year of their salary goes toward state recovery.  In a company with 100 identical developers, this means that $30,041 per year is spent paying those 100 developers just to recover from their computers being powered off.  Comparing with the baseline cost, this scenario costs $baseline – $13,520 + $30,041, or $16,521 more than the baseline of leaving the computers on all the time.

The technical among you are already shouting at your screen.  What about suspend/hibernate options?  You can suspend a computer to RAM, meaning you put it in a state where it sips only enough power to listen to a wakeup call while keeping its state alive.  Scenario #2 considers what would happen if computers were put in a low-power state with fast recovery time, and Scenario #3 examines a no-power state with slower recovery time.

Scenario #2

My laptop suspends within 6 seconds, though the time cost does not factor in because I can just close the lid and walk away.  While suspended, it sips 1W of power.  It takes another 6 seconds to wake back up to its pre-suspend state.  Assuming more worst-case scenario math, let’s say that it really takes 12 seconds to recover and sips 2W of power while suspended.  If we re-use the other numbers above, the 100 computers in our fictional company would consume $270.40 in electricity per year when suspended making the electricity cost $baseline –  $13,520 + $270.40, or $13,249.60 less than baseline cost.  Likewise, our fictional company would pay their 100 developers $1200 to wait while their computer recovered state.  This would make scenario #2 cost $12,049.60 less than $baseline.

Scenario #3

My laptop takes 50 seconds to hibernate, though it’s not necessary to wait around for it to finish.  During hibernation, it uses exactly 0W of power to sustain state.  It takes 110 seconds to wake back up to its pre-suspended state.  Let’s make this worse and assume it really takes 5 minutes to recover.  (I won’t increase the power consumption because there never is any in this state; it’s always 0W unless you’re using a laptop and the battery is charging.)  Re-using the other numbers, the 100 computers in our fictional company would consume $0 in electricity per year when hibernating.  Our 100 developers would spend $30,041 of their time to wait for their computers to recover state.  Comparing the cost vs. the baseline, we have an electricity cost of $baseline – $13,520, and we have a developer cost of $30,041, which looks suspiciously like scenario #1 because 5 minutes of waiting for the computer to restore its state is equivalent to 5 minutes of developer time manually restoring its state.

I have simplified somewhat by not taking into account the time a powered-off computer takes to boot, either from a basic shutdown or from a state of hibernation, but if you extend my calculations to include that time, you’ll find that it merely amplifies my results or breaks ties in favor of state preservation.  Likewise, using more realistic values for developer cost and for power consumption amplify the results.

Final Thoughts

It is never a good idea to have developers lose state.  The best-case scenario is to suspend the state to RAM, and if your computers can’t do that, you need to make it happen.

Even with the highest electricity prices and unrealistically low developer salaries, the idea of abandoning computer state at the end of the day to save money does not work.  However, even the best scenarios for saving money, from any angle, are insignificant when considered against a company’s total income and expenses.  So why not just set a policy that improves workflow?

Costs, revisited

Scenario #0: $baseline

All computers left on 365 days a year, 24 hours a day

Developers spend no time saving/restoring state

Scenario #1: $baseline +  $16,521

All computers powered off 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 5 minutes a day restoring state manually

Scenario #2: $baseline – $12,049.60

All computers suspend state to RAM for 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 12 seconds a day waiting for state to restore automatically

Scenario #3: $baseline +  $16,521

All computers hibernate, saving state to disk, for 16 hours a day during workdays and 24 hours a day during weekends and vacation

Developers spend 5 minutes a day waiting for the computer to restore state automatically