Bitcoin Forum
December 05, 2016, 02:51:26 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 ... 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 [117] 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
Author Topic: Cairnsmore1 - Quad XC6SLX150 Board  (Read 251188 times)
tenzor
Sr. Member
****
Offline Offline

Activity: 316


View Profile
October 06, 2012, 09:12:58 AM
 #2321

I wonder if anyone was able to set up CM1 board mining with Raspberry Pi already? If yes, how many boards is one RPi able to handle?
running 12 boards. Looks good. Floating bugs with not working boards simetimes, but i believe it's cables problem.
1480949486
Hero Member
*
Offline Offline

Posts: 1480949486

View Profile Personal Message (Offline)

Ignore
1480949486
Reply with quote  #2

1480949486
Report to moderator
There are several different types of Bitcoin clients. The most secure are full nodes like Bitcoin-Qt, but full nodes are more resource-heavy, and they must do a lengthy initial syncing process. As a result, lightweight clients with somewhat less security are commonly used.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480949486
Hero Member
*
Offline Offline

Posts: 1480949486

View Profile Personal Message (Offline)

Ignore
1480949486
Reply with quote  #2

1480949486
Report to moderator
1480949486
Hero Member
*
Offline Offline

Posts: 1480949486

View Profile Personal Message (Offline)

Ignore
1480949486
Reply with quote  #2

1480949486
Report to moderator
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
October 07, 2012, 08:40:01 AM
 #2322

There's a really annoying bug in the MPBM Cairnsmore1 worker that causes the built-in watchdog to reset it to the default speed if the network falls over for a couple of minutes, and it doesn't ramp it up again so it's going to stay there for a while. Hopefully this patch should fix it:

