Parsing SGE’s qacct dates

Recently I was trying to reconstruct a customer’s SGE job queue to understand why our cluster autoscaling wasn’t working quite right. The best way I found was to dump the output of qacct and grep for {qsub,start,end}_time. Several things made this unpleasant. First, the output is not de-duplicated on job id. Jobs that span multiple hosts get listed multiple times. Another thing is that the dates are in a nearly-but-not-quite “normal” format. For example: “Tue Mar 18 13:00:08 2014”.

What can you do with that? Not a whole lot. It’s not a format that spreadsheets will readily treat as a date, so if you want to do spreadsheety things, you’re forced to either manually enter them or write a shell function to do it for you:

function qacct2excel { echo "=`date -f '%a %b %d %T %Y' -j \"$1\"  +%s`/(60*60*24)+\"1/1/1970\"";

The above works on OS X because it uses a non-GNU date command. On Linux, you’ll need a different set of arguments, which I haven’t bothered to figure out. It’s still not awesome, but it’s slightly less tedious this way. At some point, I might write a parser that does what I want qacct to do, instead of what it does.

It’s entirely possible that there’s a better way to do this. The man page didn’t seem to have any helpful suggestions, though. I hate to say “SGE sucks” because I know very little about it. What I do know is that it’s hard to find good material for learning about SGE. At least HTCondor has thorough documentation and tutorials from HTCondor Week posted online. Perhaps one of these days I’ll learn more about SGE so I can determine whether it sucks or not.

Fun with birthdays

Sometimes I get distracted by shiny trivia. Shortly before St. Patrick’s Day, I noticed that seven of my Facebook friends happened to celebrate their birth on that holiday. That seemed surprisingly high, so I went through and counted up the birthdays for all 459 of my Facebook friends who have their birthday listed. The results are interesting. I don’t know if they’re meaningful or not.

As you can see from the I-should-have-made-it-larger chart above, any given day is most likely to be the birthday of one of my Facebook friends. It is slightly less likely to be the birthday of none of my friends. That was the most surprising result: I would never have expected that 108 days a year are empty when there are 459 birthdays to go around.

St. Patrick’s Day is the most frequently-birthed day with seven, although June 4 has six. According to the New York Times, those are the 134th and 146th most common birthdays. The most common birthday for those born between 1973 and 1999 is September 16, yet none of my Facebook friends claim that day.

May and December are the most common months for my friends, both with 52 birthdays. January is the least common with 25, though February and November each have 26. February gets some credit for being the shortest month, but it is still among the three months with less than one birthday per day. January does claim the longest stretch of birthday-less days, with eight.

How about days of the month? The 31st has the highest average, due to the 5s contributed by March and May (interestingly, these are the only two days with 5 birthdays). In second place, is the 22nd, which has the highest total count at 24. The lowest is on the 20th, which only has 6 birthdays. Two days before and after are in the 20s, so it’s a notable dip.

The full spreadsheet is available in Google Drive if you want to make your own observations.

Considering Bloom’s taxonomy in staffing decisions

A while back, an exam question introduced me to a taxonomy developed by educational psychologist Benjamin Bloom. In researching this work, I was immediately struck by how useful it could be when making decisions about technical staff. Bloom’s taxonomy is composed of three domains. The cognitive domain includes six hierarchical levels (from lowest to highest):

  • Knowledge
  • Comprehension
  • Application
  • Analysis
  • Synthesis
  • Evaluation

Applying these levels can help guide the interview process and provide a measure of a candidate’s abilities. With many technical jobs, though, it’s preferable to ignore the knowledge level. “Knowledge” in this context refers to memorized facts. Some interviews, especially phone screens, tend toward being entirely focused around the knowledge level. Even interviews that are based around programming exercises potentially overemphasize recitation over application. It is far too easy for a nervous interviewee to underperform on memorized facts. In real-world tasks, references are available for facts.

Once a person is hired, they need to be assigned work. If tasks are rated at the level they require, they can be matched to people at the required level. Tracking a person’s task levels can be beneficial as well. Giving someone tasks lower than they’re capable of will erode morale over time (and is a waste of resources), but someone who never gets lower level tasks could probably use a break. By the same token, giving people the occasional higher-level task gives them growth opportunities but too many can cause undue stress. If employees largely self-select tasks, a drop in level can be a warning sign of wider problems.

Of course, such applications are not new. Bloom’s taxonomy, by its very inclusion in an IT project management exam, is clearly not newly applied. It’s just interesting to me that a taxonomy developed for education some 60 years ago could fit technology staffing so well. If it’s new to me, then it’s probably new to someone else, too.

Thoughts on the Weather Forecasting Improvement Act

Insurance Journal reported last week on a bill sponsored by Representative Jim Bridenstine (R-Oklahoma). In a fit of poor reporting, the author says the bill makes the “protection of people and property a priority.” Unfortunately, the National Weather Service mission statement has included “protection of life and property” for years. The bill itself contains no such insulting verbiage. On the surface, it’s actually a welcome relief: a Congressman looking to direct over half a billion dollars of new funding to scientific research and operations. In reality, it strikes me as more of a pipe dream.

The average tornado warning lead time is currently around 13 minutes. The goal of Bridenstine’s bill is a lead time of 60 minutes or more. Stretch goals are good, but a 4x increase is not, perhaps, the most appropriate for legislation. Even so, there’s a question of how valuable such an increase would really be. Increased protection of property is probably not going to be that dramatic with hour-long lead times. It’s not like people can move their houses and businesses out of the way. Some damage could be prevented by securing loose objects and boarding windows, but it’s not likely to be significant.

Protecting life is the more important aspect, but would a one-hour lead time help? I’ve argued for years that there’s definitely an upper bound to lead times after which the returns diminish. My suspicion is that as the lead time grows beyond that point, people become more and more complacent. This argument has been based on hunches and unsubstantiated reasoning. It turns out, there’s evidence that increased lead time has no impact on injuries from tornadoes.

Even if the benefits are minimal, the amount of learning that would have to take place to get lead times up to an hour would aid our understanding of severe weather. The improvements to observation networks and modeling would benefit all areas of weather forecasting. Even  if tornado warning lead times remain unchanged, the scientific impact of this bill would be dramatic. I just worry that it’s setting the National Weather Service up for “failure”.