Topic: Cairnsmore1 - Quad XC6SLX150 Board - page 13. (Read 286370 times)
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?
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
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.
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. 
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 ?
Nice Fix.
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
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. 
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.
So I say "burn baby burn"....happy mining
A noble, and rational, attitude.
I wish you the best of luck.
And please do post the results you get.
Once the difficulty "gets there" Im also looking to give my cairnsmores a viking burial.
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.
So I say "burn baby burn"....happy mining
A noble, and rational, attitude.
I wish you the best of luck.
And please do post the results you get.
Anyone know if the usual suspects, mokokam, is producing a +220MHs bitstream? I am all 220MHs with <0.5% error rates
I'm actually testing one out now that has a higher maximum cap. Thoroughly voids your warranty of course, as LazyOtto pointed out. Given that the CM1 will not be profitable to run shortly after ASIC release, well not profitable in Australia due to high power costs of $0.22 kW/hr, I will not be needing the warranty after ~Q1 2013. So I say "burn baby burn"....happy mining
Anyone know if the usual suspects, mokokam, is producing a +220MHs bitstream? I am all 220MHs with <0.5% error rates
I'm actually testing one out now that has a higher maximum cap. Thoroughly voids your warranty of course, as LazyOtto pointed out. anyone using the latest dynamic glasswalker bitstream in mpbm notice that after a few days the hasrate of most of the chips drops to about 180 mh/s each?
Send me one and I'll let you know if cgminer does it also (after I write the code)
I haven't noticed that. Longest I went before I needed to restarted it, unrelated to mining, was 3 days and they were all averaging the same rate they were after their first few hours and stayed there. Did you get more invalids enough to trigger it to dethrottle?
They had been running for over 4 days without a restart. Maybe the invalids were catching up but they were all within 1% range.
Depends on your settings, I've tweaked mine a lot since I got it, I forget what the defaults are now.
Mine considers it to be an overload condition if it goes over 1%, which rarely happens (0.01% to 0.6% is typical for mine).
It has a critical at 4%, not sure what that does, but I assume it drops it down to it's min speed straight away, I guess.
However if you leave it long enough if it's invaliding a lot it will dethrottle to a slower speed. Your invalids might be anywhere from 10-20% for a while, at this new slower speed, however give it a few hours, with getting 0 invalids, which will slowly bring down your average so if you didn't notice when it had it's problem, you might be none the wiser.
There is a debug log, but it depends if you want to sift through it to find out when it happened to see if you can explain why it occurred.
anyone using the latest dynamic glasswalker bitstream in mpbm notice that after a few days the hasrate of most of the chips drops to about 180 mh/s each?
Send me one and I'll let you know if cgminer does it also (after I write the code)
I haven't noticed that. Longest I went before I needed to restarted it, unrelated to mining, was 3 days and they were all averaging the same rate they were after their first few hours and stayed there. Did you get more invalids enough to trigger it to dethrottle?
They had been running for over 4 days without a restart. Maybe the invalids were catching up but they were all within 1% range.
anyone using the latest dynamic glasswalker bitstream in mpbm notice that after a few days the hasrate of most of the chips drops to about 180 mh/s each?
Send me one and I'll let you know if cgminer does it also (after I write the code)
I haven't noticed that. Longest I went before I needed to restarted it, unrelated to mining, was 3 days and they were all averaging the same rate they were after their first few hours and stayed there. Did you get more invalids enough to trigger it to dethrottle?
anyone using the latest dynamic glasswalker bitstream in mpbm notice that after a few days the hasrate of most of the chips drops to about 180 mh/s each?
Send me one and I'll let you know if cgminer does it also (after I write the code)
anyone using the latest dynamic glasswalker bitstream in mpbm notice that after a few days the hasrate of most of the chips drops to about 180 mh/s each?
Anyone know if the usual suspects, mokokam, is producing a +220MHs bitstream? I am all 220MHs with <0.5% error rates
Merely FYI, running over 200 will void your warrantee. (Search posts in this thread or the "Cairnsmore1 Manual - Issue 1.0")
To your question though, so far as I know the only thing currently in the works is Glasswalker's "sea of hashers" approach. That is a complete ground up re-design and I don't think it is reasonable to be expecting it to arrive any time soon.
Jump to: