Cairnsmore1 - Quad XC6SLX150 Board

[LazyOtto]

...
Can you provide any update on how 'the second half of September' orders are being processed, please?

...

Thank you.

[1714223381]

1714223381

[1714223381]

1714223381

[1714223381]

1714223381

[bitcowok]

My payoff calcs results:

constants used:
Electricity here is A$0.21 per kwh
Bitcoin price: $10/BTC
Block reward: 25 (i realise we still have a few months to go)

Days till block reward quartering (to 12.5): ~1590
Max Difficulty for payoff within 1590 Days: ~6,000,000

[LazyOtto]

My payoff calcs results:

...
Max Difficulty for payoff within 1590 Days: ~6,000,000

The model I'm using has that difficulty reached by June 2013.

And ~14 million by January 2014.

Sure would be nice if I'm too pessimistic there, but I rather doubt that.

[makomk]

There's probably a fair few sources of suitable ready-made cables out there because they're used (for instance) to connect Atmel AVR programmers to development boards and those are insanely popular with electronics hobbyists. At least, it looks like a 2x5 pin 2.54mm/0.1inch pitch IDC connector to me.

[hm]

sn#62-0017
dcmwd4c_200 @ fpga0, fpga1, fpga2
dcmwd2_190 @ fpga3
2012-08-16 .. 2012-08-19:





because of the drop in the graph at 20120818 12:00 and all fpgas having orange LEDs for some seconds over and over again, I repowered the board and restarted cgminer, which helped a little bit...


---
As I marked in the graph, I then reverted to dcmwd4c_200 ... this still has the highest hash rates on my board, though the average is still not near 800MHash/s. no cgminer output for this because it didn't differ much from my past tests using dcmwd4c_200@all.
---
Now I'm trying this:
dcmwd4c_200 @ fpga0, fpga1, fpga3
dcmwd2_190 @ fpga2

Code:

 cgminer version 2.7.0 - Started: [2012-08-20 19:16:23]
--------------------------------------------------------------------------------
 (5s):833.5 (avg):3505662362.3 Mh/s | Q:9797  A:22936  R:163  HW:0  E:234%  U:8.2/m
 TQ: 0  ST: 3  SS: 9  DW: 190  NB: 318  LW: 84059  GF: 11  RF: 24  WU: 11.1
 Connected to http://mining.eligius.st:8337 with LP as user 
 Block: 000001848c9a679e716cb61cdafd508f...  Started: [17:57:47]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 398.3/398.9Mh/s | A:15380 R:100 HW:0 U: 5.48/m
 ICA 1:                | 392.7/3505661963.3Mh/s | A: 7556 R: 63 HW:0 U: 2.69/m
--------------------------------------------------------------------------------

I'm asking myself if I should accept these results because of development nature of the board, or if I should re-request RMA for the board at the coming weekend. What do you think? Any hints for improving results, besides of "try every possible bitstream combination of dcmwd2 & dcmwd4c"?

[spiccioli]

sn#62-0017

Code:

 cgminer version 2.7.0 - Started: [2012-08-20 19:16:23]
--------------------------------------------------------------------------------
 (5s):833.5 (avg):3505662362.3 Mh/s | Q:9797  A:22936  R:163  HW:0  E:234%  U:8.2/m
 TQ: 0  ST: 3  SS: 9  DW: 190  NB: 318  LW: 84059  GF: 11  RF: 24  WU: 11.1
 Connected to http://mining.eligius.st:8337 with LP as user 
 Block: 000001848c9a679e716cb61cdafd508f...  Started: [17:57:47]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 398.3/398.9Mh/s | A:15380 R:100 HW:0 U: 5.48/m
 ICA 1:                | 392.7/3505661963.3Mh/s | A: 7556 R: 63 HW:0 U: 2.69/m
--------------------------------------------------------------------------------

I'm asking myself if I should accept these results because of development nature of the board, or if I should re-request RMA for the board at the coming weekend. What do you think? Any hints for improving results, besides of "try every possible bitstream combination of dcmwd2 & dcmwd4c"?

hm,

boards running the 190 MH/s bitstream should have a U: around 5.00-5.30

From your images it is clear that a couple of your FPGAs are not working well, U: less than 3.

