Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 66. (Read 286370 times)
Thank you for the info
Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).
I'll try using a few different USB cables tomorrow or something.
Norulezapply,
what is your U: number after a few hours on mining?
If your usb hub is not powered I'd try a powered one first.
spiccioli
We have started modelling a mid size mining rig so that we can firstly test boards exactly the way Bitcoiners use them but also so we can see some of the system level problems that some of you get. This is an additional test to our normal testing and we aiming put all line boards through that test. At the moment it's windows based but we will probably run a second rig on LInux as well. We have a few observations about using USB which may help you all get running.
First observation is that powering the 12V first befor plugging in USB is good way to do it.
Our second observation was using a cheap 13 way USB hub we bought to test http://www.ebuyer.com/279682-xenta-13-port-usb2-0-hub-mains-powered-n-uh1301 if we switch off using the switch on the hub until the 12V is up and settled gave good results.
Third observation is that our 20-30 unit test rig took 10-20 minutes to enumerate the USB structure and if you try tio do anything before that is complete one or more boards will get screwed up and you can not do anything to get it back short of doing the entire start up sequence again.
Out of what we saw today we have a couple of ideas to add to the Controller that may help stability with the twin bitstream and we will try those over the next couple of days. If they are of benefit a release of Controller will follow.
Thank you for the info
Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).
I'll try using a few different USB cables tomorrow or something.
Norulezapply,
what is your U: number after a few hours on mining?
If your usb hub is not powered I'd try a powered one first.
spiccioli
I have a powered USB hub.
Here's a "screenshot" from my rig after ~20 hours:
Code:
cgminer version 2.4.3 - Started: [2012-07-13 00:43:11]
--------------------------------------------------------------------------------
(5s):1676.7 (avg):1491.3 Mh/s | Q:6826 A:7881 R:1 HW:0 E:115% U:6.6/m
TQ: 4 ST: 5 SS: 0 DW: 1037 NB: 143 LW: 30811 GF: 0 RF: 0
Connected to ozco.in with LP as user snip
Block: 000007ce5cd122fcfd0163d16d5c742d... Started: [20:21:18]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.9/373.0Mh/s | A:1383 R:0 HW:0 U: 1.16/m
ICA 1: | 379.9/372.6Mh/s | A:1252 R:0 HW:0 U: 1.05/m
ICA 2: | 380.0/373.0Mh/s | A:2624 R:0 HW:0 U: 2.21/m
ICA 3: | 379.8/372.8Mh/s | A:2622 R:1 HW:0 U: 2.21/m
--------------------------------------------------------------------------------
[2012-07-13 20:30:27] Accepted fadb8f39.9ae9fafc ICA 3
[2012-07-13 20:30:28] Accepted d9c24b95.8e05a5fe ICA 1
[2012-07-13 20:30:29] Accepted cd961974.b4c4ca52 ICA 3
[2012-07-13 20:30:47] Accepted b8a4f7f6.46f1c8a1 ICA 3
[2012-07-13 20:30:48] Accepted 63c28bba.b8d6352f ICA 2
[2012-07-13 20:31:05] Accepted 526d5521.fd5beeb7 ICA 0
[2012-07-13 20:31:24] Accepted 28843c4c.7492b005 ICA 3
[2012-07-13 20:31:33] Accepted e1658fd4.fffd4e2d ICA 3
[2012-07-13 20:31:37] Accepted d2409553.dee9a890 ICA 1
[2012-07-13 20:32:04] Accepted 3a072287.dcd450a3 ICA 3
As you can see, ICA 0/1 is running approximately half the speed of ICA2/3.
The lights on the suspect board are orange for a large majority of the time, where as the other board is rarely ever orange.
At first I thought it could help if I ran two separate instances of cgminer but I haven't tried this yet.
Regards
I only have bare details but one bug we appeared to see today on CGminer, running on Win7, was that if the dos box didn't have enough lines defined for the numbers of CM1 s running it caused a problem on the ones that could be fitted in on the bos box. So make sure you have eniough lines in the dos box if you are running a large rig.
Thank you for the info
Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).
I'll try using a few different USB cables tomorrow or something.
Norulezapply,
what is your U: number after a few hours on mining?
If your usb hub is not powered I'd try a powered one first.
spiccioli
Can someone with multiple boards please give me some help with getting both of mine upto speed?
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
Hard to say (at least for me), norulezapply, since you're using a rather "uncommon" platform to mine (raspberry).
Anyway, in my experience, the only difference is in the controller FPGA firmware, 1.3 seems better in achieving an uniform U: across all boards (but you already have it).
Here are mine
-snip-
As you can see I've got a U: around 2.30-2.60, I'm using cgminer 2.4.3 as well on an ubuntu low power pc.
Note that I have a FPGA which is underperforming the others (it is ICA 9 here) and which has always underperformed no matter what controller revision I was using.
I'm starting cgminer like this
-snip-
spiccioli.
Thank you for the info
Seems like your setup is quite similar to mine though (I don't think using the Raspberry Pi should affect anything, but maybe I'm wrong).
I'll try using a few different USB cables tomorrow or something.
EDIT: I am using a powered USB hub - specifically this one : http://www.7dayshop.com/catalog/product_info.php?cPath=777_5&products_id=113169
Can someone with multiple boards please give me some help with getting both of mine upto speed?
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
Hard to say (at least for me), norulezapply, since you're using a rather "uncommon" platform to mine (raspberry).
Anyway, in my experience, the only difference is in the controller FPGA firmware, 1.3 seems better in achieving an uniform U: across all boards (but you already have it).
Here are mine
Code:
cgminer version 2.4.3 - Started: [2012-07-13 07:26:50]
--------------------------------------------------------------------------------
(5s):7513.4 (avg):7328.9 Mh/s | Q:114056 A:41757 R:40 HW:0 E:37% U:50.9/m
TQ: 20 ST: 22 SS: 2 DW: 2324 NB: 107 LW: 311 GF: 90 RF: 1
Connected to http://pool.abcpool.co with LP as user .......
Block: 0000012b95cd60eeffec7427a809b285... Started: [21:02:32]
--------------------------------------------------------------------------------
[P]ool management [S]ettings [D]isplay options [Q]uit
ICA 0: | 379.8/366.8Mh/s | A:2120 R:3 HW:0 U: 2.59/m
ICA 1: | 379.8/366.5Mh/s | A:1976 R:1 HW:0 U: 2.41/m
ICA 2: | 379.9/367.1Mh/s | A:2114 R:2 HW:0 U: 2.58/m
ICA 3: | 379.9/366.7Mh/s | A:2013 R:3 HW:0 U: 2.46/m
ICA 4: | 379.9/366.6Mh/s | A:2108 R:4 HW:0 U: 2.57/m
ICA 5: | 380.0/366.7Mh/s | A:2092 R:1 HW:0 U: 2.55/m
ICA 6: | 379.9/366.2Mh/s | A:2172 R:0 HW:0 U: 2.65/m
ICA 7: | 379.9/366.1Mh/s | A:2139 R:2 HW:0 U: 2.61/m
ICA 8: | 379.8/366.1Mh/s | A:2080 R:1 HW:0 U: 2.54/m
ICA 9: | 379.8/366.4Mh/s | A:1848 R:2 HW:0 U: 2.25/m
ICA 10: | 379.9/365.9Mh/s | A:2092 R:3 HW:0 U: 2.55/m
ICA 11: | 379.8/366.1Mh/s | A:2100 R:5 HW:0 U: 2.56/m
ICA 12: | 379.9/366.4Mh/s | A:2079 R:1 HW:0 U: 2.54/m
ICA 13: | 379.9/366.2Mh/s | A:2192 R:3 HW:0 U: 2.67/m
ICA 14: | 379.7/366.0Mh/s | A:2016 R:3 HW:0 U: 2.46/m
ICA 15: | 379.9/366.8Mh/s | A:2109 R:0 HW:0 U: 2.57/m
ICA 16: | 379.8/366.4Mh/s | A:2141 R:1 HW:0 U: 2.61/m
ICA 17: | 379.8/367.4Mh/s | A:2128 R:0 HW:0 U: 2.60/m
ICA 18: | 379.9/366.2Mh/s | A:2149 R:3 HW:0 U: 2.62/m
ICA 19: | 379.9/366.9Mh/s | A:2090 R:2 HW:0 U: 2.55/m
--------------------------------------------------------------------------------
As you can see I've got a U: around 2.30-2.60, I'm using cgminer 2.4.3 as well on an ubuntu low power pc.
Note that I have a FPGA which is underperforming the others (it is ICA 9 here) and which has always underperformed no matter what controller revision I was using.
I'm starting cgminer like this
Code:
./cgminer -S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7 -S /dev/ttyUSB10 -S /dev/ttyUSB11 -S /dev/ttyUSB14 -S /dev/ttyUSB15 -S /dev/ttyUSB18 -S /dev/ttyUSB19 -S /dev/ttyUSB22 -S /dev/ttyUSB23 -S /dev/ttyUSB26 -S /dev/ttyUSB27 -S /dev/ttyUSB30 -S /dev/ttyUSB31 -S /dev/ttyUSB34 -S /dev/ttyUSB35 -S /dev/ttyUSB38 -S /dev/ttyUSB39 -o http://pool.abcpool.co -O ...... -o http://p2pool.soon.it:9332 -O ..... -Q 20 --failover-only
spiccioli.
edit: is your usb hub powered or unpowered?
Can someone with multiple boards please give me some help with getting both of mine upto speed?
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
I have both boards flashed with the twin_test bitstream and the rev 1.3 controller.
The boards are plugged into a USB hub with two separate USB cables.
I am using a RaspberryPi to run cgminer 2.4.3 and provide work to the boards.
I'm running a SINGLE instance of cgminer 2.4.3 for both boards.
Command line is something like "-S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7". (i'm not using the icarus-timing option)
Dip switches are set to the defaults for the twin_test running mode bitstream.
Can someone please give me a hand to figure out why I'm not getting the full hashrate? I have Skype/MSN if someone would rather speak about it over that.
At first I was just going to wait until the stable bitstream is released, but I figured I may as well fix it now just incase.
Thank you in advance
I have 2 and occassionally I get them up to a total of ~710Mh/s, but most of the time I'm only getting ~520Mh/s average total (so that's 260Mh/s per board).
I have both boards flashed with the twin_test bitstream and the rev 1.3 controller.
The boards are plugged into a USB hub with two separate USB cables.
I am using a RaspberryPi to run cgminer 2.4.3 and provide work to the boards.
I'm running a SINGLE instance of cgminer 2.4.3 for both boards.
Command line is something like "-S /dev/ttyUSB2 -S /dev/ttyUSB3 -S /dev/ttyUSB6 -S /dev/ttyUSB7". (i'm not using the icarus-timing option)
Dip switches are set to the defaults for the twin_test running mode bitstream.
Can someone please give me a hand to figure out why I'm not getting the full hashrate? I have Skype/MSN if someone would rather speak about it over that.
At first I was just going to wait until the stable bitstream is released, but I figured I may as well fix it now just incase.
Thank you in advance
I'm expecting mine some time early next week 
Been a while since I've been this excited about new hardware.
Been a while since I've been this excited about new hardware.
UK shipping cost is £8 + VAT. EEC 32€ + VAT, US $40. Please ask for other places.
This is courier/express prices, right?
Because Seur Express ships a Plasma TV across Europe in 48 hours for 30€.
UK shipping cost is £8 + VAT. EEC 32€ + VAT, US $40. Please ask for other places.
This is courier/express prices, right?
Because Seur Express ships a Plasma TV across Europe in 48 hours for 30€.
@Enterpoint Team & yohan:
Today i almost made world first in accidently destroying a cairnsmore1 board by putting in a wrong atx power supply cable (yeah call me stupid - i deserve it).
Seconds after i realized that some black smoke raised into the air over the board, i shut down the power supply.
When i took a closer look at the accident i realized that i just bought the worlds best fpga board for bitcoin mining available because all i had to do is put in a non-broken fuse from another cairnsmore1 board. It works perfectly again. WOW - just awesome! Thanks for bringing in the fuse into the design - that really safed me a board
I'll contact your sales - maybe you can supply me with a new fuse.
Today i almost made world first in accidently destroying a cairnsmore1 board by putting in a wrong atx power supply cable (yeah call me stupid - i deserve it).
Seconds after i realized that some black smoke raised into the air over the board, i shut down the power supply.
When i took a closer look at the accident i realized that i just bought the worlds best fpga board for bitcoin mining available because all i had to do is put in a non-broken fuse from another cairnsmore1 board. It works perfectly again. WOW - just awesome! Thanks for bringing in the fuse into the design - that really safed me a board
I'll contact your sales - maybe you can supply me with a new fuse.
Hallo again,
today i managed to replace the broken fuse from one of my cairnsmore1 boards.
Good news: board powers up red leds show up on each fpga and fan is working.
Bad news: windows and linux host doesn't recognize the board as a usb device even after switching the cable. so the incident harmed the usb interface of the board in some way.
Any ideas left how to bring the board back to life on usb?
This really depends on where the short circuit current went and that's really hard to pedict because it also depends on what paths exist in external equipment. It could be any of a number of components that have failed or at the currents you had it's possible PCB tracks have been vaporised. Can you see any obvious physical damage.
Does the Controller red led flash or come on?
If you are in any way technical and happen to have a multimeter it is possible to check if the power supplies are still working. Other than that you have the option to have us evaluate it and repair if possible. There may be a charge for this or carriage charge depending what state it is and what we think needs doing. Either way you should contact us on the bitcoin support email bitcoin.support AT enterpoint.co.uk.
There is another possible option that we can make the board work on the up/down structure when that is availkable. However that depends on what the current fault is. If a regulator has blown then that would almost certainly need replaced.
With controller version 1.3, I can't flash other bitstreams (eg. 200M_beta.bit from icarus) to SPI, but temporary works! After power on, all LED's turned on and remain turned on. With twin_test they turn off and only orange/amber remain turned on until it start hashing.
I don't think anything should have changed on the programming side but we do know if run the array programming tool from Linux directly it is an unstable process. That's why even under Linux we recommend the VM approach. It basically slows it all down and it looks like there is something like a timing loop in some of this software. We are going to lose the VM part eventually but we need our own native tool ready to do that and it's still a little while away.
You have probably already done this but check dip switch settings are those recommended for programming.
I am going to do a document for Rev 1.3 dip switch settings and hopefully I will get that done today.
@Enterpoint Team & yohan:
Today i almost made world first in accidently destroying a cairnsmore1 board by putting in a wrong atx power supply cable (yeah call me stupid - i deserve it).
Seconds after i realized that some black smoke raised into the air over the board, i shut down the power supply.
When i took a closer look at the accident i realized that i just bought the worlds best fpga board for bitcoin mining available because all i had to do is put in a non-broken fuse from another cairnsmore1 board. It works perfectly again. WOW - just awesome! Thanks for bringing in the fuse into the design - that really safed me a board
I'll contact your sales - maybe you can supply me with a new fuse.
Today i almost made world first in accidently destroying a cairnsmore1 board by putting in a wrong atx power supply cable (yeah call me stupid - i deserve it).
Seconds after i realized that some black smoke raised into the air over the board, i shut down the power supply.
When i took a closer look at the accident i realized that i just bought the worlds best fpga board for bitcoin mining available because all i had to do is put in a non-broken fuse from another cairnsmore1 board. It works perfectly again. WOW - just awesome! Thanks for bringing in the fuse into the design - that really safed me a board
I'll contact your sales - maybe you can supply me with a new fuse.
Hallo again,
today i managed to replace the broken fuse from one of my cairnsmore1 boards.
Good news: board powers up red leds show up on each fpga and fan is working.
Bad news: windows and linux host doesn't recognize the board as a usb device even after switching the cable. so the incident harmed the usb interface of the board in some way.
Any ideas left how to bring the board back to life on usb?
With controller version 1.3, I can't flash other bitstreams (eg. 200M_beta.bit from icarus) to SPI, but temporary works! After power on, all LED's turned on and remain turned on. With twin_test they turn off and only orange/amber remain turned on until it start hashing.
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying
The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.
We have been using Win7 and XP here.
What?
30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!?
spiccioli
SPI flash is slow but controller takes like 15-30 seconds.
Might be talking at cross purposes here. Array FPGAs take the 30-40 mins to do the SPI Flash. Controller is very fast and less than a minute to do it's internal SPI Flash.
Yes, we were talking about different things here, but in any case flashing permanently FPGAs 0/3 from a linux pc is three times faster than doing the same from inside virtualbox, so if someone here has a lot of boards it makes a substantial difference in the time it takes to reprogram them all.
Anyway, this morning I was going to flash my boards back to rev 1.2 when I decided to restart the host pc for the twentieth time just to see what serial connections were going to fail this morning and... surprise, it found all FPGAs and they are now all hashing again... I really don't know why the previous nineteen times it was not working properly (yesterday I've restarted boards, power supplies, usb hubs in every conceivable combination... go figure).
spiccioli
There are definate differences depend in what order you fire things up in and so on and we think this is a blend of OS, drivers, CGminers issues probably more than hardware issues at least when the Controller is Rev 1.2 onwards. We saw a definate problem yesterday that is related to the power supply ramp time and that's why we did the Rev 1.3 of the controller. It solved our problem with this power up problem which is also related to the twin or Icarus build. It's possible that for other environments it Rev 1.3 isn't yet the best solution and Rev 1.2 is better.
We will contine to track down these bugs so keep reports going to the bitcoin support email.
My new boards arrived yesterday. Serialnr. 400+ !
I updated to controller version 1.3 and after 5 hours one board was offline, Com's disappeared in Device Manager too.
I will post cgminer results when it was running 24 hours without a Com disappeared.
I'm using win7 32bit on netbook without USB energie saving settings.
EDIT:
Powerconsumption:
10x CM1
1x Netbook
1x ATX PSU 1000W
270 Watt@220V
~3600Mh/s
I updated to controller version 1.3 and after 5 hours one board was offline, Com's disappeared in Device Manager too.
I will post cgminer results when it was running 24 hours without a Com disappeared.
I'm using win7 32bit on netbook without USB energie saving settings.
EDIT:
Powerconsumption:
10x CM1
1x Netbook
1x ATX PSU 1000W
270 Watt@220V
~3600Mh/s
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying
The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.
We have been using Win7 and XP here.
What?
30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!?
spiccioli
SPI flash is slow but controller takes like 15-30 seconds.
Might be talking at cross purposes here. Array FPGAs take the 30-40 mins to do the SPI Flash. Controller is very fast and less than a minute to do it's internal SPI Flash.
Yes, we were talking about different things here, but in any case flashing permanently FPGAs 0/3 from a linux pc is three times faster than doing the same from inside virtualbox, so if someone here has a lot of boards it makes a substantial difference in the time it takes to reprogram them all.
Anyway, this morning I was going to flash my boards back to rev 1.2 when I decided to restart the host pc for the twentieth time just to see what serial connections were going to fail this morning and... surprise, it found all FPGAs and they are now all hashing again... I really don't know why the previous nineteen times it was not working properly (yesterday I've restarted boards, power supplies, usb hubs in every conceivable combination... go figure).
spiccioli
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying
The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.
We have been using Win7 and XP here.
What?
30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!?
spiccioli
SPI flash is slow but controller takes like 15-30 seconds.
Might be talking at cross purposes here. Array FPGAs take the 30-40 mins to do the SPI Flash. Controller is very fast and less than a minute to do it's internal SPI Flash.
BTW, Yohan, a linux SPIProg would make flashing a few boards a lot faster, now I need to detach/attach usb cable from/to boards and windows laptop I use to flash them.
Which Windows version are you using? I found some old laptop with XP Professional on it and every time I plug a different CM1 it re-installs the FTDI drivers. Takes some minutes for each board to flash (need to accept non-signed drivers each time) - really annoying
The process for programming the SPI Flash is very slow. Expect 30-40 minutes per board. We do have a plan to include parallel programming of the array and this will make an obvious time saving expecially if we can make it work over multiple boards at the same time. For this to happen it needs our own bitstream so we can add some necessary support features.
We have been using Win7 and XP here.
What?
30 minutes per board to flash controller FPGA? On my vista 32 laptop it takes 30 SECONDS to flash it?!?
spiccioli
SPI flash is slow but controller takes like 15-30 seconds.
Jump to: