Hardware

My servers and workstations use ECC memory with the motherboard BIOS memory scrubbing enabled. Some motherboards require FB and ECC, other motherboards have non-ECC/ECC options (depending on CPU characteristics).

The m0n0wall is our only piece of "network-class" hardware that doesn't use ECC memory. Since m0n0wall executes from memory, one should want the most stable and error-correcting hardware available?

Is there a good reason to use ECC memory with m0n0wall? It would require changing the motherboard to a different class - and higher power consumption - CPU/memory combination.

My servers and workstations use ECC memory with the motherboard BIOS memory scrubbing enabled. Some motherboards require FB and ECC, other motherboards have non-ECC/ECC options (depending on CPU characteristics).

The m0n0wall is our only piece of "network-class" hardware that doesn't use ECC memory. Since m0n0wall executes from memory, one should want the most stable and error-correcting hardware available?

Is there a good reason to use ECC memory with m0n0wall? It would require changing the motherboard to a different class - and higher power consumption - CPU/memory combination.

No reason at all, here's why, screen shot attached.

This m0n0wall runs a wireless ISP for an entire city, so it's important it be up 24/7. It never has any problems, it's just an old Dell PIII800 with 128MB RAM and (4) 3COM 10/100 Cards.

I never get into the ECC debate because I've always seen it as snake oil for companies to sell servers this way. I've worked with PC servers for almost 2 decades and never have I seen any benefit from a server running plain old RAM than the one sitting next to it running ECC RAM. If the system is stable and cooled properly, you'll never be able to tell the difference between it and the one sitting next to it running the more expensive ECC RAM.

Only 200 days knightmb?     I've personally had uptimes over 800 days and know a lot of others have as well, using plain old WRAP or Soekris gear or old desktops, no ECC.

ECC probably isn't worth it for this purpose. If you need the power that only server class hardware can give you (it offers considerably more throughput, but unless you have a gigabit pipe to the Internet it doesn't matter), you'll have no option, but for the bulk of deployments it just isn't necessary.

Only 200 days knightmb?     I've personally had uptimes over 800 days and know a lot of others have as well, using plain old WRAP or Soekris gear or old desktops, no ECC.

ECC probably isn't worth it for this purpose. If you need the power that only server class hardware can give you (it offers considerably more throughput, but unless you have a gigabit pipe to the Internet it doesn't matter), you'll have no option, but for the bulk of deployments it just isn't necessary.

Hehe 
Well you know, the uptime is about as long as the most recent release sometimes since you have to reboot for the new update. I had to reboot it last year I think because I replaced the UPS battery that was connected to it. Of course, you would think at 3:00AM, no one would be using it, but sure enough I got calls for the 10 minutes it took me to take it down, take apart UPS, replace battery, etc. People were calling in at that time complaining it wasn't working, LOL.

I dont think ECC is going to do anything for you but take more power and increase memory latency. I too have never seen any benefit from running it.. Would not recommend going out of your way to use it.

However, as knightmb just inadvertently pointed out having a machine w/dual power supplies would be quite beneficial so enterprise class servers can be great m0n0 routers.  The downside is its hard to find an enterprise server now days w/out multiple cores and buttloads of memory, both of which go to waste running m0n0wall and use even more power. Then again if you can get by w/commodity hardware and invest the money in either an automatic power transfer switch, a UPS that allows you to hot-swap batteries, or a redundant psu in a standard atx form you can avoid knightmb's scenario.