Code:
diff --git a/modules/theseven/cairnsmore/cairnsmoreworker.py b/modules/theseven/cairnsmore/cairnsmoreworker.py
index 4dd4dd0..aaadc96 100644
--- a/modules/theseven/cairnsmore/cairnsmoreworker.py
+++ b/modules/theseven/cairnsmore/cairnsmoreworker.py
@@ -395,6 +395,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.oldjob and self.oldjob.starttime:
       if self.oldjob.starttime:
         hashes = (now - self.oldjob.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.oldjob.hashes_processed(hashes)
       self.oldjob.destroy()
@@ -410,6 +411,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.job:
       if self.job.starttime:
         hashes = (now - self.job.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.job.hashes_processed(hashes)
       # Destroy the job, which is neccessary to actually account the calculated amount

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Lethos
Sr. Member
****
Offline Offline

Activity: 476


Keep it Simple. Every Bit Matters.


View Profile WWW
October 07, 2012, 08:42:36 AM
 #2323

Nice Fix.

Lethos Designs | UK BTC Seller -  Local Bitcoins | BTC OTC Rating | 1EFhXfX9uXsbXBF3LC69GiVfS3SHCsyMR1
FPGA: 2x Quad XC6SLX150 Boards
Isokivi
Hero Member
*****
Offline Offline

Activity: 924


Items flashing here available at btctrinkets.com


View Profile WWW
October 08, 2012, 01:53:18 PM
 #2324

There's a really annoying bug in the MPBM Cairnsmore1 worker that causes the built-in watchdog to reset it to the default speed if the network falls over for a couple of minutes, and it doesn't ramp it up again so it's going to stay there for a while. Hopefully this patch should fix it:

Code:
diff --git a/modules/theseven/cairnsmore/cairnsmoreworker.py b/modules/theseven/cairnsmore/cairnsmoreworker.py
index 4dd4dd0..aaadc96 100644
--- a/modules/theseven/cairnsmore/cairnsmoreworker.py
+++ b/modules/theseven/cairnsmore/cairnsmoreworker.py
@@ -395,6 +395,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.oldjob and self.oldjob.starttime:
       if self.oldjob.starttime:
         hashes = (now - self.oldjob.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.oldjob.hashes_processed(hashes)
       self.oldjob.destroy()
@@ -410,6 +411,7 @@ class CairnsmoreWorker(BaseWorker):
     if self.job:
       if self.job.starttime:
         hashes = (now - self.job.starttime) * self.stats.mhps * 1000000
+        hashes = min(hashes, 2**32)
         self.hasheswithoutshare += hashes
         self.job.hashes_processed(hashes)
       # Destroy the job, which is neccessary to actually account the calculated amount

Could I please get the "clueless moron" version of how to apply this patch ?

Bitcoin trinkets now on my online store: btc trinkets.com <- Bitcoin Tiepins, cufflinks, lapel pins, keychains, card holders and challenge coins.
makomk
Hero Member
*****
Offline Offline

Activity: 686


View Profile
October 08, 2012, 10:29:27 PM
 #2325

Could I please get the "clueless moron" version of how to apply this patch ?
Sorry, only just noticed this message. TheSeven's added a more complete version upstream, so you should just be able to "git pull" and get it.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
steamboat
Hero Member
*****
Offline Offline

Activity: 648


View Profile
October 09, 2012, 11:07:26 PM
 #2326

I'm running the dynamic hashvoodoo release capped at 200 on mpbm and a laptop and i've been noticing my rig doesn't like more than 17 boards connected at once. It always drops 2 random boards a few hours after I reset them. Each time one of them drops I swap out the usb cable for a new one. It's possible they aren't getting enough power, but I have them connected to a 1000 watt power supply on a 1500va/1000 watt UPS that hasn't given any warnings, and the rig only draws 950 from the wall, so i should have ~250 watts to spare. I'm going to split the rig up and see what happens over the weekend.



You have to be a little careful on what an individual ATX PSU will do. The additive of individual rails is often more than the overall rating but conversely that doesn't mean you can get the entire 1000 watts out of the 12V rails.

In some power supplies the 12V is also split and individual sections have a limit and it is possible to exceed the limit on one section whilst under capacity either overall or even in other sections.

There is another aspect which probably isn't a big factor in modern ATX supplies but I will mention to be complete and that is where the 5V or 3.3V is underloaded and causes an issue. In older supplies there was often a primary regulation based on usually 5V loading. Low or no load on the 5V typically lowered what I will call the excitation of the power supply and basically it drops too low to provide enough energy to 12V circuits. Some of you may have noticed that we put a small loading on our PDB for 5V and 3.3V to avoid this issue.

upon further inspection i indeed was drawing too much from the power supply. switched out to a more efficient 1200 watt and everything is humming along nicely and drawing less power too! Now to find something to do with this newfound free time.

ASIC miners available for purchase

Those who serve best, profit most.
bitcowok
Jr. Member
*
Offline Offline

Activity: 48


View Profile
October 10, 2012, 06:29:31 AM
 #2327

There is another aspect which probably isn't a big factor in modern ATX supplies but I will mention to be complete and that is where the 5V or 3.3V is underloaded and causes an issue. In older supplies there was often a primary regulation based on usually 5V loading. Low or no load on the 5V typically lowered what I will call the excitation of the power supply and basically it drops too low to provide enough energy to 12V circuits. Some of you may have noticed that we put a small loading on our PDB for 5V and 3.3V to avoid this issue.

Yep. I hit this issue loading up a power supply's 12V rail with CM1s.  Almost let all the magic smoke out but caught it just in time.  The remedy: load up the 5V rail with a x6500  Smiley
Bitbird
Full Member
***
Offline Offline

Activity: 233



View Profile WWW
October 10, 2012, 05:26:45 PM
 #2328

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?

Doff
Sr. Member
****
Offline Offline

Activity: 327


View Profile
October 10, 2012, 06:32:02 PM
 #2329

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?

Is this the dynclock version of Bfgminer, the one Luke-Jr has been working on with the clock settings for the new bitstream?  If it is, setting the clocks to start at 175 fixed that problem for me. if its an older version using makomk bitstream I don't know the answer.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
October 10, 2012, 07:12:29 PM
 #2330

My Cairnsmore1 displayed dead one chip after the other by BFGMINER from time to time (after start BFGMINER around 5 to 20 minutes) today. When this occur you'll need disconnect the power to restart Cairnsmore1. But that wouldn't help this situation. What could be caused this?
Could you make a debug.log file with this failure and upload it somewhere? Add to the end of your bfgminer command: --debuglog 2>debug.log

Bitbird
Full Member
***
Offline Offline

Activity: 233



View Profile WWW
October 11, 2012, 07:27:36 AM
 #2331

@Doff
It's standard version of Bfgminer 2.8.1

@Luke-Jr
OK. I'm testing the Cairnsmore1 on my another Linux PC. Will know this problem still occur or not soon.


#EDIT: Seems it's computer problem. Didn't get the same error on another PC at present.

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
October 11, 2012, 11:54:39 AM
 #2332

@Doff
It's standard version of Bfgminer 2.8.1
2.8.1 only worked with fixed-frequency bitstreams, not the new dynamic-frequency ones, FYI.

Cranky4u
Hero Member
*****
Offline Offline

Activity: 771



View Profile WWW
October 14, 2012, 03:32:08 AM
 #2333

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

tenzor
Sr. Member
****
Offline Offline

Activity: 316


View Profile
October 16, 2012, 07:48:02 AM
 #2334

After cold start of 12 boards, some of them wan't start mining. Cgminer responds with a 'invalid blah-blah' and doesn't mine on them. Kano's python usb tester responds with empty values after some timeout or invalid response. I'm using master/slave config with up/down cable. So, from this 12 boards I have, random number wan't start. It might be slave or master, does not matter. During request their leds flashs normally, as expected. Yellow off, then green on and fading down. Then yellow again.
After power cycle failed biard and its master/slave board, it might work in about 80%. If not, I just power do cycle again.
Tried to change usb hub, usb cables, miner..

Looks like controller issue? v1.5. Any suggestions?
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
October 16, 2012, 09:52:30 AM
 #2335

After cold start of 12 boards, some of them wan't start mining. Cgminer responds with a 'invalid blah-blah' and doesn't mine on them. Kano's python usb tester responds with empty values after some timeout or invalid response. I'm using master/slave config with up/down cable. So, from this 12 boards I have, random number wan't start. It might be slave or master, does not matter. During request their leds flashs normally, as expected. Yellow off, then green on and fading down. Then yellow again.
After power cycle failed biard and its master/slave board, it might work in about 80%. If not, I just power do cycle again.
Tried to change usb hub, usb cables, miner..

Looks like controller issue? v1.5. Any suggestions?

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

Glasswalker
Sr. Member
****
Offline Offline

Activity: 350



View Profile WWW
October 16, 2012, 06:33:24 PM
 #2336

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

Unfortunately I'm in France on travel for my day job. And I had hoped to have much development time, but unfortunately that hasn't panned out. I've been extremely busy with no time but for work/eat/sleep. Hell this is the first time I've been online in days... I don't even know what's going on as far as recent developments are concerned.

I'm returning to Canada on Thursday, and I'll do my best to dedicate some time to getting some significant bitstream progress made then.

Sorry for the delays everyone. I'm well aware that each day is ticking closer to ROI problems. I'm doing my best to make time. (I have a cluster running myself now, and I need to get ROI on them too, so I feel you pain).

Just trying to make Bitcoin a Success... One crazy project at a time. (13rwPKskyATcAq3PpnCikfFG8989DQ8M3c)
HashVoodoo Open Source FPGA Mining Bitstream: https://github.com/pmumby/hashvoodoo-fpga-bitcoin-miner
tenzor
Sr. Member
****
Offline Offline

Activity: 316


View Profile
October 17, 2012, 08:47:45 AM
 #2337

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

Ok, didn't try exactly that yet, but I always wait some time before testing. USB on host enumerated, correct and presented. I can do a request using kano's python script. I can see during request flashing lights on pair of FPGA's (so they handling incoming request?), I can see even green light on one of them (got nonce?), but no response on host after timeout (70%) or wrong response (30%).
Boards failing after complete reset, when no power at all, even no usb powert to them. Tried starting boards then host, host then boards - no changes. With or without usb connected. Controller red light blinking pretty fast all time when PSU turned on and power cables connected.
So, for now, to resolve this issue, I power down slave, than master. Then power up slave/master or master/slave doesn'y matter.
Usually failing 1-3 boards out of 12, usually different.

Also, I received my boards with controller 1.5, but 6 of 12 didn't work in master/slave - FPGA-s LEDs was red after board boots. So, I flashed controller, it seems to be resolved for now.

Hmmm... How much power each board requires during start process? Have not measure voltage output on PSU during start.
yohan
Sr. Member
****
Offline Offline

Activity: 448



View Profile
October 17, 2012, 12:59:29 PM
 #2338


Hmmm... How much power each board requires during start process? Have not measure voltage output on PSU during start.

During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.

tenzor
Sr. Member
****
Offline Offline

Activity: 316


View Profile
October 21, 2012, 12:07:03 AM
 #2339

It is more likely that the USB is screwed up but there is an ocassional thing that is power supply related. So try following this sequence in powering the rig up again up:

(1) Remove 12V power and ideally unplug all USB leads at Cairnsmore1s. If you happen to have a USB hub with a switch for on/off that can work as well as unplugging if it properly removes USB power. Do check that it does remove power some don't do this properly. Basically we want the boards to be fully de-powered before starting. This is also the only way also to reset the USB controller if it gets upset by sometime and we have seen that a few times.
(2) Power 12V and Controller LED is flashing on all boards and each FPGA section is powered and configured - LEDs bright.
(3) If you don't get Controller and section LEDs doing the right things modify the power up of the 12V by doing an initial momentary switch on then off and on again.
(4) Plug back in USB leads either one by one or use the hub switch if you have one.
(5) Make sure you leave enough time for USB to enumerate before firing up mining software and better still check USB ports/COMs are all correct and present in the host.

When using master/slave in Controller 1.5 it is important that both boards of the pair power up together otherwise one may fail to start up and that is only an issue for master/slave usage. We are going to try and improve the Controller to either remove, or reduce, this powering up dependence but that might be a few weeks before we have the time to do that.

Did that, nothing changes. 1-2 boards still failing.

Quote from: yohan
During startup there are surges mainly due to the capacitors on the 12V and rails that come up more or less immediately. We have limited these surges by the way we turn on the main power supplies and that is the reasoning for the phased turn on that you will see on the board. That goes a long way to limiting surges. We don't know what the surge current peaks at as it changes dynamically as the boards power up and the highest current peak is extremely short duratiion and very hard to measure.

What do think is sometimes a problem is the rate at which the 12V rises from 0V to normal range. This rise rate depends on the number of CM1 boards in the rig and the power supply being used so it is different for more or less every rig. If is too slow then one of 2 things can happen. The first is that the Controller FPGA fails to configure. The second is that we think that the USB doesn't come out of reset correctly. To see if this is your issue try powering up with only some of your rig say half initially on the power supply. If these all come up ok repeat gradually adding boards to find where issues start to occur. If this does prove to be the root of your problems there are a couple of ways to proceed. The first argueably wasteful way is to either split your power supply into 2 power supplies or just use a bigger supply that might give a better ramp time. More crudely and needs care is to live plug in the power supply of the last few boards and after bringing up whatever of the stack will come up happily with the power supply.
Looks like my PSU can only start 4 boards without any errors. That's strange... If I add 2 boards more, one will fail. I'm using PDB with OCZ ZT 750W PSU
If fails master board, it's slave still works.
Cranky4u
Hero Member
*****
Offline Offline

Activity: 771



View Profile WWW
October 22, 2012, 01:56:04 AM
 #2340

is there any chance of getting a monthly summary of updates? e,g,

Oct
Bitsreams
Mokamk  ver 5  (300MHs)

CGMiner
CKolivas ver 3000.1.00001  (yeah updates are my thing)

etc...etc...

P.S. it is all good and I appreciate your work...plus back it up with sheckles now and then

Unfortunately I'm in France on travel for my day job. And I had hoped to have much development time, but unfortunately that hasn't panned out. I've been extremely busy with no time but for work/eat/sleep. Hell this is the first time I've been online in days... I don't even know what's going on as far as recent developments are concerned.

I'm returning to Canada on Thursday, and I'll do my best to dedicate some time to getting some significant bitstream progress made then.

Sorry for the delays everyone. I'm well aware that each day is ticking closer to ROI problems. I'm doing my best to make time. (I have a cluster running myself now, and I need to get ROI on them too, so I feel you pain).

Cheers Glasswalker...appreciate the efforts

Pages: « 1 ... 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 [117] 118 119 120 121 122 123 124 125 126 127 128 129 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!