Monthly Archives: January 2013

It’s been a while since I played around with firewalls. Picked up a really cheap Watchguard Firebox x5000 Peak on eBay. Could not resist taking the Peak platform for a spin with pfSense. I’ve heard good things about the power of the “Peak” platform. Even though the x5000 is older generation than the typical x550/x750s I’ve been playing with.

Unlike the x500 which comes with only 10/100 Realtek (problematic) interfaces. The x5000 is equipped with 3x 10/100/1000 nics and 8x 10/100 nics, all by Intel.

This box also comes with a second COM port at the rear of the unit. Though it serves no real purpose when running pfSense as all output is defaulted to COM1.

This firewall is actually just slightly shallower than the x750e series boxes. The x750 firewall is just a bit too deep for wall mount racks and required a right-angle power cable in order to fit. The x5000 is about an inch shorter.

Taking the cover off exposes all the various components of this box. The Intel NIC chips can be clearly visible.

The “Peak” comes with 512MB of RAM standard. Unfortunately I could not locate any more DDR RAM to upgrade it, so for now will stick with the stock amount. I used to have tons of original DDR RAM modules, but got rid of them thinking I’m never gonna need them again.

Just like most other boxes. This one comes with a 128MB Compact Flash card. And just like most of the other boxes, the IDE port is available for additional internal storage.

I wanted to take a quick peek at the CPU. Specifically to see what the stock CPU is. What I discovered was quite shocking. First of all, I had a problem getting the heatsink off from the CPU. Ended up tearing the heatsink and CPU directly from the ZIF socket. Closer examination revealed the cause of the problem. The amount of heat paste on this thing is insane. The gap between the heatsink and CPU was at least a couple of millimeters. It was everywhere. Someone really went to town on this sucker.

It took me almost 30 minutes to clean the CPU, heatsink and motherboard from all the thermal compound. I used plenty of rubbing alcohol and tons of cloths to get everything cleaned. Everything was completely covered with the goop.

The CPU could finally be identified. Intel Pentium 4 2.8Ghz SL6PF. Not the most energy efficient CPU, quite the opposite. This firewall definitely sucks down a lot of juice. It’s actually a pretty fast CPU for the task. With firewalls raw speed matters most when dealing with latency. This one has plenty of speed.

Loading pfSense on this firewall is incredibly easy. There’s no BIOS flashing required. It boots pfSense from a 2GB CF card without any problems at all. Unlike the x500 firewall, which has Realtek NICs and randomly stops responding, the Intel NICs are bulletproof.

Once I got the firewall configured. It was time to do some throughput testing. I was expecting the speeds to be sub-par simply because both the 1000Mbit and 100Mbit interfaces are all on the PCI bus. PCIe did not exist in P4 era.

Interestingly enough, the 8th 10/100 NIC does not appear in the list of devices. Not sure if this is due to pfSense limitation or a problem with the port itself.

On with the testing. The test was performed by copying a 8GB file between two machines. Both machines stored the file on an SSD to eliminate the disk as the bottleneck. The test was performed 3 times for each direction and values averaged over the test.

Source Interface

Destination Interface

Transfer Speed

CPU Usage

fxp0

em0

10.3 MB/s

20%

em0

fxp0

11.5 MB/s

21%

em0

em1

42.8 MB/s

41%

em1

em0

97.8 MB/s

100%

*

fxp0

fxp1

11.5 MB/s

27%

fxp1

fxp0

11.5 MB/s

27%

* pfSense UI interface stopped responding during the transfer.

Once again it’s been shown that the bottleneck is the PCI interface. With maximum theoretical speed of 133 MB/s shared across the PCI bus, the firewall will never be able to attain faster combined throughput than roughly 100 MB/s. This is not terrible though for a small network as that kind of saturation is rather rare. What I can’t explain is why pfSense shows different max speeds depending on direction of data. This technically shouldn’t make a difference. I saw the same thing happen when benchmarking the x550e firewalls.

In the end, this is actually a pretty sweet box for what it costs nowadays. Even with “only” 512MB of RAM it’d be sufficient to run a small rack. However I do not recommend it for office use. The fans run 100% speed all the time and are fairly loud, haven’t found a way to throttle the fans other than replacing them with something quieter. The box, running pfSense draws about 52W at idle and almost 100W under load.

I’ve been spending a lot of time lately thinking about how to best redo my GaugePod program for my Carputer project.

Existing Problems (and potential solutions):

Program sometimes crashes on resume from hibernate.
Need to determine what causes this. This started when upgraded from Atom to I3 Motherboard/CPU. Perhaps Mobo not sending proper signal to Windows?

Current Arduino implementation isn’t very accurate.
This one is major. Had to fudge the voltage numbers to get semi-accurate reading. This needs a rewrite. Right now the Arduino box simply sends the raw value from the ADC (0 to 1023) as input into GaugePod. Perhaps a better solution would be to have the Arduino send the actual voltage. In fact, I could monitor the reference voltage to make sure it doesn’t drop below 5V. Arduino could detect any drop in reference voltage and adjust reading before sending to the Carputer. Could even add an LED to indicate a condition where reference voltage is not 5V, though it wouldn’t know if input voltage is >5V. Though that is highly unlikely as the reference voltage is coming from a 5V voltage regulator.

Change how GaugePod stores settings locally.
Right now the settings are stored in a DataSet that’s stored in the user profile. Can’t migrate settings or even hand edit. Need the ability to import/export settings. Switch to XML Format. Will have to write a custom library to deal with this. Won’t be difficult. Already did this kind of implementation in the UltraDMM project.

The Arduino box is too big and wiring too complex.
Need to simplify wiring, switch to Teensy for smaller footprint. Perhaps add chokes to eliminate electronics noise. Rev 2.0 of the Arduino box uses Molex connectors for the sensors.
Better to use barrel connectors. Need 3 Pins.
1 – 5V Input
2 – Ground
3 – Sensor Return
Something like this would work:
Additional advantage of using round connectors. Easy enough to drill holes for them rather then cut square holes for the Molex connectors. The enclosure would be nicer looking. The screw-in connectors would deal better with vibration in the car.

Program runs in foreground, blocks access to Centrifuse
Possible solution to implement as plugin for Centrifuse. Though it might be possible to simply run the program inside a Centrafuse window. I vaguely remember reading that this can be done. Drawback of this approach is reduced screen real-estate.