Cairnsmore1 - Quad XC6SLX150 Board

[Lethos]

I've only got 2 boards, so don't expect 10 to react the same, but ubuntu and windows do react abit differently to a boards and their tty/com ports.
In ubuntu the order they are plugged in usually chooses their number, lowest first. In windows generally it remembers the one that board had last time.

So the first plugged in will always get 0/1/2/3 and the second always 4/5/6/7.

[1714213115]

1714213115

[1714213115]

1714213115

[kano]

...
my biggest 'problem' was not mapping ICAn to ttyUSBn, but ttyUSBn to the 'correct' board (I have ten of them) so that, for example, I can flash a slower bitstream to the pair with too many errors.

spiccioli

Yep, I was just adding the extra bit on the end after that in case anyone wanted to know
The mapping (ICAn -> /dev/...) is simple - since cgminer knows it and you can ask it.
Also note that if any /dev/... fails to be detected properly, the ICAn number will not increment past it i.e. there won't be a gap
So the ICAn numbers can change if there are any detection problems

[makomk]

What on the board knows to turn the yellow LED on when the FPGA is waiting on work?  And if it knows to turn that on, why can't it send a request for more work?

It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

[kano]

What on the board knows to turn the yellow LED on when the FPGA is waiting on work?  And if it knows to turn that on, why can't it send a request for more work?

It could do, but none of the existing mining software would understand the request. In theory you could (for instance) have the miner send a nonce of zero, which is never returned by the Icarus miner as a genuine nonce, when it reaches the end of the current work and then modify mining software to understand this.

The current software adds minor complexity to handle the fact that the Icarus bitstream DOESN'T send a completion reply.
It must decide when to abort the work before it is idle, but making it ~99% means fewer requests for work
Sending a completion reply would of course be easier to handle.

There are, however, 2 estimates for the Icarus bitstream:
1) When to abort work (and thus how much work was done if it doesn't find a share before that)
2) How much work was done when the work is aborted due to an LP

Adding a completion message removes the estimate for 1) but not 2)

A reply to an abort saying how much work was done at the time of the abort would also be required to perfect the MH/s calculation (though the estimate is highly accurate now anyway for a normal Icarus and can be made accurate with --icarus-timing for any other Icarus bitstream FPGA)

Interestingly enough, the way that Icarus returns a share and stops is actually the current best method of mining.

The only way to improve it would be for the Icarus to also continue working on the rest of the nonce range - thus the code would keep requesting a reply and keep getting nonce's until it got a 'finished' reply.

Nonce-range processing is good if you have to wait for the processing to complete, but the Icarus method is better.

[spiccioli]

OK, with a bit of help from ebereon running lots of SmartXplorer runs, the following should apparently hit 200 MHz on the pairs that couldn't manage it before: http://www.makomk.com/~aidan/shortfin-eb-20120809.zip Unfortunately, it doesn't have a functioning DCM watchdog, so you have to watch out for pairs falling over. Apparently ebereon has managed to get all of his FPGAs running reasonably stably at 200 MHz by combining this with the dcmwd2 ones. A good starting guess would probably be 200 MHz http://www.makomk.com/~aidan/shortfin-dcmwd-20120808.zip on FPGA0/1, 200MHz shortfin-eb on 2/3, switch to shortfin-eb if you have too many invalids on 0/1, switch to dcmwd if the U/m of 2/3 drops off spectacularly after a few hours (should be 5+, if it's 2 to low 4s something's up), fall back to 190MHz dcmwd if either of those still doesn't work reliably.

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli

[makomk]

makomk,

are you going to build a version which has the dcm watchdog again or is the dcm watchdog a problem when trying to reach higher hashrates?

spiccioli

I am, it's just that was built with an older non-functional version of the DCM watchdog and I ran into a whole bunch of irritating technical issues when trying to merge the newer version in. http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards. I'm seeing some really weird behaviour from the 210 MHz bitstream though - it's consistently getting a lower U/m than it should on one half of my test board (about 5.3ish when it should be closer to 5.86).

Note that I'm trying out a new archive format with this set of bitstreams to reduce the download size. You may need to download 7-Zip to unpack them if you don't have any other unarchiving software installed that can open .7z files; it's of course free, open source and adware-free and all that good stuff. Linux users should install p7zip instead. (The new archive plus the 7-Zip installer still comes in at a quarter the download size of using ZIP, so it's a definite saving.) Try starting off with the 200 MHz bitstream.

