"You take a million, billion tonnes of flaming inferno and turn it into 'twinkle, twinkle little star' ..."

Fri, 23 Mar 2007

Preparing for Daylight Savings Time

While computers mostly handle the Daylight Savings Time changeover automatically, sometimes work is required. In our case at ICHEC, arranging for some jobs to run at set times, means changing the scheduler at the changeover.

We use PBS and Maui to schedule what jobs run when on our cluster. Mostly jobs get run according to priorities: the scheduler (software) decides which what the priority jobs are and when; it collects free nodes until it has sufficient free CPUs to run the jobs at hand. It can do backfilling: when it's e.g. trying to run a large 128 node job but has only 10 nodes free, it will reserve nodes as they become free until it has all the resources needed to run the job. If by looking at the remaining time left on running jobs it realises that it won't get nodes free for the large job for say 2 hours, it can run small jobs with runtimes of less than two hours on the nodes it had reserved. Clever.

The fun issue comes when you need to set reservations: say you need to run a job at 2am every day on 32 nodes, as we do: the scheduler needs to plan accordingly. The scheduler needs to really have 32 nodes free at that time.

Thats 2am local time, of course: but next Sunday, at 2am, the clock changes...

So, working out the consequences, and preparing for the change, I sympathise with our American friends who've moved three weeks early to save energy. Thus causing lots of midnight oil to be burned around the world by sysadmins and programmers updating software. Hmmm.

Note to Self:

When Posting a blog entry asking for help on getting blog comments to work with openid, try leaving the comments setup on the blog working, so people can leave replies. Fixed now.

Time change for the Energy Policy Act of 2005 had very little affect on the servers hosted at my work place. My only complaint stems from the pricetag that MS assigned to the update for business customers. This made it both harder to get the appropriate updates and expensive for many. It was an easy buck for MS and I have yet to see any proof that the time zone changes will have any real affect on energy consumption. I am lucky that in Debian I didn't have to do squat. Timezone information was updated automagically using apt and off I went. Boo MS, Hooray Debian.

Thanks for supporting OpenID. I needed to test the WordPress OpenID plugin. :-)
Yes, Maui is not very smart when it comes to time: if at 10am you schedule a reservation for 2am, it tries to backdate a reservation, rather than set one for the following morning. If its concept  of 'day' is that week, daylight savings time is totally beyond it.

It case it wasn't clear, the problem we had to address is that, if at 1am it has to  schedule jobs on a machine that needs to be free at 4am for a particular task, its not smart enough to realise that tonight in particular, there are only 2 hours between 1 and 4am. If it schedules a 3 hr job to run in that slot, the job wont complete in time for the priority job to run at 4am.
Followup: According to arstechnica.com Changing the Daylight Savings Time in the U.S. Saved no power.

A popular move, but in the end, a complete flop.

Post a Comment

Name: 
Your email address: 
Your website: 
 
Comment: