Linux on test systems, pt 5

In July of 2007 I started reviewing app notes that Agilent published about using Linux on test systems. They've put out 5 papers on the subject (full list is here). This blog reviews #5, the last paper in the series.



Tips for Optimizing Test System Performance in Linux Soft Real-Time Applications


One of the first things the paper does is discuss the difference between soft real time applications and hard real time applications. To be honest, I didn't realize there was a noticeable distinction. But I found it referenced in Wikipedia, so it must be real... My experience with real time systems has been of both varieties, but I never quantized the difference. So, now I know something new.

One of the things I liked is the list of tips for optimizing response times. These tips aren't really specifically linked to Linux, and they seem obvious but sometimes it's good to see those "obvious" ideas listed.

■ Avoid it if you can
■ Put the burden of real-time control on your instruments
■ Use a fast PC with plenty of memory
■ Shut down unused services
■ Isolate the real-time part of your application

The author then goes on to discuss specific Linux techniques like time slices, the Linux scheduler, preemptive multitasking, and virtual memory & paging. Each of these discussions are paired with code, diagrams and graphs that dive into some technical details. Most of those details were admittedly beyond my skill level - I'm not a Linux guy - but the paper was written well enough for me to understand the subject matter.

----------------------

This is the last paper in the series, so I don't expect to blog much more on the subject, at least not until I install Linux on that computer at home. I'm still working heavy at my new job, so it may be another couple of weeks before my next post.

Starting A New Job

I’ve been with my latest job now for almost two months. In that time I’ve averaged about 1.5 emails a week and 1 phone call every two weeks with new job possibilities. Most of that activity I chalk up three items:

Ø I still have my resume listed on Monster.com. Many head hunters have programs that troll through piles of resumes and auto-generate emails if you match certain keywords. I’d say a third of the jobs I’ve seen were obviously not a fit for me, but my resume had the right keywords.

Ø I live in a fantastic technology environment. The greater Boston area. Yes, if you do pure software or web work, then the San Francisco Bay Area is probably better, but for cutting edge hardware work (electronics, optics, pharmaceuticals, MEMs) this area can’t be beat.

Ø Test Engineering is often a recession-proof career. We live in an imperfect world, so you always have to test your products. Coincidentally, US News & World Report had a special feature on good careers for a recession this week. Test engineering was not specifically mentioned, though engineering in general was listed.

I wrote those tidbits as a preface to my main point: what do you do before you start a new test engineering position? A couple of weeks ago I wrote about my list of things to do before I leave a position, so this list is complimentary to that. First impressions are important, and it always helps to start out on the right foot.


Familiarize yourself with the company
Yes, you already did this before you interviewed. You read their website, checked out their competitors, read their white papers, etc. Now it’s time to dig deeper. Read up on their technological practices, review the company’s history, and find information on how well their products work. Buy a book on the technology they use.

Project list
Email your new boss and see if you can get a list of what projects will be most important when you start. Having this list ahead of time will help you get a handle on what you can start doing the first couple weeks on the job when you need a break from filling out those new employee forms.

Equipment
Get a list of the current equipment they use. If you’ve used it before, then great. If not, download the manuals and start reading. Download the LabVIEW drivers for it. Find some example code using it.

People
Learn about who you'll be working with: Facebook, LinkedIn, or just google them. Knowing about their professional backgrounds (i.e. - papers they've written, patents they've filed, other companies they've worked at) helps you understand what they can do and, consequently, how you can fit in with them.

Linux on test systems, pt 4

In July of 2007 I started reviewing app notes that Agilent published about using Linux on test systems. They've put out 5 papers on the subject (full list is here). This blog reviews #4.


Using Linux to Control USB Instruments
As I have written before, I sometimes take a dim view of these white papers. It seems that their actual value is proportional to how much input comes from marketing - I just haven't determined if that proportion is direct, quadratic, or exponential. Maybe it depends on the company itself.