Hope this works. Donations to 1CCorPPK8X6Px5iNxCBc5Eciw81iZPVBPh are welcome as always.

[toxicocean]

http://www.makomk.com/~aidan/shortfin-dcmwd4c-20120811.7z should have the higher potential hashrates and the DCM watchdog, with a bit of luck it should reach 200+ MHz on most boards.

Are these DCM bitstreams also suitable for pre #0050 boards? (I tested the shortfin_dcmwd2_test_200_overclock.bit some days ago and it didn't seem to be hashing very stable on my #0005 board)

Currently the best bitstream for my board seems to be the shortfin_icarus_cm1_test_190_overclock.bit, closely followed by shortfin_eb_test_210_overclock.bit, but that last one isn't stable (1 Icarus device stops performing work after some time)

[kano]

...
Maybe so, but as you say, not processing the complete range is a bug.

I can't be bothered to make a complete proof, but it's demonstrable that terminating after finding a share lowers overall utility.

If valid solutions are independent and have a uniform probability, failing to complete the range will miss clusters of valid shares.  A nonce range will have an integer number of valid shares - 0, 1, 2, 3 etc.  Binomial theorem would allow you to calculate the expected distribution of valid shares per range.  In any range with 2 or higher solutions, terminating after the first one will lower the ultimate utility of the system and, effectively the 'luck' of the miner.  

Actually the net effect would be distribution dependent.  If % of nonce ranges with only 1 solution exceeds the % of ranges with 2-99 solutions, you are better off moving to the next range.  (I chose 99 as an arbitrarily large number where the probability of having that many solutions in a range becomes vanishingly small)

No, sorry, it doesn't reduce U due to probability.
(and no it's not a bug)

It only reduces MH/s due to processing more work to do the same number of hashes
Having a slightly lower MH/s will of course also mean a slightly lower U - though the difference is very small.

The distance from one share to the next is random and independent of the work being done
i.e. you can look at it this the simple way: every hash done has an equal chance of being a share.
So it doesn't matter if you do 10% of each nonce range, or 90% of each nonce range, over time the average expected number of 1 difficulty shares will converge to 1 in each 2^32 hashes, no matter where they come from
(as long as they are not duplicates of course )

[Lethos]

Going to give the 210 Bitstream a go today. Great work Makomk.

[hm]

I just flashed shortfin_dcmwd4c_ed_test_200_overclock.bit and it seems to be a definitive improvement over shortfin_dcmwd2_test_190_overclock.bit @ board #62-0017.
If this runs stable for a day or two, I probably should cancel my RMA request.
Thank you makomk.

shortfin_dcmwd2_test_190_overclock.bit:


shortfin_dcmwd4c_ed_test_200_overclock.bit:

[ShadesOfMarble]

@hm please keep us updated.

[hm]

shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:


the drop was caused by a cgminer crash.



perhaps i should flash 190mh bitstream to fpga2/3 to get better U/m results on ICA 1.

[Doff]

2.6.3 has a bug that makes it segfault after a certain amount of time, 2.6.4 doesn't have that bug in it.

[hm]

thank you Doff, updated to 2.6.4.

edit: 1h15m running cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:

Code:

 cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):344.2 (avg):792.5 Mh/s | Q:236  A:834  R:4  HW:0  E:353%  U:10.4/m
 TQ: 0  ST: 4  SS: 0  DW: 50  NB: 14  LW: 1601  GF: 0  RF: 0
 Connected to http://mining.eligius.st:8337 with LP as user
 Block: 000004a396dc614ecfd9419f9a7f0dd9...  Started: [01:07:34]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 398.8/397.4Mh/s | A:456 R:2 HW:0 U:5.67/m
 ICA 1:                | 398.6/397.8Mh/s | A:379 R:2 HW:0 U:4.71/m
