...

Hi kano,

there are two BFL but they're managed by a different instance of cgminer.

anyway, here it is a screenshot after half a minute since restart with 2.10.5

cgminer version 2.10.5 - Started: [2013-02-08 12:36:49]

--------------------------------------------------------------------------------

(5s):1.120E (avg):801.4Ph/s | Q:482 A:0 R:0 HW:99 E:0% U:0.0/m

ST: 0 SS: 0 DW: 1 NB: 1 LW: 2 GF: 0 RF: 0 WU: 96.9

Connected to rpc.hhtt.1209k.com diff 128 with LP as user 1..._128

Block: 00d9ec7e48042357... Diff:3.27M Started: [12:36:49] Best share: 87

--------------------------------------------------------------------------------

[P]ool management [S]ettings [D]isplay options [Q]uit

ICA 0: | 268.3M/172.2Mh/s | A:0 R:0 HW:7 U:0.00/m

ICA 1: | 299.8M/161.4Mh/s | A:0 R:0 HW:7 U:0.00/m

ICA 2: | 236.2M/210.2Mh/s | A:0 R:0 HW:1 U:0.00/m

ICA 3: | 251.4M/237.0Mh/s | A:0 R:0 HW:2 U:0.00/m

ICA 4: | 381.7M/253.0Mh/s | A:0 R:0 HW:1 U:0.00/m

ICA 5: | 996.4P/400.7Ph/s | A:0 R:0 HW:6 U:0.00/m

ICA 6: | 159.7M/155.6Mh/s | A:0 R:0 HW:8 U:0.00/m

ICA 7: | 250.0M/232.5Mh/s | A:0 R:0 HW:9 U:0.00/m

ICA 8: | 378.7M/321.8Mh/s | A:0 R:0 HW:3 U:0.00/m

ICA 9: | 195.2P/133.6Ph/s | A:0 R:0 HW:7 U:0.00/m

ICA 10: | 260.4M/156.2Mh/s | A:0 R:0 HW:7 U:0.00/m

ICA 11: | 711.7M/439.0Mh/s | A:0 R:0 HW:3 U:0.00/m

ICA 12: | 284.5M/182.0Mh/s | A:0 R:0 HW:6 U:0.00/m

ICA 13: | 1.684E/534.3Ph/s | A:0 R:0 HW:6 U:0.00/m

ICA 14: | 278.5M/241.1Mh/s | A:0 R:0 HW:1 U:0.00/m

ICA 15: | 273.2M/174.7Mh/s | A:0 R:0 HW:9 U:0.00/m

ICA 16: | 330.7M/253.1Mh/s | A:0 R:0 HW:3 U:0.00/m

ICA 17: | 890.1M/457.4Mh/s | A:0 R:0 HW:3 U:0.00/m

ICA 18: | 150.4M/170.3Mh/s | A:0 R:0 HW:6 U:0.00/m

ICA 19: | 554.0M/319.4Mh/s | A:0 R:0 HW:5 U:0.00/m

--------------------------------------------------------------------------------

[2013-02-08 12:38:54] ICA11: invalid nonce - HW error

[2013-02-08 12:38:55] ICA1: invalid nonce - HW error

[2013-02-08 12:38:56] ICA15: invalid nonce - HW error

[2013-02-08 12:38:57] Icarus 2 Re-estimate: Hs=7.223040e-10 W=6.352486e-01 read_count=36 fullnonce=3.738s

[2013-02-08 12:38:58] ICA7: invalid nonce - HW error

[2013-02-08 12:39:01] ICA19: invalid nonce - HW error

[2013-02-08 12:39:02] ICA3: invalid nonce - HW error

[2013-02-08 12:39:02] Icarus 3 Re-estimate: Hs=-6.210501e-10 W=2.930369e+00 read_count=1 fullnonce=0.263s

[2013-02-08 12:39:02] ICA12: invalid nonce - HW error

[2013-02-08 12:39:04] ICA13: invalid nonce - HW error

[2013-02-08 12:39:04] ICA7: invalid nonce - HW error

[2013-02-08 12:39:05] ICA16: invalid nonce - HW error

[2013-02-08 12:39:06] ICA10: invalid nonce - HW error

[2013-02-08 12:39:07] ICA15: invalid nonce - HW error

[2013-02-08 12:39:10] ICA10: invalid nonce - HW error

[2013-02-08 12:39:11] ICA8: invalid nonce - HW error

See ICA 5/9/13 for example.

Thanks.

spiccioli

Ok clearly something is going wrong since the hash speed estimate is negative.

(Hs=-6.210501e-10) Travelling back in time

I've tried it on my Icarus and of course not had the problem ... I've only got 2 Icarus so it probably needs more hardware to see it happen.

Most likely it's that your computer isn't handling hashing that many devices stably ... or it's busy doing other stuff at the same time.

The timing code does depend on reasonably reliable code CPU performance (as it says in the FPGA-README), since it is using the performance to estimate the hash rate.

How the code works is that it uses the hash answers to estimate a line of best fit (using least squares) to determine a reasonable estimate of the hashing speed.

Bad hash values can skew the line badly and cause invalid results if the number of sample points is small (which it is early on)

Oddly enough you probably will find it is still getting a reasonable U: value for the ones with the weird MH/s values.

If it is using read_count=1 (the minimum) it just means it is aborting work really early and thus doing about 100x the work generation work to get the same results.

Of course that is not at all desirable and will reduce the performance of that device, but it will still hash away anyway.

There's a simple fix (well it should fix it) that will give you very close to maximum hashing performance but the MH/s shown on the screen will most likely be incorrect.

The fix is to simply use --icarus-timing Hns:Timeout with values that you know are below the fastest card, but close to the limit (which is what the timing code estimates)

The second value in Icarus timing is how long (in 1/10ths of a second) to let the cards hash for before interrupting it with new work.

The first one is an estimate of how long it takes to do a single hash, so it can estimate how many hashes it did when it aborts any work, to determine the MH/s value.

Even Timeout estimates under by 4 or 5 times will still get you close to the best U: value.

If the value is close to the time it takes to complete a nonce range then it will maximise it's performance.

If it is a little below that, it still will be very close to maximum performance anyway.

If you are certain that none of your devices hash faster than 500Mh/s you can manually calculate values to use.

So assuming 500Mh/s is the fastest, it means it will complete a nonce range in 8.59 seconds.

We can take a guess of: an average performance of all the cards of around 250MH/s ? So that means each hash takes on average 4ns

So using --icarus-timing 4.0=84 should be OK based on those estimates.

The value 84 should always be OK - no need to adjust it at all unless you really are hashing at faster than 500MH/s on any board; and the slower boards, that number is OK also - even down to 100Mh/s it really doesn't matter too much.

The value 4.0ns will mean that the MH/s hash rate shown will get nudged towards 250MH/s every time it fails to find a nonce before 8.4s (or an LP happens) Thus for any cards doing 250MH/s it will show that correctly, for any others it will nudge them towards 250MH/s every so often, so will read low for the cards that hash above 250MH/s and high for the cards that hash below 250MH/s - however it will NOT affect the U: rate significantly.

Of course U: can take a few days to start to converge on the expected value ...

So without a LOT more information about the hashing speed and other details of your boards, using --icarus-timing 4.0=84 should be close to maximising your shares anyway.

You can of course set a different pair of values for each card if you want as such:

--icarus-timing 4.0=84,3.6=84,2.6=84,3=84

A normal Icarus board is 380Mh/s which is: --icarus-timing 2.6316=112 (the default settings inside the driver)

If you have more cards than you specify, it will use the last for each of the extra cards.