I had a backup. Really.

Things to look for in a gigabit switch

Several customers have been moving to gigabit Ethernet switches to run traffic around inside their networks, and I've been setting up MRTG monitoring of them. Virtually all networking devices implement SNMP's interface MIB, and they provide byte counters for each interface in both directions. Defined in the ifTable tree, ifInOctets.1 is the number of bytes received on port 1, and ifOutOctets.1 is the outgoing count. These counters are unsigned 32-bit integers, and the values are typically collected every five minutes: the difference between the two counters is taken and divided by the interval (300 seconds), yielding an average bandwidth during that period.

But difficulties arise as the speeds increase: a 32-bit counter is just not big enough to hold 5 minutes worth of traffic at speeds much above 100 mbit/sec. Though MRTG can deal with wraparound through zero, they cannot deal with full wraparound of a 32-bit counter - the data is simply lost. One needs to poll the device around twice per minute to monitor full gigabit speeds.

The solution is to use 64-bit counters instead; they have dramatically higher range and would take more than 4000 years to overflow even at full gigabit speeds. These are defined in a different part of the tree, in ifXTable, with several "HC" - High Capacity - counters that largely parallel the similar entries in ifTable. We'd expect to find ifHCInOctets.n and ifHCOutOctets.n here.

But Dell's Power Connect 5324 24-port managed gigabit switch simply doesn't support these 64-bit counters. I didn't see them when doing an snmpwalk, and because I just couldn't believe that a $1000 switch supported only 32-bit counters, so I must have been doing something wrong.

After hours of looking I found a note in the Dell community support forums that they are not supported and won't be - limitations of the ASIC.

Wow.

These devices are entirely unsuitable for any environment where monitoring is important, and I'm going to recommend that my customer return it and get a switch that does.

And now I know to put "Does the device support 64-bit octet counters?" on the shopping checklist.

Building LIBGD on FreeBSD

While building Thomas Boutell's excellent libgd library (ver 2.0.33) on FreeBSD 4.11, I ran into a problem that Google shows lots of others have had, but without a solution. After configuring the library for the platform, undefined pthread variables are found:

---

$ make
...
/usr/local/bin/bash ./libtool --mode=link gcc  -g -O2   -L/usr/local/lib \
   -L/usr/local/lib -o annotate  annotate.o ./libgd.la -ljpeg -lfreetype -lpng \
   -lz -lm  /usr/local/lib/libiconv.so -Wl,-rpath -Wl,/usr/local/lib
gcc -g -O2 -o .libs/annotate annotate.o /usr/local/lib/libiconv.so \
   -Wl,-rpath -Wl,/usr/local/lib  -L/usr/local/lib ./.libs/libgd.so \
   -ljpeg -lfreetype -lpng -lz -lm -Wl,--rpath -Wl,/usr/local/lib
./.libs/libgd.so: undefined reference to `pthread_mutex_unlock'
./.libs/libgd.so: undefined reference to `pthread_mutex_destroy'
./.libs/libgd.so: undefined reference to `pthread_mutex_lock'
./.libs/libgd.so: undefined reference to `pthread_mutex_init'
*** Error code 1

---

Looking around found no libpthread.a library - huh? - in any of its forms, but it was hard to imagine that this machine simply didn't have this facility.

Several hours of hunting this down showed the problem: pthreads are found in libc_r (the re-entrant C library). Aha! This is enabled with the -pthread flag to gcc.

I typically use a simple wrapper script around ./configure so that I can document my settings, and I just added CFLAGS="-pthread" to the ../configure-gd script:

---

#
# requires LIBPNG
#
#       sh ../configure-gd
#       make
#       make check
#       sudo make install
#

export CFLAGS='-pthread'   # for FreeBSD

exec ./configure \
        --without-x

---

The proper solution is to fix the configure.ac script to check for this properly, but it looks like very ugly territory; many flavors and variants and workarounds. Sadly, not up for that today.

I'm documenting this here mainly so Google will index it and perhaps help some future GD-builder who's been having the same problem.

"Think Assimilation"

I have no particular interest in (or objection to) Mac computers, but with today's announcement that Apple will be using Intel Pentiums in their computers starting in 2006 (IBM apparently couldn't deliver the PowerPC chips Apple required) is too good of an opportunity to pass up.

The wailing and gnashing of teeth from the Mac users who bemoan Intel (and by extension, Microsoft) is just asking for schadenfreude, so I'm happy to take my shots with the rest of 'em.