Faking Better-Than-Millisecond-Resolution with a QTimer

If you’ve ever used a QTimer you may know that they have a maximum time resolution of ~1 millisecond, and that they’re fairly inaccurate (even on a Linux box). Here’s how I got a little bit better performance out of a QTimer while retaining its ease of implementation and Qt-ness.

I was working on a project that needed to send UDP packets over the network at a rate of 114 Hz. That’s one message every ~8.77193 ms. QTimer’s setInterval() method, though, only accepts an integer millisecond parameter. Connecting a SendMessage() slot to the timer’s timeout signal on a 9 ms interval would mean I was only sending messages at a rate of ~111 Hz. Neglecting three messages per second seemed bad.

Being as in love with Qt’s Signals & Slots as I am, I didn’t want to abandon the simple brevity of QTimer’s timeout signal. Nor did I want to delve into possibly subclassing that object. My solution (erm, maybe workaround) is described below.

I created a QTimer with an interval of 8 ms. I connected the timeout signal of this timer to a slot brilliantly named SendMessage(). The timer starts. After about 8 ms, the timeout signal is emitted and the SendMessage() slot is entered. Then! At the beginning of SendMessage() I stop the timer. Before I actually send the UDP packet, though, I enter a tight while loop. In this loop I make use of Linux’s gettimeofday(2) function, where I compare the delta between a very high-res current time and the exact time I last sent a message with my 8.77193 figure. When I’m close, I leave the loop, send the message, record the current high-resolution time, and restart my QTimer. Phew. And then do that ad infinitum.

That while-loop is still holding up the thread, but it’s only for less than a millisecond per call to SendMessage(). The performance I saw was much better than using a QTimer with a 9 ms timeout. Most of the time deltas were coming out to 8.772 ms–over a large sample, about 2.5% of the deltas were more than 100 microseconds off the mark. I was effectively seeing messages transferred 113.999 Hz.

But wait–2.5% of 114 Hz being sent at the wrong time is pretty close to three per second. Which is equal to how many messages I was neglecting by simply using a QTimer with a 9 ms timeout interval.

The messages would only be sent late, though, if the QTimer timed out longer than 8.772 ms after the previous timeout (which happens sometimes, a testament to QTimer’s inaccuracy at this scale). So while a message might be late, it wouldn’t typically affect when the next message would be sent.

Consider this: a message is sent late. For ease of explanation I’ll say it’s the first message. It’s sent at 9 ms into the run instead of 8.772 ms. At this time, too, the QTimer is started, and ~8 ms later, SendMessage() is entered again. Now we’re at 17 ms into the run. The second message should be sent at 17.544 ms into the run (8.772 + 8.772), so we have about 500 microseconds of buffer time. This means that, on average, about 3 of the messages per second are sent at the incorrect time, but they’re still sent.

Our packet headers have indexes, so I think this will be copacetic. If I needed any more accuracy than this I would probably start looking for a solution without QTimers :,( and would probably have to turn on CPU shielding.

Don’t Call Me at Work

Today I was sitting in the lab doing some computer stuff. The phone rings. The sound gets filtered out–the phone has rung hundreds of times and was never for me.

My supervisor picks it up: “Matt, it’s for you.”

Not knowing what to expect, I take the call.

“Hi, Matthew! My name is Something Sometherson! I’m a technical recruiter with–”

“I’m not interested,” I say. And then quickly, “How did you get this number?”

This tech recruiter had found me on LinkedIn and then looked up the phone number of my current employer. Really? Even if I had been interested in whatever she was hawking (I didn’t stay on the line long enough to find out), I’d have been pretty put-off by her calling my office.

Please don’t call me at work, especially if it’s to discuss other job opportunities.

Girl Develop It

Last night I volunteered at the Philadelphia chapter of Girl Develop It. GDI offers low-cost programming classes for women. One of my former co-workers who’s involved with GDI shared that they were looking for an extra TA, and I thought it would be a good opportunity to meet people in the local tech world and to hang out for a couple hours near the edge of my comfort zone.

The meetup I was TA-ing was Intro to the Command Line. I feel proficient enough at the command line (since I use RedHawk Linux every day at work) that I thought I’d be useful as a TA.

The class was a little over two hours. From the meetup description:

In this course, we will cover the basics of using a terminal to control *nix operating systems. In addition, you will also learn how to use it to manipulate such things as the filesystem, the built-in help commands, file contents, program I/O, and remote systems.

I answered the participants’ questions and enjoyed helping out. I’d probably go back if they asked me or if there were another class for which I felt particularly apt to volunteer. None of my close friends are computery, so it was nice meeting people outside of work who are interested in software development.

It was also refreshing to see women wanting to learn how to program. I don’t view women being underrepresented in STEM fields as a problem, as long as it’s by choice, but at the same time I’m kind of biased in thinking that software development is cool and girls might be missing out. I like what GDI is doing. The meetups are affordable (< $15/hr), and one can take the classes à la carte. If GDI is teaching people who otherwise wouldn’t have an affordable/comfortable/accessible forum to learn about development, well, that’s pretty nice.

There is No Right Way to Develop Software

There is no “right” way to develop software. I repeat: THERE IS NO RIGHT WAY TODEVELOP SOFTWARE. Some people in our industry like to cargo cult and don’t want to believe this. They believe that the sweet new hotness they learned a couple of hours ago is the only way to make things work and build reliable pieces of engineering.

Source

Sick Day

Woke up before dawn this morning with heartburn, a headache, and a lot of congestion. I guess I have a cold. I didn’t really want to call (read: email) out of work, because it’s Friday, which meant I would be missing the weekly software meeting. This week the SW group was reviewing and discussing the Google C++ Style Guide as part of a recent effort to improve process and communication.

Also on the meeting’s docket was going over the first chapter of a book called Effective C++. The book is broken into 55 smaller “items”, each one dealing with a small and specific concept in C++. I was looking forward to what some people at the office have been calling “Book Club”, but, alas, too sick to work.

Maybe that’s not totally true–I could’ve popped some ibuprofen, driven to the office, and tried to stem the flow of nose-leakage for nine hours. But I really wanted to just stay in bed, and so I emailed my boss to give him the news. I rationalized this decision by acknowledging that even if I had gone to work, I probably would’ve been only slightly better than useless, and I would also run the risk of getting somebody else sick. If I were to infect a principal engineer with my cold, and he then had to take a sick day…well, that would be far more expensive for the company. So, you see, it was really in my employer’s best interest that I stayed home to enjoy the amazing weather nurse a cold.