Cairnsmore1 - Quad XC6SLX150 Board

[steamboat]

Short Info about Makomk's new bitstreams:

I'm using dcmwd4e bitstreams from 200 to 220Mh on 50 boards with controller rev. 1.5 now. Invalids reach from 0.0% up to max. 3%.
And again i got "tested" USB cables from enterpoint and 3! not working with controller 1.5 but with 1.3?!?...

One hour average reported from pool is 42.44GH/s (~848Mh/Board).

Update Power Consumption:
50x CM1(every FPGA! opticed with dcmwd4e bitstream to reach <3% invalids in MPBM)
1x PDB
3x LogiLink 10 Port USBHub (12,95€)
5x PSU Super-Flower SF650P14XE Golden Green Pro 80plus gold - 54 Ampere max. on 12V
2x ASUS Netbook (Win7 32bit, 1GB, Atom N450/Atom N2600) ... I can't run all 50 boards on one Win7 Netbook, Interupts taking up to 100% CPU :-/  ... I think I have to switch to Linux...
2x Windmachines (30cm(50W) + 45cm(130W) Fans) I need this at the moment to keep temps in the rig-room at 28°C. Without it I had temps 38°C-44°C in this room(Window open!). But I will move the rigs to a room in the basement(cellar).
----------
Total: 2212 Watt @ 224 Volt

eb

848? I'm getting an avg of just under 800 per board using the newest 210 stream.

[1714113085]

1714113085

[1714113085]

1714113085

[1714113085]

1714113085

[1714113085]

1714113085

[ebereon]

Update on latest bitstreams:
Total 200 FPGA's = 40 boards SN#550+ and 10 boards SN#400+.
Controller rev. 1.5.

Makomk's dcmwd4e oc bitstreams 3 day's running:
107x 220Mh, 68x 210Mh, 25x 200Mh. That means 100% of all fpga's running @200Mh+ with <3% invalids!

Working bitstreams in percent:
220Mh oc = 53,5%
210Mh oc = 87,5%
200Mh oc = 100%


Glasswalker's bitstream:
No futher tests until it is a bitstream up to 220Mh available!
175Mh oc = 100% (only short test about 2 hours)

eb

[ebereon]

848? I'm getting an avg of just under 800 per board using the newest 210 stream.

Yes, this is the average per board of my 50 boards. I have ~ 26 boards that run at 880Mh (4x220Mh)!

I'm sure some of your FPGA's have a huge amount of invalids. AFAIK cgminer don't show you the invalids, which is suboptimal. I use MPBM and it shows you easyly the invalid shares and also the info which FPGA of the pair have produced the invalid. So you can easy optimice every FPGA to it's best bitstream with very low invalids.

eb

PS: Here is my average MH from my pool:

[gigantic]

where can i download 200Mh oc/ dcmwd4e oc ?  

Thanks

[ebereon]

where can i download 200Mh oc/ dcmwd4e oc ?  

Thanks

Makomk have it in his forum sig 

[Keninishna]

848? I'm getting an avg of just under 800 per board using the newest 210 stream.

Yes, this is the average per board of my 50 boards. I have ~ 26 boards that run at 880Mh (4x220Mh)!

I'm sure some of your FPGA's have a huge amount of invalids. AFAIK cgminer don't show you the invalids, which is suboptimal. I use MPBM and it shows you easyly the invalid shares and also the info which FPGA of the pair have produced the invalid. So you can easy optimice every FPGA to it's best bitstream with very low invalids.

eb

PS: Here is my average MH from my pool:

nice... what version of mpbm are you using? I know you made your own miner but did it ever make it to the official source? Also how long does it take you to program all your boards? Do you do a batch flash? Thanks for the help. Also pics of that 50 board setup you have?

[gigantic]

where can i download 200Mh oc/ dcmwd4e oc ?  

Thanks

Makomk have it in his forum sig 

Thanks,
and Congratulations?   :-)

[ebereon]

nice... what version of mpbm are you using? I know you made your own miner but did it ever make it to the official source? Also how long does it take you to program all your boards? Do you do a batch flash? Thanks for the help.

I use the testing git with my worker, but it's the same as the Icarus worker, nothing special.

