Search content
Sort by
Showing 19 of 19 results by fuzzster
Re: Avalon users: bitcoind and slush's/generalfaults mining pool setup
Hi all,
I was wondering if anyone could shed some light on the following lines of output I am receiving from stratum-mining (I have removed sensitive info):
The parameters change every faulty message, however they all seem to include a "strange" character: í, ï, ®.
All miners are using cgminer. Any idea a way to fix these?
Everything seems to be running fine, but I periodically get these messages.
Thanks!
I was wondering if anyone could shed some light on the following lines of output I am receiving from stratum-mining (I have removed sensitive info):
Code:
2013-07-09 08:32:18,600 WARNING protocol # Failed message: Cannot decode message '{"params": ["", "j", "í000000", "1d000000", "f6e56e5f"], "id": 5, "method": "mining.submit"}' from
The parameters change every faulty message, however they all seem to include a "strange" character: í, ï, ®.
All miners are using cgminer. Any idea a way to fix these?
Everything seems to be running fine, but I periodically get these messages.
Thanks!
Re: Avalon users: bitcoind and slush's/generalfaults mining pool setup
questions:
1. to upgrade from 0.8.1 to 0.8.2 are the commands simply "sudo apt-get update" followed by "sudo apt-get upgrade"?
2. how do i check bitcoind version # from the command line?
1. to upgrade from 0.8.1 to 0.8.2 are the commands simply "sudo apt-get update" followed by "sudo apt-get upgrade"?
2. how do i check bitcoind version # from the command line?
For point two, run
Code:
bitcoind getinfo
. The version will be listed at the top of your output.Re point one, not 100% on this myself. Am looking into it and will let you know what I find - unless someone else here could help??
Re: Avalon users: bitcoind and slush's/generalfaults mining pool setup
Quick update:
Everything was working fine, it was just me being paranoid. It found the block at about 106%.
I think jspielberg hit the nail on the head!
Thanks for your replies!
Everything was working fine, it was just me being paranoid. It found the block at about 106%.
I think jspielberg hit the nail on the head!
Thanks for your replies!
Thanks for your reply DrHaribo. I'll post on the stratum-mining thread and see if anyone can shed some light.
I am just concerned I am wasting my hashes, and not sure if I should stop it and start again or keep it running with my fingers crossed...
At 106% now...
I am just concerned I am wasting my hashes, and not sure if I should stop it and start again or keep it running with my fingers crossed...
At 106% now...
Re: Avalon users: bitcoind and slush's/generalfaults mining pool setup
Thanks for replying tiktoc! I have posted on the stratum page but with no reply 
So thought I'd try my luck here. Have you experienced it at all? Or do you always find the block under 100%?
I am getting the progress value from the pool table in the database, which does display on the stats page, yes.
So thought I'd try my luck here. Have you experienced it at all? Or do you always find the block under 100%?I am getting the progress value from the pool table in the database, which does display on the stats page, yes.
Re: Avalon users: bitcoind and slush's/generalfaults mining pool setup
Thanks for the original post! I have set it up successfully, just wanted to check something...
the round_progress has gone to 105%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
the round_progress has gone to 105%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
I have managed to solve my error above! One more thing... 
The round_progress has gone to 104%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
The round_progress has gone to 104%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
I have a Stratum server set up with stratum-mining as the mining service and the round_progress has gone to 102%. Should it not have found something by 100% or is this just the average?
Basically, is it normal for it to go over 100% or should I be worried??
Basically, is it normal for it to go over 100% or should I be worried??
My Bitcoin daemon has started taking up 100% CPU as mentioned here (a restart of the daemon fixes it for half a day, but the same keeps happening).
I'm not sure how this does anything when the date on my system is correct (when running 'date')?
Could this still be a possible solution? And does it affect the current block I am mining? As I am 80% through and don't want anything to reset!
Thanks.
I'm not sure how this does anything when the date on my system is correct (when running 'date')?
Could this still be a possible solution? And does it affect the current block I am mining? As I am 80% through and don't want anything to reset!
Thanks.
On a separate note, has anyone else experienced the below error:
I've noticed people on other forums have had it, but no one seems to have a solution!
Any ideas?
Code:
ERROR protocol # [Failure instance: Traceback: : (2006, 'MySQL server has gone away')
I've noticed people on other forums have had it, but no one seems to have a solution!
Any ideas?
I have been getting the following error whenever someone connects their miner:
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
The code being:
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
Code:
2013-05-23 08:29:18+0000 [Protocol,0,141.0.48.3]
2013-05-23 08:29:18,619 ERROR protocol # [Failure instance: Traceback: : subscribe() takes exactly 1 argument (2 given)
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:192:dataReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:246:lineReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:13:_handle_event
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:81:call
--- ---
/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py:137:maybeDeferred
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:78:_run
2013-05-23 08:29:18,619 ERROR protocol # [Failure instance: Traceback: : subscribe() takes exactly 1 argument (2 given)
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:192:dataReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:246:lineReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:13:_handle_event
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:81:call
--- ---
/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py:137:maybeDeferred
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:78:_run
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
Code:
msg_id = message.get('id', 0)
msg_method = message.get('method')
msg_params = message.get('params')
msg_result = message.get('result')
msg_error = message.get('error')
msg_method = message.get('method')
msg_params = message.get('params')
msg_result = message.get('result')
msg_error = message.get('error')
The code being:
Code:
if msg_method == "mining.subscribe":
del msg_params[0:len(msg_params)]
del msg_params[0:len(msg_params)]
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
Pretty sure that's the default download speed... we all have to deal with it
Didn't realise is was capped! Makes a lot of sense though...
subscribe() takes exactly 1 argument (2 given) - Possible solution?!?
I have a Stratum server with generalfaults stratum-mining installed, and have been getting the following error whenever someone connects their miner:
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
The code being:
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
Code:
2013-05-23 08:29:18+0000 [Protocol,0,141.0.48.3]
2013-05-23 08:29:18,619 ERROR protocol # [Failure instance: Traceback: : subscribe() takes exactly 1 argument (2 given)
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:192:dataReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:246:lineReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:13:_handle_event
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:81:call
--- ---
/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py:137:maybeDeferred
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:78:_run
2013-05-23 08:29:18,619 ERROR protocol # [Failure instance: Traceback: : subscribe() takes exactly 1 argument (2 given)
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:192:dataReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/protocol.py:246:lineReceived
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:13:_handle_event
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:81:call
--- ---
/usr/local/lib/python2.7/dist-packages/Twisted-13.0.0-py2.7-linux-x86_64.egg/twisted/internet/defer.py:137:maybeDeferred
/usr/local/lib/python2.7/dist-packages/stratum-0.2.13-py2.7.egg/stratum/services.py:78:_run
Although the mining seems to continue fine, it was a massive annoyance, without mentioning the additional logging mess it made. After much digging, the culprit turns out to be when the mining.subscribe method is called from protocol.py, Stratum didn't like the additional parameter being used (in my case CGMiner/3.1.0 or something similar) in msg_params.
As such, I have created a work around by adding some code directly after the following lines in protocol.py:
Code:
msg_id = message.get('id', 0)
msg_method = message.get('method')
msg_params = message.get('params')
msg_result = message.get('result')
msg_error = message.get('error')
msg_method = message.get('method')
msg_params = message.get('params')
msg_result = message.get('result')
msg_error = message.get('error')
The code being:
Code:
if msg_method == "mining.subscribe":
del msg_params[0:len(msg_params)]
del msg_params[0:len(msg_params)]
This removes the error and everything SEEMS to be mining OK, however I was wondering peoples thoughts on it as it was just a hack. Could it effect anything down the line?
Unfortunately my Python is very poor, so please be nice with your comments
Hi,
I set up a Stratum server to start my own pool, however after running fine for a week or so, I am now getting high CPU usage, and the bitcoin_blocks parameter in the pool table is not being updated.
The only error I have in the logs is:
However there are countless of these errors, to the point of my log file being 1Gb after 3 days.
Also, miners are complaining that there is "dips" in their mining activity every 5 minutes or so. I THINK this is down to the server taking too long to get back with more work, but not sure why!
Has anybody else come across this/have an answer to my prayers??
Thanks.
I set up a Stratum server to start my own pool, however after running fine for a week or so, I am now getting high CPU usage, and the bitcoin_blocks parameter in the pool table is not being updated.
The only error I have in the logs is:
Code:
2013-05-14 01:23:08,358 ERROR protocol # [Failure instance: Traceback: : subscribe() takes exactly 1 argument (2 given)
However there are countless of these errors, to the point of my log file being 1Gb after 3 days.
Also, miners are complaining that there is "dips" in their mining activity every 5 minutes or so. I THINK this is down to the server taking too long to get back with more work, but not sure why!
Has anybody else come across this/have an answer to my prayers??
Thanks.