October 26, 2004
@ 02:29 PM

At a friend's company, a network hub has been dying a horrible and slow (literally) death until this morning when it got replaced. Of course, they are asking how a networking device like that, without moving parts can start to produce random errors, become gradually slower and sporadically just outright stop working for a little while and then be fine again. Given that after my mostly unsuccessful and expensive attempts to do anything with hardware, a buddy of mine once said "if there is ever a robot invasion from outer space, we'll send Clemens and he'll kill them singlehandedly", that's an excellent question for which I have no good answer, but only a theory: bit erosion!

I suspect that they (our friends) have unhealthily balanced data that has substantially more "1"s than "0"s. Now, when you look at "1" vs. "0", you'll immediately know what I mean. "1" is a lot more edgy and when you send "1"s through a data bus or through a cable, it's pretty obvious that every "1" will scratch along the sides here and there. If you have balanced data, the "0" (round and smooth) will usually polish it all out and while the data bus shows a little bit of wear and tear over time, it usually works well for many, many Exabytes. Now, if you have many more "1"s go down the data bus than "0"s, the bus gets all scratchy from the inside, actual potholes develop and subsequently "1"s start to get stuck. When they get stuck, "0"s bump into them, other "1"s slip past (probably even through a "0"!) and it's all getting really messy. And when you look at it all on a few levels higher up, you start losing packets and stuff gets slow and in the end everybody is unhappy and blames it on the software. The only cure for the problem that I can think of is to do data balancing that ensures a proper proportional flow of "1"s and "0"s. I think that's a totally plausible explanation and cries out loud for software that fixes this problem. ;-)

Tuesday, October 26, 2004 10:27:16 PM UTC
"a proper proportional flow of "1"s and "0"s"

Why send those wear-and-tear-inducing 1s at all? Surely it can't be beyond our collective expertise to design protocols that consist entirely of 0s?

This is made more urgent by the popularity of HTML and XML, as all those nasty sharp angle brackets must do really terrible damage...
Wednesday, October 27, 2004 12:32:49 PM UTC

The solution is simple. You just have to make sure all your traffic uses encryption (ssh, ipsec, etc), that way you get nicely balanced 1's and 0's.. for network environments where this is not applicable, you have to pipe /dev/random in at off-peak hours (it's also usually easier to explain this to your stubborn sysadmins)
Viktor Szathmary
Thursday, October 28, 2004 10:12:30 AM UTC
Actually the problem is exacerbated by a little-known fact: Ones are heavier than Zeroes. If the data pattern is such that the Ones are packed together at one end of a memory chip, while the zeroes are packed at the other end, mechanical stresses can be introduced that may actually fracture the chip and cause data errors.
nwells
Friday, October 29, 2004 12:58:13 AM UTC
But all this stuff will not be a problem any more. The latest philosophy theories, from MIT Researchers, pointed out that the the whole point of using 0/1 is not "using the values of a bit", but instead "using two nice characters, different from each other".

This is why the next generation buses/cables will not work with 0/1 anymore. They will use 0/O (ZERO vs. LETTER "O") instead, so that cables will not be ruined by those nasty "1"s.

Moreover, having only round data passed through the channel will also improve che transfer speed - it is fairly OBVIOUS that "O"s will roll at higher speed than "1"s... :-P
Saturday, October 30, 2004 2:18:14 AM UTC
'1's tend to fall over over time. Eventually the hardware can't tell the difference between the bent '1's and real '0's. That's why octal systems that use '8's and '0's work better - the '8's don't fall over!
Chris
Sunday, November 07, 2004 1:49:49 AM UTC
Thanks for the humor Clemens!

http://blog.magenic.com/seans/archive/2004/11/06.aspx
Comments are closed.