Imagine a spaceship, one light-year in length.  Assume it’s built in such a way that it magically has zero ability to compress or flex.  Humans are in the front, and engines are in the back.

If the engines turn on, I know that it takes one year from the perspective of the crew until they could see the light from the engines.  Obviously, the vibrations from the engines would take much much longer.

What I don’t know is when the humans would notice motion.  If the motion was bound by the speed of light, then it would take them one year to notice that they were moving.  But based on my rudimentary physics knowledge, this doesn’t seem to make sense.  I never heard of any physics that made the head of an object move long after the tail was pushed.

Luckily, Pete saved me from a series of sleepless nights in which I half-wondered if I’d derived some form of really clunky FTL communication technology.  His response was so thorough and informative that I wanted to share it with the world.  Well, the subset of the world who reads my blog.

The speed of light is not just a limit for light transmission, but for all interactions. From a particle viewpoint, interactions are mediated by particles. In the case of electromagnetism, this particle is the photon, which moves of course at the speed of light. The mediator particles for other types of interactions are also limited by the speed of light. Generally, massless particles travel at the speed of light, and all others are limited by it (but can never reach it.)

The macroscopic effects of what you described, aside from any resulting motion, might be called material stress or a material shock wave.

With regard to the humans in the front, not only is there no instant notification of what’s happening in the back, there can be no effect at all for 1 year. That is, no stresses, no motion, no nothing.

So what you’re thinking right now is, well then how can I conserve momentum? If the engines are spewing things out backwards, the center of mass of the spaceship taken as a whole must be moving the other way to balance that. In fact, there is momentum produced in the other direction (as there must be), and if you found a way to calculate precisely the center of mass motion of the spaceship as a whole you’d find it to be moving, but it is in the form of either material deformation in the rear, or microscopic dynamics that on a macroscopic level could be described by a type of wave in the material which can be associated with an overall macroscopic momentum.

In this context, an analogy between the spaceship material and fluid medium might be useful. If you’re in the middle of the lake and row your boat, the boat goes one way, and the momentum is balance by the motion within the water. The water at the edge of the lake doesn’t know anything about it until the waves you’re making reach there. If you were to calculate the momentum of all the water molecules at once and add them all together, you’d find that it cancels out the momentum of your boat. You can think of the momentum of your engine exhaust being balanced by the momentum associated with the shock wave traveling forward through the material of your spaceship.

You might not believe that the effects of the engines could be absorbed entirely by material waves with no macroscopic motion. This is because the scale of your spaceship is rather extreme. If you made the spaceship too rigid and not large enough width-wise, and the engines were too powerful, then the rear of your spaceship would just bust apart. If you imaged that the spaceship was a borglike cube of solid iron 1 light year per side, then you can start to believe that the engine thrust could be “absorbed” by wave disturbances within the material.

The apparent paradox in your thought experiment is due to the false assumption that you can make something that’s completely rigid. This is not physically possible. On a logical level, your thought experiment itself, combined with the speed of light restriction, proves this. On a microscopic level, you can make arguments regarding microscopic interactions as I did above for why 100% rigidity is not possible.

This reminds me of a special relativity problem I used to give my students that is related in one respect, but otherwise different:

Imagine a garage that’s 20 ft long, and a pole vaulter with a 30 ft pole that can run really fast into the garage.  As you may know, things that are moving get contracted in length. This is not because they are being compressed or anything like that – it is a result of the nature of space time.

Suppose the vaulter runs so fast that in the rest frame of the garage the pole is only 20 ft long. (He would have to run really really fast to get that kind of effect.) Then he would be able to fit the pole inside the garage, and you could close the door quickly and the entire pole would be contained in the garage undamaged for a split second until everything hits the back wall with massive destruction ensuing.

So that’s all well and good, but what about the rest frame of the vaulter? In that frame, the pole is still 30 ft. To make matters worse, the garage, which is in this frame speeding towards the vaulter, is contracted to only 10 ft. So in that frame when the front of the pole hits the back wall, there’s still 20 ft of pole outside the garage.

I was actually aware of the pole-vaulter example, but I hadn’t considered how it applied to my own thought experiment.  Physics is filled with such awesome stuff like this.  Thanks, Pete!

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.

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.

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!

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?

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