I'd try with dcmwd2 150-160 MH/s to see what happens.

spiccioli

[Lethos]

When I switch over between using different bitstream, I've got better results now doing a pre-emptive erase.
I did this the first time, when I started using hashvoodoo bitstream.
https://bitcointalk.org/index.php?topic=78239.msg1110647#msg1110647

Same principle might help others moving between other bitstreams, if you've been flash over and over different ones a lot.

[makomk]

I'm asking myself if I should accept these results because of development nature of the board, or if I should re-request RMA for the board at the coming weekend. What do you think? Any hints for improving results, besides of "try every possible bitstream combination of dcmwd2 & dcmwd4c"?

I'm in the process of testing a new bitstream which should improve matters a lot. Stay tuned!

[makomk]

OK. I think I've managed to track down an issue in my previous bitstreams which sometimes caused them to fall over and stop producing shares after a while. You can find the fixed bitstreams at: http://www.makomk.com/~aidan/shortfin-dcmwd4e-20120822.7z They should hopefully reach the same initial hashrates and invalid rates as the dcmwd4c ones did, except without the long-term stability issues that plagued those. Again, this issue affects all my previous bitstreams and for maximum stability I recommend that everyone who's using any of them upgrades to the new ones when it's convenient to do so. Plus, the 210 MHz and 220 MHz bitstreams might actually be usable this time around!

(It appears some - though not all - of the problems I was blaming on the DCM were actually caused by me failing to change a synthesis option that needed changing, meaning a particular finite-state machine was less robust than it needed to be and kept getting wedged in an invalid state. Whoops.)

[Lethos]

OK. I think I've managed to track down an issue in my previous bitstreams which sometimes caused them to fall over and stop producing shares after a while. You can find the fixed bitstreams at: http://www.makomk.com/~aidan/shortfin-dcmwd4e-20120822.7z They should hopefully reach the same initial hashrates and invalid rates as the dcmwd4c ones did, except without the long-term stability issues that plagued those. Again, this issue affects all my previous bitstreams and for maximum stability I recommend that everyone who's using any of them upgrades to the new ones when it's convenient to do so. Plus, the 210 MHz and 220 MHz bitstreams might actually be usable this time around!

(It appears some - though not all - of the problems I was blaming on the DCM were actually caused by me failing to change a synthesis option that needed changing, meaning a particular finite-state machine was less robust than it needed to be and kept getting wedged in an invalid state. Whoops.)

Awesome news Makomk, would love to try, but just changed over to hashvoodoo. Kinda like now I got it stable, not a single error, also it mean having to revert back to the original controller right?
It is very tempting that higher rate though.

[makomk]

Awesome news Makomk, would love to try, but just changed over to hashvoodoo. Kinda like now I got it stable, not a single error, also it mean having to revert back to the original controller right?
It is very tempting that higher rate though.