--------------------------------------------------------------------------------

 [2012-08-13 01:05:17] Accepted 9135665a.5f85ee88 ICA 0
 [2012-08-13 01:05:34] Accepted ba914994.b8bd0df3 ICA 1
 [2012-08-13 01:05:35] Accepted be1cf531.aa60e9a9 ICA 0
 [2012-08-13 01:05:41] Accepted 75836e8b.04df23e9 ICA 1
 [2012-08-13 01:05:47] Accepted a6aa3caf.d5f50486 ICA 0
 [2012-08-13 01:05:48] Accepted ff0f5fe5.27d88c89 ICA 0
 [2012-08-13 01:05:50] Accepted c2235c3e.8fd2d100 ICA 0
 [2012-08-13 01:05:50] Accepted 08d131d0.4629ffef ICA 0
 [2012-08-13 01:05:51] Accepted 6084d797.7a355cf2 ICA 1
 [2012-08-13 01:06:19] Accepted 5083cfc3.374f42cd ICA 0
 [2012-08-13 01:06:19] Accepted bab5e764.5d3716ff ICA 1

power consumption of the psu is just below 46W, using an usb cable with disabled power line.

[Lethos]

Going to give the 210 Bitstream a go today. Great work Makomk.

Not having much luck with the 210 bitstream, going to move back to the new 200 one by your Makomk. I've found it to be a little more stable.
The 210 has brillant results for about 3-4 hours, but once left unattended over night, It had the lame duck effect, where one half would start mining at about half capacity.

[steamboat]

update:

flashed the boards to the dcm4d200 bitstream, and after 24 hours 8 boards are chugging away @ an avg of U: 5.4, and one pair of chips on one board is @ 4.12. much more stable than the pre-dcm 190 bitstream i was using before. Very happy and can't wait for you guys to release an update. /cheers

[toxicocean]

I'm currently using 2 different bitstreams on my #0005 board: shortfin_eb_test_210_overclock.bit on p0 and p1, and shortfin_icarus_cm1_test_190_overclock.bit on p2 and p3. 210 Did great for a while on all 4, but after a few hours 2 FPGA's would stop performing work, so I switched those back to the 190 bitstream.

Stats with this setup:
(5s):770.2 (avg):774.7 Mh/s | Q:11545  A:26708  R:190  HW:0  E:231%  U:10.6/m
ICA0                | (5s):400.8 (avg):395.2 Mh/s | A:13732 R:102 HW:0 U:5.5/m
ICA1                | (5s):378.5 (avg):379.5 Mh/s | A:12978 R:88 HW:0 U:5.2/m

pool reports 771 Mhash/s

[hm]

cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:

Code:

 cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):977.7 (avg):795.8 Mh/s | Q:3039  A:10706  R:65  HW:0  E:352%  U:9.7/m
 TQ: 0  ST: 4  SS: 1  DW: 545  NB: 120  LW: 20703  GF: 4  RF: 4
 Block: 00000630832d26eb96ea5b5c6b6fb89b...  Started: [17:53:05]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 396.2/398.0Mh/s | A:5863 R:29 HW:0 U:5.30/m
 ICA 1:                | 397.8/397.8Mh/s | A:4843 R:36 HW:0 U:4.38/m
--------------------------------------------------------------------------------

3 hour average	691.17 MH/s
15 minute average	706.28 MH/s

[ebereon]

cgminer 2.6.4, shortfin_dcmwd4c_ed_test_200_overclock.bit @ board #62-0017:

Code:

 cgminer version 2.6.4 - Started: [2012-08-12 23:47:49]
--------------------------------------------------------------------------------
 (15s):977.7 (avg):795.8 Mh/s | Q:3039  A:10706  R:65  HW:0  E:352%  U:9.7/m
 TQ: 0  ST: 4  SS: 1  DW: 545  NB: 120  LW: 20703  GF: 4  RF: 4
 Block: 00000630832d26eb96ea5b5c6b6fb89b...  Started: [17:53:05]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 396.2/398.0Mh/s | A:5863 R:29 HW:0 U:5.30/m
 ICA 1:                | 397.8/397.8Mh/s | A:4843 R:36 HW:0 U:4.38/m
--------------------------------------------------------------------------------

3 hour average	691.17 MH/s
15 minute average	706.28 MH/s

@hm
Please watch the LED's on ICA 1, sometimes one of the both fpga's should show you a orange LED for "some" seconds. On my boards is mostly the second fpga. Flash only this fpga with the dcmwd2 190Mhz bitstream and the ICA 1 should have around 5.2 U.