Having said that, when I started reading this latest paper I learned about the "USB Test and Measurement Class (USBTMC) specification," which I didn't know about prior to this. Any white paper that actually teaches me something must have something going for it. Plus the author provides sample code for create a generic USB driver that works with current Linux distributions - even better.

I should point out I haven't had a chance to test out this code. I have an older computer at home I am converting over to a Linux box, so I plan to do it at that time. But aside from that caveat, I think this paper was pretty well written.

----------------------

The remaining paper in the series is "Tips for Optimizing Test System Performance in Linux Soft Real-Time Applications." I'll review this one next week.

Linux on test systems, note

In July of 2007 I started reviewing app notes that Agilent published about using Linux on test systems. I reviewed the third of five back in November. In the past couple of months, while I was busy ending one job and starting another, Agilent went and published numbers four and five. So I'll review #4 this week and #5 in another week or two.

The full list of papers is here.

Leaving your job

Over the past 15+ years I've worked for a lot of different companies, 8 including the company I joined in January. I don't look at myself as a job hopper - I think that's just the nature of the tech marketplace in today's economy. With one exception, those jumps have been voluntary, and over time I've developed a list of things to always do before I even give notice. Below are the highlights of that list.

Clean your computer Y'know that collection of 200 albums you got from BitTorrent and now you listen to at work? Burn it to CD/DVD and delete it from the hard drive. The same goes for those pictures you took last year in Washington DC, chat logs that you've saved, and those blue-humor jokes your friends sent you.

Archive your contacts
I have hundreds of business contacts in my PDA from people I've worked with over the years. Sometimes that list comes in real handy. I have that list because I always make sure I download my list of contacts from Outlook (or whatever mail app your company uses) before I leave. I also make sure I have cell phone numbers & personal email addresses from people I want to keep in touch with afterwards.

Backup your work Burn a CD or two of what you've done at your company. I'm not advocating stealing company secrets, but most engineers will have collected a lot of stuff on their hard drive over time: PDF files of interesting papers & "how-to's"; PDF technical manuals; install files for useful utilities. Also, I see nothing wrong with copying LabVIEW subVIs (or portions of them) that you spent a lot of time figuring out how to make work. This represents your experience, and whether you copy it from work or just recreate it on your own at home, that knowledge is yours. I use subVIs at work that I originally wrote 2, 4 and even 10 years ago somewhere else.

The flip side to this is you shouldn't take someone else's work as your own, nor should you take entire projects and use that at a competitor. That's stealing, no matter how you rationalize it.

Transition your work
This is maybe the most important one. Some people may look at it as a "don't burn bridges" policy, but I also think of it as "don't screw your friends." Until the company hires someone to replace you, your previous coworkers will have to take up the slack. So make a list of your current projects and their status, list potential people who could take them over, and list things you do on a regular basis (i.e. - preventive maintenance on equipment, software backups, etc.)


---------------
4-19-2008
Postscript
I had a conversation the other day with someone about this post, and he pointed out a couple of things that could get people into trouble. So let me clarify.
Archive your contacts. This is a tricky subject. I've read online about senior sales guys who have been sued for bringing contacts with them that they made while being paid for doing that. Even worse, some of the business contacts you've made while on company time could legally be considered that company's property. So, tread carefully here. I am certainly not a lawyer, and the best advice I could give would be to do the ethical thing: If you consider the person a friend, it's reasonable to keep in touch with that person after you leave the company. If you only relate with that person on a business level, take care.

Backing up you work. Do NOT take stuff that could be considered company property. What I was referring to were - for example - PDF files of papers you found online, installation files of shareware programs you've downloaded, or sample code you found on a discussion board. BUT, if you take anything that was written by the company, or someone in the company, or paid for by the company, taking it might get you sued. Basically, if you couldn't have gotten it on your own time at home, don't touch it. If you're an engineer, some of that stuff you probably downloaded at home the night before & brought to work anyway.