July 09, 2004

What's the difference between 255 and 256?

If you answer "1" then you're not a computer engineer (or programmer).

The Hamsters are transmitting their little packets of data in perfect synchronization, mostly. Since size does matter when it comes to bulk data transfer, I've been trying to increase the packet size, albeit with little success. To be honest, that would be no success. Although I've optimized the hell out of all the timing, socket, and transmission unit parameters, my Hamsters choke as soon as I give them bigger packets to send.

Why? Why, Hamsters, when I've been so good to you?

Having run out of TCP documentation to mine for further clues, I decide to stare at the Hamster code for a while. Although staring blankly at code gives one (if one is sufficiently self-delusional) the sense of doing something, one can only take so much of this before one has to make trips to the water fountain, to the far end of the building to read Far Side comics taped to the doors of unoccupied offices, and to ferry one's crap out to the car.

Why would adding one word, two measly bytes, to a 256-word packet crash the Hamster?

To put off the inevitable return to the code, I sit on a picnic table in the shade and watch bees pollinate clover. I count no fewer than four bird's nests knocked out of the trees by the daily thunderstorms. The crepe myrtles bow beneath loads of pink flowers. The corn in the field over by the hangar is tall.

Why is there a cornfield on the grounds of an aerospace research facility? Why would increasing the maximum buffer index from 255 to 256 choke the Hamster? What's the difference between 255 and 256?

In hex, 255 is FF and 256 is 100. 255 is an eight bit number and 256 is a nine bit number. The dried flowers woven into the bird's nests are pretty. One of the nests doesn't have any flowers and I wonder if it was built by a bird of a different species. If the kids who wrote the original version of the interrupt service routine (the code that the Hamsters use to load data into the buffer that constitutes the packet) didn't consider that someone might want to increase the packet size, then they might have only used an eight bit register to hold that value when indexing data into the buffer. If that is the case, then that Most Significant ninth bit gets lost and the buffer never gets filled, because the first 256 locations (we start counting at zero so 0 to 255 is 256 locations) are written over and over.

Do you think that's sweet corn? If I pulled off an ear, would I get in trouble? It's probably not ripe yet. I'll try in August.

I return to my lab and read the interrupt service routine very carefully. Not only did the kids use an eight bit register, they included several extra lines of code to make goddamn certain that only an eight bit value could be used to represent the maximum buffer size. I rewrite the ISR and it is faster, simpler, and able to accommodate humongous packets. Ha! It—compile-time errors. Damn!—isn't quite working yet and it's time for me to hit the road. I grab the rest of my stuff and head out to my car. On the way, I figure out how to eliminate the compile-time errors and halve the number of instructions in the process. I keep going because traffic is murderous around here, but on Monday, when I get that bit of code up and running, the Hamsters shall rejoice. So shall I.

613 words | July 9, 2004 08:22 PM | Rocket science