My .cshrc

Aside from a bunch of environment variable settings and shortcuts to oft-used directories, I’m collecting in my .cshrc file some little aliases.

Here are a handful of my favorites:

# so meta
alias cshrc 'vi ~/.cshrc' 		

# note-taking is v important
alias notes 'vi ~/documents/notes.txt'	

# this one just makes me think I never do typos
alias sl ls				

# display directory contents after cd-ing (stolen from Wikipedia)
alias cd 'cd \!* && ls' 		

# yes I'm this lazy
alias status 'svn status' 		

# so v lazy
alias update 'svn update' 		

# makefiles woooo
alias build 'make clean ; make all'	

# only show warnings/errors
alias buildquiet 'make clean > /dev/null ; make all > /dev/null' 

# always show line numbers w/ grep results
alias grep 'grep -n'			

# teleport to a server (esp cool w/ PKA)
alias servername 'ssh -X username@servername' 

# resets the terminal. god i love a clean terminal window
alias r 'tput reset' 			

# new terminal window
alias term 'gnome-terminal &'		

# shut down the computer
alias goodnight	'sudo /sbin/shutdown -h -P -time "now"'

Running in Real-Time

In C/C++, you can make a process run on a specified CPU and set its priority.

#include <sched.h></code>

// set CPU affinity so we can only run on CPU 7
cpu_set_t mask;
CPU_ZERO(&mask);
CPU_SET(7, &mask);
sched_setaffinity(0, sizeof(mask), &mask); // 0 here means set the affinity of this PID

// set real-time process priority and first-in, first-out policy
struct sched_param params;
params.sched_priority = 50; // higher number = higher priority
sched_setscheduler(0, SCHED_FIFO, &params);

I did more testing on the code I wrote yesterday, and found that running my utility with an entire real-time system was impacting my performance. I used the code above to make my utility run on a dedicated CPU and with real-time priority. This resulted in good performance–I found that messages were being sent late only about .5% of the time–which is acceptable for this application since the requirements specify approximately a rate of 114 Hz.

Read more about sched_setaffinity and sched_setscheduler.

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.