Blog of Annoying Technical Details

Yay for the syntax error! Usually they are the simplest of problems, you forgot a semi-colon, or left off a parenthesis. But while I was building my OpenEmbedded build environment I ran into the error listed in the title here, but it seems far from simple. It is nested deeply within many layers of build systems:

make TARGETS=oneprocess SHELL=”/usr/bin/tcsh” CC=”ccache gcc” CFLAGS=” -isystem/home/hans/code/openembedded/stuff/tmp/staging/i686-linux/usr/include -Os -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-error -DHAVE_CONFIG_H -DGENERATOR_FILE” LDFLAGS=”" LIBERTY=”/home/hans/code/openembedded/stuff/tmp/work/i686-linux/gcc-native-3.4.6-r9/gcc-3.4.6/build.i686-linux.i686-linux/gcc/../libiberty/libiberty.a” install-bin
make[2]: Entering directory `/home/hans/code/openembedded/stuff/tmp/work/i686-linux/gcc-native-3.4.6-r9/gcc-3.4.6/build.i686-linux.i686-linux/gcc/fixinc’
/usr/bin/tcsh /home/hans/code/openembedded/stuff/tmp/work/i686-linux/gcc-native-3.4.6-r9/gcc-3.4.6/gcc/fixinc/genfixes machname.h
SHELL=/bin/sh: Command not found.
export: Command not found.
if: Expression Syntax.
make[2]: *** [machname.h] Error 1
make[2]: Leaving directory `/home/hans/code/openembedded/stuff/tmp/work/i686-linux/gcc-native-3.4.6-r9/gcc-3.4.6/build.i686-linux.i686-linux/gcc/fixinc’
make[1]: *** [fixinc.sh] Error 2
make[1]: Leaving directory `/home/hans/code/openembedded/stuff/tmp/work/i686-linux/gcc-native-3.4.6-r9/gcc-3.4.6/build.i686-linux.i686-linux/gcc’
make: *** [all-gcc] Error 2
FATAL: oe_runmake failed

After much searching around, I found that this bug can be found in the original sources of gcc-3.4.6: NetBSD Problem Report #33238. Hmm, well, it looks like the root of the problem is this:

SHELL=/bin/sh: Command not found.
export: Command not found.

This is Bourne Shell (sh, bash, ksh, etc.) syntax and I am weird, old stickler for tcsh. So I ran bash, like basically everyone does these days, and voila, no more problem…

There is at least two parts of your net connection feeling ’slow’: one is responsiveness and the other is bitrate of downloading and uploading. Usually, when the internet feels ’slow’, it is not a problem of bitrate but rather responsiveness.

Cable and DSL modems are really the cause of most of the issues related to responsiveness. These modems have huge upload buffers, like 1 second or more. The idea is that they are tuned to making one user as fast as possible. But if that buffer is full, that mean any new packet you send will be delayed by at least one second.

So there is a simple way to regain the responsiveness, and that is by preventing the upload buffer from filling up ever. Basically, if you limit the total bitrate to be slightly less than the actual bitrate of the connection, then the buffer will always be empty. Then even when all your neighbors are using your connection for bittorrent, it’ll still be responsive. Your up/down bitrates will of course be slower.

I currently have about 10 regular users of my open wifi and I basically never even notice. I’ve messed with the ‘tc qdisc’ stuff quite a bit, and I have found that it is quite tricky to get things running smoothly. I currently use the most basic ‘tc qdisc’ filter, called a “Token Bucket Filter”, set up like this:


tc qdisc add dev eth1 root tbf rate 370kbit latency 50ms burst 2000


But if you have a WRT54G v1 through v4 (newer versions are much more limited), then you can run firmwares like Tomato and DD-WRT, and they’ll do this token bucket setup for you. I highly recommend Tomato, unless you want to be more 1337, then go with DD-WRT. In Tomato, go to QoS and you’ll see a nice web interface for playing with these things.