Cairnsmore1 - Quad XC6SLX150 Board - page 34.

gyverlb

hero member

Activity: 896

Merit: 1000

Quote from: yohan on August 14, 2012, 09:10:51 AM

We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok.

Any news for flashing this with Linux? It's the only thing I can't do right now and all the bitstreams I've tried (yours and makomk's) aren't stable at all. The serial interfaces die after some time (most of the time on #62-110) and there's nothing I can do short of cutting the power to reset the board.

As I'm not always next to them, considering all the downtimes my current mean hashing speed isn't event 800MH/s for *2* boards. I would even be glad if I could have this speed with stability, currently I must check on these boards on an hourly basis...

spiccioli

legendary

Activity: 1378

Merit: 1003

nec sine labore

Quote from: yohan on August 14, 2012, 09:10:51 AM

We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok. The main feature of this build is the first usage of the up/down cabling and it is a very simple implementation that we have done to use it. With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave. So long and short of it is that you get to use half the USB cables that you needed previously.

If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.

We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.

We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.

700 boards!! Good accomplishment, that's half a TH with current bitstreams!

spiccioli

PS. Apropos usb power: I'm using now a powered (but I don't power it) no-name 10 ports usb hub which works very well because it does not take power from its usb cable (I don't know if it has no power wire inside) and/or it does not deliver the power it takes to its own usb ports.
I believe it has to be like this because I cannot attach more than three boards to my host PC if I don't power them (PC freezes) while right now I have all of them connected and hashing happily since at least a couple of weeks.
So, I'd say, cutting the power line should make things easier for new users.

yohan

sr. member

Activity: 462

Merit: 251

We should be making Rev 1.4 of the Controller available later today or tomorrow if our testing today goes ok. The main feature of this build is the first usage of the up/down cabling and it is a very simple implementation that we have done to use it. With Rev 1.4 you have the option to pair up boards to use a single USB interface. On the Master board all 4 com ports are used to support 4 pairs of FPGA 2 pairs on the Master and 2 pairs on the Slave. So long and short of it is that you get to use half the USB cables that you needed previously.

If you don't want to use up/down cabling Rev 1.4 will operate pretty much as Rev 1.3. There is 1 dip switch change for Master/Slave selection but otherwise pretty much what you have seen in Rev 1.3.

We are still looking at the implementation of more complicated schemes that will use up/down for either bigger board clusters or even an entire rig and that will come later. Meanwhile the Rev 1,4 will hopefully make it a bit simplier on the USB setup for all of you with multiple boards setups.

We are also experimenting with removing the power feed from USB to the controller to see if it is just better to power the Controller always from the 12V feed. There is a possibility that might cause an ennumeration issue so it's not confirmed we will do this yet but if does look the better configuration we will cut that in to production on boards serial number 0700+.

We are also closing the general pre-order now with the general intention that it will become a stocked item from October onwards. Large orders will possibly still have a lead time and also tend to clean out available stock so it won't always be immediately available.

hm

member

Activity: 107

Merit: 10

Quote from: ebereon on August 13, 2012, 01:50:59 PM

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.

Thanks for the tip, ebereon. Just to make sure I understood correctly:
I should not flash both FPGAs of ICA1 but only the one that's orange LED is active more often.
Since the orange LEDs of both FPGAs of ICA1 are active at the same time only on my board, I'll probably just have to try FPGA2=wd4-200 and FPGA3=wd2-190 or flash it the other way around if it doesn't help. Tomorrow I'll perhaps try that if I have the time.

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

Quote from: Lethos on August 13, 2012, 06:24:14 PM

Quote from: Lethos on August 13, 2012, 05:51:16 PM

- Reflashing it via linux atm with a much lesser bitstream. Will update.

Now I'm sitting infront of it, wondering why is it not working. It flashes successfully, for both, but won't mine.
Goona try a few other things, if anyone has a suggestion let me know.

Reflashing with a lower bitstream which also worked fine made no difference. Oh dear...

It appears only temp flashes work now, for board #2 more permanent flashes now don't work.
So, while I don't need fixing it really. Anyone know why this happened and is the only way to fix this is with a JTAG cable right?

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

Quote from: Lethos on August 13, 2012, 05:51:16 PM

- Reflashing it via linux atm with a much lesser bitstream. Will update.

Now I'm sitting infront of it, wondering why is it not working. It flashes successfully, for both, but won't mine.
Goona try a few other things, if anyone has a suggestion let me know.

Reflashing with a lower bitstream which also worked fine made no difference. Oh dear...

misternoodle

member

Activity: 108

Merit: 10

Been running the WD4 200Mh/s bitstream with success.

ICA 1: | 394.7/385.4Mh/s | A:16697 R:159 HW:0 U: 5.39/m
ICA 2: | 387.9/385.5Mh/s | A:16658 R:145 HW:0 U: 5.38/m

Thanks makomk, sent a little tip your way the other day.

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

Okay guys, have a small problem I can't seem to fix.

My Ubuntu rig that I run my 2 CM1's on happily mines away while I do other things on it, like play movies via XBMC.
Today for the first time XBMC decided to crash and nothing would respond, It actually did look like it was still mining so spent 30mins trying to get XBMC to exit but eventually had to resort to pulling the power cord. In hindsight, I could of handled different, but I was running low on options.

I don't blame my other software, like cgminer or anything, just making that clear. They usually coexist fine, have done for many hours of film watching. XBMC is the problem, it looks nice though.

Upon rebooting, 1 board mined fine, the other gave me an error. "Got 0000000, expecting 000187a2" or something, the sort of error I have seen before, but was puzzled this only usually occurs when I do something silly like have left it in the wrong setting.

1) Checked all the settings, all the switches are where they should be.
2) Redid the modprobe command (I had done it once already), no change, also checked the usb #, they are the same.
3) Left it offline for a while, so I could update the working one (yes still works and is abit faster), but still no change.
4) Reflash it via linux, with the bitstream it had before, no change.
5) Reflash the bitstream controller via windows, no change.
- Reflashing it via linux atm with a much lesser bitstream. Will update.

Now I'm sitting infront of it, wondering why is it not working. It flashes successfully, for both, but won't mine.
Goona try a few other things, if anyone has a suggestion let me know.

ebereon

sr. member

Activity: 397

Merit: 500

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

ebereon

sr. member

Activity: 397

Merit: 500

Quote from: hm on August 13, 2012, 12:19:20 PM

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.

hm

member

Activity: 107

Merit: 10

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

toxicocean

newbie

Activity: 24

Merit: 0

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

steamboat

hero member

Activity: 648

Merit: 500

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

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

Quote from: Lethos on August 12, 2012, 05:44:32 AM

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.

hm

member

Activity: 107

Merit: 10

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.

Doff

sr. member

Activity: 327

Merit: 250

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

member

Activity: 107

Merit: 10

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.

ShadesOfMarble

donator

Activity: 543

Merit: 500

@hm please keep us updated.

hm

member

Activity: 107

Merit: 10

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:

Lethos

sr. member

Activity: 476

Merit: 250

Keep it Simple. Every Bit Matters.

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

Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 34. (Read 286370 times)