« September 2007 | Main | November 2007 »

October 27, 2007

1394 DMA Multiplexing sneak preview

Today I got a new, highly demanding piece of code working in our drivers. What it does is to receive streaming video from multiple 1394 cameras using a single DMA context on the 1394 adapter. Up till now each camera would have its dedicated DMA context. Since there are only four of those on most 1394 adapters, you could only receive 4 camera video streams per adapter. If you needed more you had to install a second 1394 adapter, etc.

DMA Multiplexing was a feature that we have been talking about for years in Unibrain. It would always get pushed back in the schedule since it was considered a "complex" item. Finally we did it. Of course there is more dirty work to get done, but the tricky part is over, and the important result is that the multiplexing DMA context can really handle some serious load without flinching.

I know some people like sneak technology previews so here is a photo of one of my test PCs displaying 6 cameras using a single DMA context:

Img_5789_2

If you zoom on the actual 5MP picture (1.5MB download), low on the right side you can see the 1394 bus topology, consisting of two PCs (nodes 0 and 9), six cameras, 1 repeater (node 1) and 1 analyzer (node 3). The monitor is on the blue node (node 0).
CPU usage (37%) is pretty decent for a slightly dated single CPU system.

Of course there is no way you can verify, just by looking at the photo, that all six video streams are on a single DMA context. You'll have to trust me on that :-)

Have fun!

October 25, 2007

Programmer DNA

Today I came across a very interesting article about why it is hard to program, with which I wholeheartedly agree.
Joel talked about student's inability to understand C pointers some time ago in his article about interviewing. Leave alone recursion or concurrency.

Here's what I think:

  • Not everyone can become a good++ programmer.
  • It's not a matter of practice or study alone.
  • It's a matter of having some crucial abilities or not having them.

I don't think it's arrogant to claim the above.
It holds for programming in the same way it holds for many other demanding professions.

Could I ever become a weight lifter just by trying?
I wasn't built for that. No matter how many steroids I inject, I won't ever be able to bench press 150kg.

Could I ever become a successful composer? I can't recall from memory any 5 minute song, how could I ever come to compose music?

Could I ever become a mathematics professor? Although I like math, theorems and equations don't ring in my ears, they are not my native instruction set.

This is the best analogy I can come up with. Each of us has a native instruction set, embedded in our DNA. Activities that are compatible with this instruction set can be carried out with the highest degree of efficiency. Other activities less so. Some activities might be seriously incompatible, causing serious degradation in overall performance.

Back to programming. If programmers had professional licenses like doctors do, then I know a couple of people whose license should be immediately revoked. Irrevocably revoked. Programming is not their brain's native instruction set; not in their DNA. They don't really understand what they are designing and what they are implementing. How it will behave, how it will perform, how it will be tested, how it will need to evolve and expand, etc.

No, I am not being harsh here. Some say there is an extremely high demand for software developers, so not everyone has to be that good.

WRONG. DEAD WRONG.

In my previous job I spent around 40% of my time bug fixing or completely redesigning and rewriting code written by people whose programming license should be revoked. What good did it do that these people worked for the company? The company paid their time plus 40% of mine for a work that could be done in less than 40% of my time, had I done it myself from the beginning.

That's why I insist on having top programmers on my team.

Have fun!

October 19, 2007

Undefined Behavior (NMI quiz - Part 2)

It has been some time since my last Tom & Jerry dialog.

Jerry: Hey Tom, could you help me out here? I am kind of confused...
Tom: Sure thing Jerry! I'd be glad.
Jerry: Do you happen to know what "Undefined Behavior" is?
Tom: Well, isn't it when the results of an operation are unpredictable?
Jerry: I know, but isn't that a definition for this kind of behavior?
Tom: Uhmmm, I guess so...
Jerry: So, you have just defined "undefined behavior".
Tom: Uhmmm, I guess so...
Jerry: So, what's undefined about it, since you just defined it?
Tom: I hate it when you do that! Leave me alone!

Undefined Behavior is a funny term, a misnomer if I am allowed to say.
If you ask me, there is NO such thing as "Undefined Behavior"
Even random behavior is not undefined. It is defined as random.

Instead, there is behavior undefined BY someone.

If you read about Undefined Behavior on WikiPedia you will notice the following in the first paragraph:

... the specification leaves the results of certain operations specifically undefined.

It is the specification that does not define the result of the operations, so implementations are free to do what they feel like, plus tell no one about it (if you are required to document it then it is implementation-defined).

What does all this have to do with NMIs? Well, by now it should be evident.

The NMI I got bitten by last month was caused by "Undefined Behavior", as described someplace inside the OHCI 1.1 specification.

In my case, up to that point in time, the undefined behavior our code was stepping on was not undefined at all. It was perfectly stable and correct behavior. But one day, given the proper hardware combination, it decided to flip and do an NMI instead. Cool, but still perfectly defined :-)

So to answer the quiz, yes, it was once again the software's fault :-)

Have fun!

October 17, 2007

Stupid dialog boxes

To be on not to be?
To OK or to Cancel?

Stupic_ok_cancel_dialog_2

This dialog is shown by Visual Studio 2005.

Have fun!

October 14, 2007

NMI quiz - Part 1

NMI errors are a form of fatal error that users don't encounter as often as the infamous Blue Screen of Death (BSOD). Here's what an NMI error looks like:

Nmi

Not as much information as in a BSOD. The user is given no real information about what happened. The most often seen NMI is the Memory Parity Error.

Now, here is a common sense quiz for common computer users:

  • You have a piece of driver software that works on all IEEE-1394 OHCI adapters (FireWire), on thousands of different machines, on all versions of Windows (Win2K to Vista).
  • HP produces a new server machine. If you use a specific 1394 adapter on this specific machine then you get an NMI error when the drivers load. All other 1394 adapters work without problems on this HP machine.

Who do you think is to blame?

  1. The HP hardware. All adapters work on all other machines, so there is something wrong with this machine.
  2. The 1394 adapter. There must be a bug in the adapter hardware.
  3. The driver software. Obviously there is some bug in the device driver.

Here's a hint to what I think.

Have fun!

October 10, 2007

I am a movie star!

Yes indeed I am! The last few weeks I have been starring in an exciting action series that will rock the software community. Here is a first draft of the logo (please don't mock me for my poor image editing abilities; I am only a soon-to-be-world-famous movie star):

Thousands_of_lives_are_at_stake

Releasing software is tough.
Releasing software that may render your clients' applications unusable is tougher.
Releasing software that may also crash the operating system is even tougher.
If you try to do it without proper testing procedures then you become an action movie star ;-)

Have fun!

Physics of the iPod awarded Nobel Prize

Oh dear... While driving to work this morning I listened on the radio... "Physics Nobel Prize goes to iPod and the technology used in hard disks".

After missing several heartbeats and recovering from massive brain damage I managed to arrive at work, where one of my emails had a link to Physics of the iPod.

I guess there must be numerous similar articles on this subject today. Even Reuters could not resist: iPod Technology Behind Nobel Prize for Physics. "iPod technology" ... Oh my...

God have mercy on us!!! What has iPod got to do with a discovery made back in 1988? Why should it share some of the glory and fame of a Physics Nobel Prize? I guess I don't have to explain that part...

Of course the text in the articles usually make it clear that iPod only USES the technology, but the headline remains blatantly incorrect. There are some media that do a much more decent job.

Have fun!