Yeah, it does require reverting back to the 1.3 or 1.5 controller. No doubt ebereon and others will have some news as to how stable it is in a day or two, might be worth waiting until then. (Glasswalker will probably also be coming out with faster bitstreams at some point but he's really busy right now.)

[Lethos]

btw I found 2.71 to be a good upgrade atleast for me (hashvoodoo175oc bitstream).
I swear it's increased my average hash rate by about 5-10%. 1400 -> 1500
Will give it another 12 hours, but it appears to be performing very well.

[gyverlb]

Yeah, it does require reverting back to the 1.3 or 1.5 controller. No doubt ebereon and others will have some news as to how stable it is in a day or two, might be worth waiting until then. (Glasswalker will probably also be coming out with faster bitstreams at some point but he's really busy right now.)

In fact it seems to run fine on the original (1.1?) controller. As my 2 boards were crashed when you posted your new version, I tried it. I'll have to wait 24h to know if its more stable (usually utility goes down within 24h meaning FPGAs are going down one after another).

[hm]

thank you, makomk, I appreciate your work. the new bitstream will stop my whining for a short time...

dcmwd4e_ed_test_200 @ all four fpga of board #62-0017 running for 16 hours:
still no 5.6 U/m @ ICA1... I'll let it run another day to have a better base for the stats...

Code:

 cgminer version 2.7.0 - Started: [2012-08-23 02:13:30]
--------------------------------------------------------------------------------
 (5s):1050.6 (avg):795.4 Mh/s | Q:17911  A:9777  R:45  HW:0  E:55%  U:10.0/m
 TQ: 0  ST: 3  SS: 0  DW: 380  NB: 108  LW: 0  GF: 22  RF: 1  WU: 11.3
 Connected to http://pool.50btc.com:8332 with LP as user 
 Block: 0000017b391822c95719fa9889eaa756...  Started: [18:21:20]
--------------------------------------------------------------------------------
 [P]ool management [S]ettings [D]isplay options [Q]uit
 ICA 0:                | 400.4/397.6Mh/s | A:5399 R:26 HW:0 U: 5.52/m
 ICA 1:                | 399.8/397.8Mh/s | A:4378 R:19 HW:0 U: 4.48/m
--------------------------------------------------------------------------------

sometimes there are simultaneous orange flashes @ fpgas 2+3 (ICA1).

[makomk]

sometimes there are simultaneous orange flashes @ fpgas 2+3 (ICA1).

Ah, normally that means that the FPGAs aren't being fed new work fast enough. It might help to add "--icarus-timing=2.4" to the cgminer command line. Also, does cgminer complain about not getting work from your pool fast enough?

[hm]

makomk,
I use "--icarus-timing long".
I remember cgminer complaining about not getting work fast enough, but I didn't see this with the 200mhz bitstreams but with 210 and 220 which have way lower U/m than the dcmwd4c/4e-200 on my board. I can't say for sure though because I don't use cgminer logfile.

[spiccioli]

Hi makomk,

this is board sn #132 with your latest bitstream dcmwd4e 210 MH/s running since yesterday 10 pm CET.

Code:

 ICA 16:                | 419.6/419.1Mh/s | A:3883 R:2 HW: 24 U: 5.88/m
 ICA 17:                | 414.8/415.6Mh/s | A:3801 R:3 HW:104 U: 5.76/m

The 220 MH/s one does not work, a pair of FPGAs dies as soon as it starts.

It has a higher invalid count, though, in particular ICA 17

spiccioli.

[daemonic]

I would just like to thank all that have been working on the bitstreams and such, ive been away for a month (a weeks holiday and then waiting on my rma return, etc).

Flashed the 2 new boards to controller 1.5 and shortfin_dcmwd4e_ed_test_200_overclock.bit for the hour that both have been running, i have average Utility per pair of 5~5.5, which seems pretty good to me, such a change from my poorly board before

For anyone that has done the up/down cable, is there anything special i need to change in my run commands? I know i have to connect the cable and set the master/slave dip, but is that it, does the dual stack just present as 8 com port as it would do individually?

[steveme]

Hi everybody - I'm having some problems with my cm1 board (arrived today)

Here's what I did:

Plugged it all in and installed the drivers (Win7 X64) - all ports, etc. created ok

Tried cgminer to com ports 25-28 - nothing working - I assumed it was because the shipping controller runs at 57600 and cgminer assumes 115200 (i read that on the thread)

Used spiprog.exe to update to controller 1.5 - 0 errors and flashing red controller led,so disconnected usb and psu to cm1 and reconnected with all dip switchs on. led still flashing (?)

The red controller led stops flashing if the board is back in programming mode (sw3 & sw6 off), but isn't responding at all

Do I need a JTAG cable to reprogram the controller?

[Glasswalker]

For anyone that has done the up/down cable, is there anything special i need to change in my run commands? I know i have to connect the cable and set the master/slave dip, but is that it, does the dual stack just present as 8 com port as it would do individually?

The way it currently works with the newest controllers is:

Previously you had 4 ports per board, but only 2 of them were used for mining (1 port for each Icarus Style Pair of chips).
With the new ribbon cable in place, the second board uses the other 2 ports on the first. So you plug the USB into one board, chain a second board off of it, and use all 4 ports (each port representing 2 chips Icarus style).

Does that help?

Other than following the instructions from Enterpoint (I believe some dip settings) there is nothing else fancy you need to do, just use it like normal, just use all 4 ports instead of just 2.

Hope that helps!