No proxies.
Just reset everything... See how it looks after a couple of hours.

Do you accept shares unconditionally? I'm getting quite a discrepancy between cgminer stats and your stats:

CGminer:
Gets:1116
Accepts: 7805 
Rejects:3
Discards: 155
Stale: 0

maxBTC:
Gets:1108
Accepts: 7066
Stale: 282

There's no settings to check. I mine on BFLs so there's nothing to change.
Using 1 instance of CGminer in load balance mode on EMC servers US2 & US2 and OZ US server ports 8332 & 80.
It's a direct comparison.

*Sniff*

I'm leaving you.

*sniff*

It's not you, it's me.

*sniff*

I lie, it is you.

With a reject rate of always >1.5% (currently 2.2% over the last 2 days!)

I don't know why it should be, ping is the same as with EMC (60ms), but that has a reject rate of ~0.7%.

Ho hum

Chart seems to have turned into an 'L' shape...

Would CFLAG -D_BIG_ENDIAN_ not be an option?

And an even WARMER garage.

I think you're going to end up with a very warm mini-fridge and a burnt out motor.

Updated version:
https://github.com/downloads/pshep/cgminer/cgminer-2.4.1-1-mipsel.tar.gz

Still the same binary, but a few tweaks to the scripts and an all-new serial driver.

I discovered there was a problem with the FTDI drivers. The existing one wasn't quite compatible with the FTDI chip used in the BFL (hence having to add product and vendor IDs when loading the driver). I found newer drivers which had the chip included (FT232H), but these drivers were for later versions of linux kernel than DD-WRT uses, so wouldn't compile.
In the end I had to hack together a driver from the old one as a base and adding in the bits of code needed to get the new chip working. Seems to be working for me so far, but it is quite experimental (read: a hack) so be aware.

The specific issue I found was that when more than 64 bytes were sent by the BFL, the 65th and 66th byte would be lost. This meant that when 6 or more valid nonces were returned by the BFL, the 6th would be corrupted, leading to the 7th and onward being read incorrectly. What was happening was the driver was expecting a packet of only 64 bytes and reading the next two bytes as controls. In fact the packet being sent was much larger and the driver was discarding valid data.

The driver fix does two things:
1. Adds native support for the FT232H (and that's the only device I added)
2. Scans the device for the max packet size, which previously was hard-set to 64 bytes.

At some point I'll put my ftdi_sio.ko code changes on github.

It does? Ah well. I may change it if something better comes along. It'll do for now.
(I find it useful anyway )

Perfect!

I didn't see this limit in the docs (at least not where I was looking).

So I've added a new page to Anubis to retrieve balances from blockchain.info. All I display is BTC received, sent and current balance. The rest is wasted bandwidth for us both.
Could you add an API which returns the minimal data?

Updated again.

V2.3

Adds an accounts page, so you can add bitcoin addresses and retrieve a summary of the balances.

Just what it say in the API doc...

Currently: /rawaddr/$bitcoin_address

The other (/address/$bitcoin_address?format=json) prints the same.

They recommend a partition of 512MB for Optware
http://www.dd-wrt.com/wiki/index.php/How_to_-_Format_and_Partition_External_Storage_Device

You can always make another partition for NAS

and you absolutely need a powered hub. Each of those devices may only use a small amount of power, but if they are all getting that power through the router then you're going to stress the router. At least have the hub attached to the router powered.

There's an updated to that script I've not added yet:

For the kill commands, change them to the following:

Use screen instead?

Look at the scripts in my dd-wrt implementation in my sig. may help you.

That's fine. The wording should really be changed there to 'No Icarus detected' rather than 'Test failed'. Give the wrong impression.

shares =
{
    "submitted" = <shares submitted>,
    "stale" = <shares deemed stale by pool>,
    "invalid" = <shares deemed invalid by pool>
}

block =
{
    "currency" = <BTC, NMC, etc...>
    "id" = <block ID>,
    "duration" = <seconds>,
    "shares_round" = {<'shares' for entire pool for the round (as defined above)>},
    "shares_user" = {<'shares' for all workers of the user for the round (as defined above)>}
}

balance =
{
    "currency" = <BTC, NameCoin, Ix, iO, etc.>,
    "confirmed" = <confirmed reward (>=120 valid blocks) in Satoshis>,
    "unconfirmed" = <unconfirmed reward (<120 valid blocks) in Satoshis>,
    "estimate" = <estimated reward for current round>,
    "last_pay" = <value of last payout in Satoshis>,
    "last_pay_time" = <time of last payout in unix time>,
    "total_pay" = <total value of payout in Satoshis>,
    "threshold" = <min confirmed reward before auto payout in Satoshis. 0 for no auto payment>
}

worker =
{
    "id" = <unique identifier>,
    "name" = <name / description>,
    "hashrate" = <worker hashrate>,
    "last_activity" = <last submitted share time in unix time>,
    "shares_round" = {<'shares' for current round (as defined above)>},
    "shares_reset" = {<'shares' since last user reset (as defined above)>},
    "shares_total" = {<'shares' for all time (as defined above)>},
    "reward_algo" = <reward algorithm identifier>,
    "fee" = <fee multiplier (1% = 0.01)>
}

user =
{
    "API" = 1.0.0
    "pool_MOTD" = <whatever the pool wants to tell us>,
    "pool_hashrate" = <entire pool current hashrate>,
    "pool_users" = <number of active users on the pool>,
    "pool_workers" = <number of active workers on the pool>,
    "current_round" = {<array of active 'block' (as defined above)>},
    "user_hashrate" = <current hashrate in H/s for all workers - implementation pool dependent>,
    "last_activity" = <last submitted share time in unix time>,
    "balances" = {<array of 'balance' (as defined above)>},
    "workers" = {<array of 'worker' (as defined above)>}
}

Where:
All time displays presented as UNIX epoc.
All hash rates presented as hashes per second.
'Satoshis' is the smallest value for the associated currency. i.e. For USD this would be 1c.

Hashrate in the tab, that's a good one.

Regarding the auto-refresh: I'm not much of a web developer and I don't know how to just update fields, only the inelegant whole page refresh. Messy, clunky, awkward, resource hungry, inefficient whole page refresh.

If you want to do it yourself you can add:
<meta http-equiv="refresh" content="10" >

just below:
<head>

of index.php

I'll look into putting the total hashrate in the title.