Synthesis Studios

Last week, a new version of the Linux kernel was released. Amongst the speculations about how fast ARM chips and new spinlocks will change the world was the inclusion of a new networking protocol. Many people, including some big reviewers, have glazed over CAN as a simple protocol designed for industry. This does not give it justice. CAN is fundamentally different from the IEEE 802 protocols in that it addresses the data contained within the packet instead of the intended recipient.

By looking at these protocols from a different perspective you can see where many of the common communications ideas like handshaking and retransmission don’t fit.

Think about it for a minute. It’s a fundamental difference in transportation method. Imagine Ethernet as a phone call saying “This packet is for Aaron’s phone,” and CAN as a radio station saying “This packet contains Billy Joel.” By looking at these protocols from a different perspective you can see where many of the common communications ideas like handshaking and retransmission don’t fit. Just jumping into CAN with these notions can (sorry!) leave someone very confused and frustrated, like the kernel network maintainers.

CAN was designed by Robert Bosch GmbH in the late eighties for device communications in noisy environments. It is designed to disseminate information about the entire region covered by the network to every node in the network with little overhead. Consider a network that covers a car, a common use for CAN, you have many sensors and many devices that wish to talk to each other. In a connection oriented network, this would involve much overhead; everyone who is interested in the status of the ABS system would have to either ask the ABS how it’s doing or hope the ABS speaks up. This is especially time-consuming in an emergency situation. In a pre-crash situation, many devices are going to need to know about the ABS’s activity in a short amount of time. This problem gets even worse when there are many devices all looking for several pieces of data.

CAN has a very clever way of arbitrating who gets to talk on the network. Carrier Sense Multiple Access with Bitwise Arbitration (CSMA/BA) allows the devices to pick who will transmit next just by saying their ID. This makes it especially important to pick the IDs of the data properly. You want a tire pressure monitor’s warnings to supersede the status of the rear defroster in an emergency. By allowing higher priority data to block the transmission of lower priority data a CAN network does have the possibility for a lower priority node to get starved of transmission time.

I hope these point help anyone who reads this to realize that CAN is not a direct replacement for Ethernet, even if the powers that be decided to add some hacks (like ISO-TP) to let you use it in that manner. Hopefully its inclusion in the Linux kernel will cause more communities (i.e. sensor networks and home automation) to pay attention to what network protocols they are using and why.

This is a surprisingly difficult question to answer. The standard advice is just to store everything as milliseconds since the epoch (January 1st, 1970) in UTC, but this breaks down as soon as you need to show a time to a person or get one from them.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong.

When it comes to human concepts of time, most naive assumptions about turn out to be wrong:

• not every day has 24 hours (e.g. March 11, 2007 and November 4, 2007 — in most of the United States, at least)
• some times never occur (e.g. 2:30 am on March 11, 2007)
• some times occur twice (e.g. 2:30 am on November 4, 2007)

If you go further back in time, things get even worse:

• entire days don’t exist (October 5 to 14, 1582 in Spain, Portugal, and most of Italy)
• the calendars of different countries may be days or weeks apart, and change depending on the year, as illustrated in this quote from Vladimir Nabokov (born in Russia):

All dates are given in the New Style: we lagged twelve days behind the rest of the civilized world in the nineteenth century, and thirteen in the beginning of the twentieth. By the Old Style I was born on April 10, at daybreak, in the last year of the last century, and that was (if I could have been whisked across the border at once) April 22 in, say, Germany; but since all my birthdays were celebrated, with diminishing pomp, in the twentieth century, everybody, including myself, upon being shifted by revolution and expatriation from the Julian calendar to the Gregorian, used to add thirteen, instead of twelve days to the 10th of April. The error is serious. What is to be done? I find “April 23″ under “birth date” in my most recent passport, which is also the birth date of Shakespeare, my nephew Vladimir Sikorski, Shirley Temple and Hazel Brown (who, moreover, shares my passport). This, then, is the problem. Calculatory ineptitude prevents me from trying to solve it. [Speak, Memory, 1951]

Every time must be associated with a place, in the form of a time zone.

To handle time correctly, keep in mind one basic rule: every time must be associated with a place, in the form of a time zone.

(This advice may have a familiar ring to readers of Joel on Software’s The Absolute Minimum Every Software Developer Absolutely, Positively Must Know About Unicode and Character Sets (No Excuses!) and its admonition that “It does not make sense to have a string without knowing what encoding it uses.

In addition, you need a historical database of the time-related legislation in each of these places. These basic requirements pose problems for many popular development platforms: for example, neither Flash/Flex nor Javascript have a proper notion of a time zone. Instead, they treat all times as in either the local time zone or UTC - if you want to schedule a meeting elsewhere in the world, or if your server happens to be in a different time zone than your browser, you’re in trouble.

Fortunately, many platforms (e.g. Linux, Windows, Java) do include a time zone database and a way to associate time zones with a time. The APIs are not always particularly clean (.NET has a TimeZone class that you shouldn’t use; the Java Date class has approximately five times as many deprecated as non-deprecated methods), but they work. Given a number of milliseconds since the epoch, a time zone, and a format, you can show the right text to the person using your software. You can even let them input a date and time (but be careful - which 2:30 am on November 4th do they mean?).

If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight.

Things get trickier when you start dealing with concepts that are less precise than a specific instant in time. If a person wants to wake up at 7 am, you can’t just set the alarm to go off seven hours after midnight: it’ll only be six on the day that Daylight Savings Time starts and eight when it ends. If someone wants to see all sales that happened on Christmas Day, 2007, you have to know if they mean December 25th in their time zone, or the one in which the sale occurred (and furthermore, you need to store your data in a way that makes the appropriate query efficient). You can’t make any assumptions about the future either. Laws change; Daylight Savings Time is enacted, repealed, shifted; your time zone database needs to be kept up-to-date or your software will end up like the alarm system in our office - its time is off by an hour for a few weeks every Spring and Fall.

All of which is to say that handling time is harder than it seems. But if you keep the basic principle in mind, and code carefully, you should be able to figure out what time it is.