I do only load it to the FPGA's at the moment. If I find the time I will flash them.
How I know what bitstream is on which FGPA? In MPBM I have named every Worker(pair) like this:
"CM20 SN#62-408 | wd4e | 220/210 | 0"       <- That means pair 0+1, 0 have 220Mh, 1 have 210Mh bitstream.
"CM22 SN#62-409 | wd4e | 200/210 | 3"       <- That means pair 3+2, 3 have 200Mh, 2 have 210Mh bitstream.

So when I have time to flash (7minutes on ubuntu per board) I know which bitstream I need to flash to every fpga.
My command line to load only looks like:
sudo xc3sprog -c cm1 -p0 {bitstreamname} && sudo xc3sprog -c cm1 -p1 {bitstreamname} && sudo xc3sprog -c cm1 -p3 {bitstreamname} && sudo xc3sprog -c cm1 -p2 {bitstreamname}

eb

[ebereon]

How to optimice bitstream on every FPGA using MPBM:

First of all, set up MPBM with all boards(Workers), name them as I did with SN# and such and one worksource. And let it run!

Now load all FPGA's on the board with 220 dcmwd4e bitstream, if you have many boards, load all boards first with the 220Mh:

• 0. set the logwindow settings in MPBM to 200!
• 1. connect the USB to your flashing machine
• 2. SWITCH3 off
• 3. SWITCH1 off and on to reset the board
• 4. wait for the bitstream loaded from SPI to the FPGA's (light blue LED)
• 5. fire up: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname220} && sudo xc3sprog -c cm1 -p2 {bitstreamname220}
• 6. wait 10 seconds(ubuntu!) and it should be done
• 7. SWITCH3 on
• 8. connect the USB to your mining machine
• 9. look on MPBM, it should reconnect this unit automaticaly!
• 10. watch the invalids for 10 minutes!
• 11. note the pairs which have >55% invalids - if the invalids are lower start with 14.
• 12. load the next slower bitstream only to this pair(start again as described above with 1. ) , you must load all 4 like: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname210} && sudo xc3sprog -c cm1 -p2 {bitstreamname210}
• 13. repeat 2. -12. until invalids <55%
• 14. now we have only <55% invalids
• 15. as you see every invalid logged in MPBM log window
• 16. note only one pair(Worker) at a time in a text editor like: "CM54 SN#62-564 | 220/220 | wd4e | 08-rig2 | 3:    Got K-not-zero share 721e2931" search for this pair and note them up to 10 times
• 17. now you have 10 lines in you text editor, the second last digit of the invalid share tells you which FPGA is it. 0-7 = FPGA0 -- 8-9+a-f = FPGA1
• 18. I have now the above line like "CM54 SN#62-564 | 220/220 | wd4e | 08-rig2 | 3:    Got K-not-zero share 721e2931  ->0"  (this is FPGA0 as the second last digit is the "3", do this and count how many invalids shares have FPGA0 or FPGA1 on that one pair
• 19. load the next slower bitstream only to this FPGA!, you must load all 4 like: sudo xc3sprog -c cm1 -p0 {bitstreamname220} && sudo xc3sprog -c cm1 -p1 {bitstreamname220} && sudo xc3sprog -c cm1 -p3 {bitstreamname210} && sudo xc3sprog -c cm1 -p2 {bitstreamname200}
• 20. repeat 16. -19. until invalids <3% (Edited, sry I forgot this...)
  
• 21. All this can take time, it took me 1 hour for 10 boards
• 22. You are done optimicing every fpga  

I hope I didn't forget a step  

Attention! Do not let it run for hours with invalids >20% !!! It can damage the FPGA's with that amount! It's like overclocking a CPU and let it run while it have errors!

While you doing all this with a separate flashing machine, MPBM is mining away with every board connected exept the one you load at this one moment. This is very nice and the advantage of MPBM compared with cgminer/bfgminer.

I hope this helps a bit  

eb

PS: For better understanding how you have to count the invalids on a pair(this have 4,5%), here is what I note in the text editor:

Code:

CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 8b318881	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 99fe4dbe	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share fb6d419e	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 8e2469b9	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 6beffd87	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 5951eecd	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 5f4fa9ae	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share ed6444dd	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share a5fca58b	1
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 1518088d	1

CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share b90e3421	0
CM31 SN#62-406 | 210/220 | wd4e | 05-rig1 | 0: 	Got K-not-zero share 86a3044d	0

You see FPGA1 have 10 invalids, FPGA0 only 2, so I have to load a lower bitstream on FPGA1. FPGA0 is ok with only 2 invalids in the same time.

[Keninishna]

This new version of mpbm is working well for me. Definitely helps to see which boards are producing invalids but I would switch to a slower bitstream if the error rate is above even 5% because at that point its as slow as the next bitstream down anyways. Thanks for the help eb.

[ebereon]

This new version of mpbm is working well for me. Definitely helps to see which boards are producing invalids but I would switch to a slower bitstream if the error rate is above even 5% because at that point its as slow as the next bitstream down anyways. Thanks for the help eb.

Well, thats why I'm said until <3%
Sorry, I forgot this step lol! Post edited, thanks Keninishna! 

[Keninishna]

Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work.

[gigantic]

Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work.

what exactly do you mean by getwork connections? do you mean the getwork timeout? or the job fetching connections maybe?

[Keninishna]

Also I noticed in mpbm that my workers under the work source would go from my pool to null status and the fpga leds would turn orange. I went under the work source settings and set the getwork connections from 1 to 3 and now my fpgas are flllyyying and no longer are waiting for work.

what exactly do you mean by getwork connections? do you mean the getwork timeout? or the job fetching connections maybe?

Sorry, I forgot the exact wording but Job fetchter connections.

[hm]

Code:

 cgminer version 2.7.0 - Started: [2012-08-23 02:13:30]
--------------------------------------------------------------------------------
 (5s):368.3 (avg):797.2 Mh/s | Q:133386  A:71374  R:332  HW:0  E:54%  U:9.7/m
 TQ: 0  ST: 3  SS: 1  DW: 2761  NB: 787  LW: 0  GF: 115  RF: 6  WU: 11.1
 Connected to http://pool.50btc.com:8332 with LP as user
 Block: 000004ff4340c97b50e0a7d4bf7ac798...  Started: [04:11:09]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 403.5/398.8Mh/s | A:39039 R:188 HW:0 U: 5.32/m
 ICA 1:                | 399.8/398.4Mh/s | A:32335 R:144 HW:0 U: 4.41/m
--------------------------------------------------------------------------------

20120828 04:30 - stop cgminer

Code:

 cgminer version 2.7.0 - Started: [2012-08-28 04:31:23]
--------------------------------------------------------------------------------
 (5s):749.6 (avg):793.3 Mh/s | Q:16444  A:8514  R:29  HW:0  E:52%  U:9.4/m
 TQ: 0  ST: 3  SS: 0  DW: 376  NB: 94  LW: 0  GF: 23  RF: 1  WU: 11.1
 Connected to http://pool.50btc.com:8332 with LP as user
 Block: 00000012c6c47dc749525c7b182e6036...  Started: [19:31:45]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 401.6/397.5Mh/s | A:4832 R:15 HW:0 U: 5.35/m
 ICA 1:                | 399.1/395.9Mh/s | A:3685 R:14 HW:0 U: 4.08/m
--------------------------------------------------------------------------------

20120828 19:35 - stop cgminer


(spikes around 3:00 are caused by the mining pool.)

makomk's 200 dcmwd4e @ #62-0017 is running stable but still with problems at ICA1.
For some days now, I didn't have time to test other bitstreams.

[rocks]

Hi Yohan,

Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?

Thanks!

[yohan]

Hi Yohan,

Just curious if you have an updated ETA for when the boards will be available again. Is October still expected?

Thanks!

We are aiming for October as a general availability again but I can't be precise at the moment of what date in October. A lot depends on how fast we satisfy our existing pre-order list and we are working our way though those orders now. It also depends on supplies of FPGA and other components. What we are aiming to do from October is to have some level of stock boards but if we get large purchases we will have short periods where boards are on some sort of lead time as we manufacture another batch.

[rocks]

Great, thanks for the update.

Now that Makomk, TheSeven and Glasswalker worked out a high performing bitstream, I'm glad to hear this will become a regularly stocked item (and suspect others are as well).

[ocminer]

How can I read out Invalids per ICA in CGMiner instead of MPBM ? Or are these included in the HW: (Hardware Error) count ?

[ebereon]

How can I read out Invalids per ICA in CGMiner instead of MPBM ? Or are these included in the HW: (Hardware Error) count ?

They are Hardware Errors, but you can't read them out at the moment. Even with the source patch which is available somewhere it have some bugs and count it wrong.

Only with MPBM you can count invalids correctly and also count per FPGA, not only per pair (Makomk bitstream).

eb