Great, thanks! It works! Except it's reporting that it's working on the wrong pool. And I tried to change the password on the web interface, and now I'm locked out.

I'll post to your forum later - I just wanted to make a quick report before I go to work this morning.

One more interesting thing... I'm using my TZ: Europe/Lisbon [WEST +01:00]. The time displayed by cgminer and all devices @ main page is correct, but the time that the live graphics displays is shifted by -1 hour.
 

Also, when I try static charts and then I select 'update', I always get same error:

and the graphics not updated.

The change time zone option in the WebUI changes only for the WebUI.  Since that is what people mostly look at it is all that is really necessary.

If you really want to change the timezone in the underlying OS for some reason it is quite simple, here is an article that explains how;-

http://www.thegeekstuff.com/2010/09/change-timezone-in-linux/

By the way, the full suport forum for MinePeon is at ;-

http://minepeon.com/forums/ and it is better to ask there.

Neil

Its a bug that happens with some networks, does it fix itself after 5 minutes of operation?

Neil

I must insist with the send e-mail alerts option. I (and all Gmail users) need SMTP authentication to use MinePeon to send mails via gmail.

... also I've just added to cgminer master git the code for a TODO I wrote long ago in the Icarus driver ...
It allows you to set a limit to --icarus-timing short (or long)
Basically the idea is that if your computer affects the timing due to CPU/Task Scheduling/Swapping/... an optional specified limit wont allow the read_time to go beyond the limit
What it really means is that even if the MH/s is showing wrong due to a bad timing calculation, it will still abort the work at 'limit' and thus will be mining at maximum performance if limit is set appropriately (WU: will show that over a few days)

Historically I have almost always used --icarus-timing short
Now it will be --icarus-timing short=100

In your case if you use --icarus-timing short=90 it should never go idle even for the fastest one - AMU0 - if it really is 448MH/s
90 allows up to 477MH/s

It is the time to process a full nonce (times 100ms)
So 90 = 9000ms

Anything that can process a nonce 9000ms or slower will have their work aborted before it finishes - so it cannot go idle

The timing is for 2 reasons:
1) To estimate how much work was done when work is aborted (about 1/3 of work has no nonces and must be aborted) i.e. to get the MH/s on the display correct
2) To estimate how long work should be allowed to run until to abort it (less a safety factor of 150ms)

Normally --icarus-timing short aborts the work 150ms before the work should finish but of course if the computer isn't allowing cgminer to mine at full speed, it's timing estimate can get it wrong
(I use a line of best fit through the data points to estimate Hs and W - which seems to be pretty accurate if the computer isn't busy)

The Icarus mining devices don't send a message to say work has finished, so you have to start new work before the old one finishes.

Oh ... and a lot of this is all in FPGA-README ... (and the new option also)

Anyway the meaning of:
AMU0 Re-estimate: Hs=2.231016e-09 W=1.409179e-03 read_time=9433ms fullnonce=9.584s

Is that it takes 2.23ns to do a single hash with an average latency of 1.4ms per work item
At 2.23ns it takes ~9.584s to hash a full nonce range (2^32 hashes)
So my code decided to abort the work 150ms early (as is the safety margin) at 9433ms to ensure it never goes idle

thanks heaps for that. it makes much more sense now.

I did read the fpga-readme earlier but it didn't make sense to me at the time. ill go have another read now.

thanks again.

Kano fixed my hosed up pool detection code and submitted the changes a few days ago. He's also made changes to the error rate code.

Have you tried pulling the latest cgminerLCDStats.py commit? It may fix your LCD display issues.

BTW - what else are you seeing that's incorrect?  Thanks