The dcmwd2 have the best DCM Watchdog and will work better on fpga's with the dcm problem which is ICA 1 on your board.

Give it a try, i'm sure your board will be much more stable in the average Mh.

[ebereon]

Update for 10 boards with makomk's bitstreams wd4c 200, 210 and 220(special from makomk) !!!Attention! Please use with caution!!!.

I have optimiced every fpga for it's best bitstream version and this is a 4 hours run with cgminer:

Code:

 cgminer version 2.6.4a - Started: [2012-08-13 18:06:46]
--------------------------------------------------------------------------------
 (5s):9372.2 (avg):8165.4 Mh/s | Q:6029  A:29736  R:340  HW:0  E:493%  U:112.0/m
 TQ: 0  ST: 22  SS: 0  DW: 1549  NB: 29  LW: 54437  GF: 25  RF: 0
 Connected to http://xxxxxxxxxxxxxxxxx:xxxx with LP as user xxxxxxxxxx
 Block: 0000072baf258bce9edfb9fd104b3549...  Started: [22:25:17]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA  0:                | 415.9/420.3Mh/s | A:1547 R:14 HW:0 U:   5.83/m
 ICA  1:                | 400.3/401.2Mh/s | A:1508 R:21 HW:0 U:   5.68/m
 ICA  2:                | 413.3/414.5Mh/s | A:1519 R:18 HW:0 U:   5.72/m
 ICA  3:                | 407.6/409.8Mh/s | A:1496 R:20 HW:0 U:   5.64/m
 ICA  4:                | 410.0/408.9Mh/s | A:1491 R:14 HW:0 U:   5.62/m
 ICA  5:                | 427.3/420.1Mh/s | A:1553 R:17 HW:0 U:   5.85/m
 ICA  6:                | 411.1/410.9Mh/s | A:1542 R:17 HW:0 U:   5.81/m
 ICA  7:                | 413.3/412.1Mh/s | A:1438 R:17 HW:0 U:   5.42/m
 ICA  8:                | 407.9/410.4Mh/s | A:1540 R:12 HW:0 U:   5.80/m
 ICA  9:                | 399.0/399.5Mh/s | A:1419 R:15 HW:0 U:   5.35/m
 ICA 10:                | 409.6/413.1Mh/s | A:1510 R:15 HW:0 U:   5.69/m
 ICA 11:                | 414.3/411.4Mh/s | A:1503 R:19 HW:0 U:   5.66/m
 ICA 12:                | 403.1/405.8Mh/s | A:1466 R:27 HW:0 U:   5.52/m
 ICA 13:                | 399.2/399.2Mh/s | A:1404 R:18 HW:0 U:   5.29/m
 ICA 14:                | 407.7/409.4Mh/s | A:1502 R:10 HW:0 U:   5.66/m
 ICA 15:                | 399.8/400.0Mh/s | A:1432 R:12 HW:0 U:   5.39/m
 ICA 16:                | 401.9/400.0Mh/s | A:1449 R:13 HW:0 U:   5.46/m
 ICA 17:                | 411.6/409.9Mh/s | A:1469 R:18 HW:0 U:   5.53/m
 ICA 18:                | 411.9/408.6Mh/s | A:1513 R:18 HW:0 U:   5.70/m
 ICA 19:                | 400.6/400.7Mh/s | A:1436 R:25 HW:0 U:   5.41/m
--------------------------------------------------------------------------------

Pool reports a 60 minutes average of 8115Mh/s.

A full optimisation is only doable with MPBM. MPBM tells you on an invalid share which FPGA have produced it. It is the second last digit on the share, 0-7 means FPGA0, 8-9+a-f means FPGA1(Thanks to TheSeven for this information!) on that specific pair. If you get a freezing unit, you will notice it when after some hours/days a unit falls under 5 U and more, you have to watch the pair and you will see one of the both FPGA's will have a orange LED for some seconds. This FPGA need a "lower" bitstream or if it is still freezing with the 190 wd4c bitstream, take the dcmwd2 190 bitstream.

As you see on my boards, all running 200Mh+ bitstreams.

Thank you again to makomk for nice success with the ICARUS modified sources!

eb