Speak Embedded

We recently had a very eye opening experience while helping a customer with a problem. They were having issues with our ATS1936 and TM1936-SFP+ in their engineering lab.  Their ATCA nodes and external nodes would link to the ATS1936, the ATS1936 reported the links as up, but they could not get traffic to pass between the nodes.  We checked spanning-tree settings.  We checked port physical settings.  We checked various other switch settings.  We checked SFP+ module numbers.  We checked fiber cable types.  We checked E-Keying settings.  We ran various tests and we could not find anything wrong.  It was getting frustrating.  We were close to issuing an RMA and then we remembered the Zeroth Law of Debugging.

Zeroth Law of Debugging: Never assume anything.

or

Zeroth Law of Debugging (rephrased): Verify all of your assumptions.

I call it the Zeroth Law of Debugging because it is just like the Zeroth Law of Thermodynamics.  It is the most fundamential rule of any list of ‘laws’ for debugging.   Debugging itself could be defined as making a list of assumptions and verifying them.

What is the most basic assumption of a layer 2 switch?  What is something you would rarely check? What is absolutely required for a layer 2 switch to connect two nodes?  Do you think you have figured it out?  Well if you answered unique MAC addresses you solved this problem.

Obviously, all nodes need unique MAC addresses and would have unique MAC addresses in the field, but this is testing in a engineering lab with prototype nodes.  The MAC addresses were the same on all the nodes.  The only way we figure it out was when we simplified the test down to just 2 nodes pinging each other.  The customer saw the particular behavior of ping working from node A to node B or node B to node A but not both at the same time.  That set off a red flag and we quickly figured it out from there once we verified our most basic assumption.

Every once in a while problems like this come up to remind you that not all issues are hard to fix.  As long as you keep the Zeroth Law of Debugging in mind, most (all?) product issues can be solved.

JP Landry
Network Division Manager

From Light Reading’s Valley Wonk blog:

Heavy Reading is predicting the ATCA market will reach $7.2 billion by 2012.
…
Stanley is counting application-ready ATCA systems — that is, the value of the type of system Alcatel-Lucent or Nortel Networks Ltd. would buy. Other studies, he says, have counted up the total end value of ATCA systems, measuring the products AlcaLu or Nortel would sell.

This is the same guy as my last post on this subject. $7.12 billion is a good bit less than $20 billion but is probably a more realistic number. $7.12 billion sounds like a strong market to me. Let’s hope Stanley’s analysis is accurate.

JP Landry
Network Product Manager

and fools seldom differ.

While Doug and I are colleagues, we do not interact much. We work at different locations in different departments on different things. I can probably count on one hand how many times I’ve actually talked to Doug and our interaction via email or other impersonal mediums is rare. That is why it intriguing that 1) Doug wrote about a book in general, which I planned to do today, and 2) he mentioned Gödel, Escher, and Bach which I started reading just yesterday. Maybe this coincidence even fits in with Doug’s argument somehow, but I’ll leave the philosophy up to Doug.

I can here to post about Dreaming in Code by Scott Rosenberg. While I’m an avid reader, I’ll somewhat ashamedly admit that I mostly read SciFi/Fantasy. When I was at the book store a week ago I decided to try something new and ended up with Dreaming in Code. I couldn’t be happier with my choice and maybe it will lead me into being nonfiction junky now. That is at least a little bit better than SciFi/Fantasy junky according to my wife. Like Doug I’m not here to write a book report, but rather to recommend Dreaming in Code. While at face value the subject matter of the book is a large software project that didn’t go anywhere, or at least hasn’t gone anywhere yet after many years of development, the underlying subject is about software development in general. Rosenberg does a wonderful job mixing the Chandler team’s struggles with discussions on why software development is hard and what people have tried to do about it.

An old software engineering buddy of mine used to love to point out the numerous articles that said “Software is hard”, or his favorite “Hardware is easy. Software is hard” because I was a hardware guy at the time. While I never doubted that software is hard, as I’ve become more and more involved in software development at DTI I have seen it first hand how difficult software development can be. I can empathize with some of the Chandler team’s difficulties and it is somehow comforting to hear that the entire industry has some of the same problems. Reading Dreaming in Code feels like having a beer with the guys after work. Sure discussing, theorizing, complaining, etc. about your projects usually doesn’t make them easier, but don’t you feel better afterwards?

JP Landry
Network Product Manager

Light reading has an ATCA analysis that is spot on. The ATCA market is not as big as initially (erroneously?) projected, but it is far from dead. Simon makes a good point that ATCA has something to prove in the next year and I believe that will happen. ATCA is a more attractive platform that ever with 10Gb Ethernet in the backplane. As requirements for 10Gb Ethernet increase, ATCA adoption rates will increase. Many companies will be looking for new platforms as their legacy platforms cannot handle 10Gb signaling rates.

JP Landry
Network Program Manager