Room temp 27C
Single 1: 47.50
Single 2: 51.20
Topic: Modular Python Bitcoin Miner - Official Thread - page 5. (Read 74196 times)
I think it's highly unlikely that there is an issue with multiple BFLs running at different speeds. I'd rather suspect that the "slower" BFL's firmware just doesn't work properly.
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
Sure, I'll do that next week as I'm moving the cooler running single to a different location. Then I'll be able to run the hotter (the one that I had to originally downclock) single all by itself using the 825 firmware.
Could you give me the two temperatures of you singles and the room temperature. I would like to have some comparison.
I think it's highly unlikely that there is an issue with multiple BFLs running at different speeds. I'd rather suspect that the "slower" BFL's firmware just doesn't work properly.
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
Sure, I'll do that next week as I'm moving the cooler running single to a different location. Then I'll be able to run the hotter (the one that I had to originally downclock) single all by itself using the 825 firmware.
I think it's highly unlikely that there is an issue with multiple BFLs running at different speeds. I'd rather suspect that the "slower" BFL's firmware just doesn't work properly.
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
If you want to nail this issue down, can you please try running only the "slower" single (with the slower firmware) for some hours and give me the ghashes total, accepted jobs and accepted shares numbers? Or you could also try running both of them with the slower firmware to check if both go nuts in that case
Update:
Hmm, well I flashed the formerly throttling unit back up to the stock 832 firmware and the previous issue with rejected jobs and shares disappeared..it seems running these things at differing hashrates (asynchronously) is not such a good idea. This could be an issue with the mining software, but I don't know for sure at this point.
Hmm, well I flashed the formerly throttling unit back up to the stock 832 firmware and the previous issue with rejected jobs and shares disappeared..it seems running these things at differing hashrates (asynchronously) is not such a good idea. This could be an issue with the mining software, but I don't know for sure at this point.
I don't know if anyone else is having this issue but one of my singles is showing odd performance metrics. The Accepted Shared, Cancelled Shares, Accepted jobs, etc are all heavily disproportionate when compared to the first one. This is BFL Single 2 that is doing this. I've attached a screenshot.
Any help is greatly appreciated!
Maybe I need to tune the pool settings a bit? I'm mining with btc guild. As you can see the first single is doing ok.
I've downclocked the second single as it was throttling but the slightly lower speed (825 mhs) does not explain the odd performance - or at least it should not.
Any help is greatly appreciated!
Maybe I need to tune the pool settings a bit? I'm mining with btc guild. As you can see the first single is doing ok.
I've downclocked the second single as it was throttling but the slightly lower speed (825 mhs) does not explain the odd performance - or at least it should not.
Hello
Its me again
Two little issues i ran into again.
First my x6500:
Its me again
Two little issues i ran into again.
First my x6500:
Code:
self.core.event(350, self.children[0], "temperature", fpga0 * 1000, "%f \xc2\xb0C" % fpga0, worker = self.children[0])
bash: Syntaxfehler beim unerwarteten Wort `350,'
schwing@R2079-W5:~$ TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
bash: Syntaxfehler beim unerwarteten Wort `350,'
schwing@R2079-W5:~$ TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
This looks like the same problem that freshzive ran into. See:
That's a regression on the testing branch as of about 3 days ago, which managed to slip through my testing.
Run "git reset --hard 21575deb675015e20e0ec68958e595e49c6988db" to go back to a working revision for now until I fix this later today.
Run "git reset --hard 21575deb675015e20e0ec68958e595e49c6988db" to go back to a working revision for now until I fix this later today.
Hello
Its me again
Two little issues i ran into again.
First my x6500:
Second the Butterfly auto manager:
If i hook up two Butterfly boxes to the miner they react in a strange way.
They start some kind of flic flacing the work between the two boards so one is doing nothing while the other is on full.
A few seconds later its the other way around
I just get them to work if manually define workers for each of them.
Any ideas ?
Its me again
Two little issues i ran into again.
First my x6500:
Code:
self.core.event(350, self.children[0], "temperature", fpga0 * 1000, "%f \xc2\xb0C" % fpga0, worker = self.children[0])
bash: Syntaxfehler beim unerwarteten Wort `350,'
schwing@R2079-W5:~$ TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
bash: Syntaxfehler beim unerwarteten Wort `350,'
schwing@R2079-W5:~$ TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
Second the Butterfly auto manager:
If i hook up two Butterfly boxes to the miner they react in a strange way.
They start some kind of flic flacing the work between the two boards so one is doing nothing while the other is on full.
A few seconds later its the other way around
I just get them to work if manually define workers for each of them.
Any ideas ?
That's a regression on the testing branch as of about 3 days ago, which managed to slip through my testing.
Run "git reset --hard 21575deb675015e20e0ec68958e595e49c6988db" to go back to a working revision for now until I fix this later today.
Run "git reset --hard 21575deb675015e20e0ec68958e595e49c6988db" to go back to a working revision for now until I fix this later today.
So I got my ubuntu 12.04 setup working nicely with MPBM. The new (rev3?) units load up flawlessly. However, when loading older units, I get this error just after the firmware finishes uploading and it tries to wake up the FPGAs:
Obviously the older revs didn't have temp sensors, so I'm not sure what to do about this? Guessing there's some easy fix that I'm not thinking of.
Code:
2012-05-22 19:38:08.719 [100] AH00WOVL: Traceback (most recent call last):
File "/home/tonic/mpbm/modules/fpgamining/x6500/x6500worker.py", line 217, in main
elif data[0] == "temperature_read": self._notify_temperature_read(*data[1:])
File "/home/tonic/mpbm/modules/fpgamining/x6500/x6500worker.py", line 287, in _notify_temperature_read
self.core.event(350, self.children[0], "temperature", fpga0 * 1000, "%f \xc2\xb0C" % fpga0, worker = self.children[0])
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
File "/home/tonic/mpbm/modules/fpgamining/x6500/x6500worker.py", line 217, in main
elif data[0] == "temperature_read": self._notify_temperature_read(*data[1:])
File "/home/tonic/mpbm/modules/fpgamining/x6500/x6500worker.py", line 287, in _notify_temperature_read
self.core.event(350, self.children[0], "temperature", fpga0 * 1000, "%f \xc2\xb0C" % fpga0, worker = self.children[0])
TypeError: unsupported operand type(s) for *: 'NoneType' and 'int'
Obviously the older revs didn't have temp sensors, so I'm not sure what to do about this? Guessing there's some easy fix that I'm not thinking of.
Does the overclocker firmware raise the clocks by itself? I know it lowers them if the board gets to hot.
Yeah, it should raise them as well, but I believe this is done pretty conservatively. I recommend setting the starting clock to 200 MHz and the maximum clock to 250 MHz and letting it run for a few hours to stabilize.
What is considered a high temperature for this board.
MPBM has default values of 45 C for "warning" and 55 C for "critical." I would say these are good values, but if you are running a more power consuming bitstream later (like eldentyrell's forthcoming one), you might want to lower these values, since the offset between the PCB temp and the FPGA die will be a little higher. For now, aim to keep it under 45, and under 40 is even better.
Just as a side note lowering the log level to 350 did the trick for me - ie the web interface no longer crashes..3 days and still going (before it would crash after after day or less)
Does the overclocker firmware raise the clocks by itself? I know it lowers them if the board gets to hot.
Yeah, it should raise them as well, but I believe this is done pretty conservatively. I recommend setting the starting clock to 200 MHz and the maximum clock to 250 MHz and letting it run for a few hours to stabilize.
What is considered a safe temperature for this board.
Does the overclocker firmware raise the clocks by itself? I know it lowers them if the board gets to hot.
Yeah, it should raise them as well, but I believe this is done pretty conservatively. I recommend setting the starting clock to 200 MHz and the maximum clock to 250 MHz and letting it run for a few hours to stabilize.
Does the overclocker firmware raise the clocks by itself? I know it lowers them if the board gets to hot.
Thanks for your help fizzisist
Is anyone else having an issue with the latest git mpbm version whereby the web management interface freezes after some time. The only solution is to close the browser and restart. This happens with Chrome. With Firefox the web interface looks all messed up - overlapping text..etc.
Are you leaving the browser window open all day? I think something happens when the scrollback on the log gets too long. Reducing the log level should help with that (Settings button on the top right corner). I like 300 or 400 personally, but I also just close the MPBM window when I'm not actively using it anyway.
I'm sure TheSeven has a better explanation for it, but that's what I do to avoid the problem at least.
Yes that's what I was doing. I've had the log level set to the default 500. I dialed it down to 300 now. I like to keep the window open just to keep an eye on the invalid shares percentage and overall hashrate. But I guess it's not absolutely necessary that I keep it open 24/7.
Is there any docs anywhere that explains the differences between the various log levels. I see that 300 displays only accepted shares unlike 500 which displays a lot more detail.
A munin plugin or some simplified interface that only shows the stats you want ("bonks" showed me one he wrote that I like quite a bit) might be a better way to accomplish this. Even cooler would be if a talented web designer wrote an overhaul of the WebUI to make it super snazzy.
This could be color coding for important stats, the option to turn off columns or move columns around, and a fix for that Firefox compatibility problem. Log levels can be figured out by looking at the log messages themselves. For example:
Code:
2012-05-14 20:18:59.212 [200] X6500 board AH01A6D7 FPGA0 sent K-not-zero share 68dc3054
The [200] in the bracket shows the minimum log level that this message would be displayed for. Once again, I'm sure TheSeven has a better explanation.
Is anyone else having an issue with the latest git mpbm version whereby the web management interface freezes after some time. The only solution is to close the browser and restart. This happens with Chrome. With Firefox the web interface looks all messed up - overlapping text..etc.
Are you leaving the browser window open all day? I think something happens when the scrollback on the log gets too long. Reducing the log level should help with that (Settings button on the top right corner). I like 300 or 400 personally, but I also just close the MPBM window when I'm not actively using it anyway.
I'm sure TheSeven has a better explanation for it, but that's what I do to avoid the problem at least.
Yes that's what I was doing. I've had the log level set to the default 500. I dialed it down to 300 now. I like to keep the window open just to keep an eye on the invalid shares percentage and overall hashrate. But I guess it's not absolutely necessary that I keep it open 24/7.
Is there any docs anywhere that explains the differences between the various log levels. I see that 300 displays only accepted shares unlike 500 which displays a lot more detail.
Is anyone else having an issue with the latest git mpbm version whereby the web management interface freezes after some time. The only solution is to close the browser and restart. This happens with Chrome. With Firefox the web interface looks all messed up - overlapping text..etc.
Are you leaving the browser window open all day? I think something happens when the scrollback on the log gets too long. Reducing the log level should help with that (Settings button on the top right corner). I like 300 or 400 personally, but I also just close the MPBM window when I'm not actively using it anyway.
I'm sure TheSeven has a better explanation for it, but that's what I do to avoid the problem at least.
Is anyone else having an issue with the latest git mpbm version whereby the web management interface freezes after some time. The only solution is to close the browser and restart. This happens with Chrome. With Firefox the web interface looks all messed up - overlapping text..etc.
Jump to: