Skip to main content

Did ND get any better in 2008?

With all the talk about the potential firing of Charlie Weis (which ultimately didn't happen) I thought I would ask this question: did the Irish improve substantially between 2007 and 2008?

The most obvious way to answer this is to use the computer polls. I chose the Colley Matrix, which is part of the BCS formula, since it has a characteristic that makes comparing teams year-to-year straightforward. All teams in this computer poll are inherently normalized to a rating of 0.5, which makes comparisons year-to-year much more valid.

Here's what it looks like (pre-bowl games for both years):

YearRankingRatingRecordStrength of ScheduleSchedule RankBest win
2008580.5296-60.53344#45 NAVY
2007900.3753-90.60410#46 UCLA

First off, it is clear that the team was much better this year. The rating differential of 0.154 is the same as the differential between 2008 Ohio State and 2008 Cal - clearly a big step forward.

Secondly, the "weak schedule" of 2008 turned out to be not-so-weak: it was a lot tougher than the 86th-ranked "mighty SEC" schedule played by Alabama, for example. Tougher than 6 of the top 10 teams in 2008 in fact.

Yes, the team still looked inept at times. And the loss to Syracuse was frankly unforgivable. But there were also many bright spots in 2008 as well. Michael Floyd and Golden Tate are going to be one of the best WR tandems in the country next year. The defense improved. Claussen looked better. Special teams looked better, with even Brandon Walker finishing the year strong.

In the end, I'm glad Charlie is staying for another year. The last thing ND needs is to hit the reset button on the program without having locked up a great successor. Willingham was fired because Urban Meyer was on the market, and ND failed to land him, so we have Weis. There is no Urban Meyer out there this year. Until there is a can't-miss candidate available, and it is clear that he will actually take the ND job, Weis is the better option.


Popular posts from this blog

Fixing slow NFS performance between VMware and Windows 2008 R2

I've seen hundreds of reports of slow NFS performance between VMware ESX/ESXi and Windows Server 2008 (with or without R2) out there on the internet, mixed in with a few reports of it performing fabulously.
We use the storage on our big Windows file servers periodically for one-off dev/test VMware virutal machines, and have  been struggling with this quite a bit recently. It used to be fast. Now it was very slow, like less than 3 MB/s for a copy of a VMDK. It made no sense.
We chased a lot of ideas. Started with the Windows and WMware logs of course, but nothing significant showed up. The Windows Server performance counters showed low CPU utilization and queue depth, low disk queue depth, less than 1 ms average IO service time, and a paltry 30 Mbps network utilization on bonded GbE links.
So where was the bottleneck? I ran across this Microsoft article about slow NFS performance when user name mapping wasn't set up, but it only seemed to apply to Windows 2003. Surely the patch me…

Google's public NTP servers?

I was struggling with finding a good set of low-ping NTP servers for use as upstream sources in the office. Using is great and all, but the rotating DNS entries aren't fabulous for Windows NTP clients (or really any NTP software except the reference ntpd implementation).

ntpd resolves a server hostname to an IP once at startup, and then sticks with that IP forever. Most other NTP clients honor DNS TTLs, and will follow the rotation of addresses returned by This means Windows NTP client using the built-in Windows Time Service will actually be trying to sync to a moving set of target servers when pointed at a source. Fine for most client, but not great for servers trying to maintain stable timing for security and logging purposes.

I stumbled across this link referencing Google's ntp servers at hostname time[1-4] These servers support IPv4 and IPv6, and seem to be anycast just like Google's public DNS servers at time…

Presets versus quality in x264 encoding

I'm scoping a project that will require re-encoding a large training video library into HTML5 and Flash-compatible formats. As of today, this means using H.264-based video for best compatability and quality (although WebM might become an option in a year or two).
The open source x264 is widely considered the state of the art in H.264 encoders. Given the large amount of source video we need to convert as part of the project, finding the optimal trade-off between encoding speed and quality with x264-based encoders (x264 itself, FFmpeg, MEencoder, HandBrake, etc.) is important.
So I created a 720p video comprised of several popular video test sequences concatenated together. All of these sequences are from lossless original sources, so we are not re-compressing the artifacts of another video codec. The sequences are designed to torture video codecs: scenes include splashing water, flames, slow pans, detailed backgrounds and fast motion. I did several two-pass 2500 kbps encodings using …