Are you using poclbm? There was a substantial bug that just showed up in it a few days ago where it will keep hashing and getting work, but it fails to actually submit the shares. I had two machines running like that for two days before I realized it.
The voting is pretty much separate from share submittal, so it shouldn't have anything to do with it.
Topic: [1200 TH] EMC: 0 Fee DGM. Anonymous PPS. US & EU servers. No Registration! - page 136. (Read 499709 times)
February 06, 2012, 12:08:17 AM
February 05, 2012, 11:53:20 PM
I'm not sure what was up w/ the last round but my mining output was the same and pool gh was same but my payout was less then half of what been gettin last week.....
my estimated reward also reflects this low amount... Why?
is the votin system messin it up? Cuz I mine both us2 and us3 equally.
my estimated reward also reflects this low amount... Why?
is the votin system messin it up? Cuz I mine both us2 and us3 equally.
February 05, 2012, 08:19:46 PM
Great job with BIP voting inaba, one more reason for miners to use this pool. If this is the only pool offering voting, you should put an post on the discussion board, see if brings in more miners until it gets moved.
I put a plug in for us.
https://bitcointalksearch.org/topic/m.733217
February 05, 2012, 07:58:00 PM
I understood nails, screws and glue but didn't get SHIT beyond that.
February 05, 2012, 07:38:19 PM
Great job with BIP voting inaba, one more reason for miners to use this pool. If this is the only pool offering voting, you should put an post on the discussion board, see if brings in more miners until it gets moved.
February 05, 2012, 07:21:53 PM
Thanks for making this democratic.
February 05, 2012, 07:10:49 PM
Ok folks - because BIP 16 and 17 are such a hot topic, I have enabled your ability to vote for whichever BIP you want. Mining on US3 will be a vote for BIP 17, mining on US2 will be a vote for BIP 16 and mining on US1 will be an abstain.
US 1 - Abstain from voting
US 2 - BIP 16
US 3 - BIP 17
When and if an official decision is made and the blockchain is irrevocably modified to support one or the other, all servers will converge to support the appropriate change (if any).
If none of this makes any sense to you, don't worry about it and just keep on doing what you're doing as it probably doesn't affect you for the most part and is really a technical matter for those interested. You can read more about it here: https://bitcointalksearch.org/topic/bip-16-17-in-laymans-terms-61125
Though I suggest you read more than just that thread, the BIP 16 and BIP 17 threads for instance, before jumping to any decisions. Ultimately, though, for most people, it's an academic argument, so I wouldn't worry too much about it.
US 1 - Abstain from voting
US 2 - BIP 16
US 3 - BIP 17
When and if an official decision is made and the blockchain is irrevocably modified to support one or the other, all servers will converge to support the appropriate change (if any).
If none of this makes any sense to you, don't worry about it and just keep on doing what you're doing as it probably doesn't affect you for the most part and is really a technical matter for those interested. You can read more about it here: https://bitcointalksearch.org/topic/bip-16-17-in-laymans-terms-61125
Though I suggest you read more than just that thread, the BIP 16 and BIP 17 threads for instance, before jumping to any decisions. Ultimately, though, for most people, it's an academic argument, so I wouldn't worry too much about it.
February 05, 2012, 04:21:47 PM
A windows binary update will be there too!
Greetz
NetworkerZ
Greetz
NetworkerZ
February 05, 2012, 01:16:34 PM
No problem. 
For those not able to update or not use git for whatever reason, here's the fix:
Find this in Transport.py (around line 92):
Replace those four lines with this one line:
For those not able to update or not use git for whatever reason, here's the fix:
Find this in Transport.py (around line 92):
Code:
bits = hex(difficulty)
bits = bits[2:len(bits) - 1]
bits += ('0' * (8 - len(bits)))
bits = ''.join(list(chunks(bits, 2))[::-1])
bits = bits[2:len(bits) - 1]
bits += ('0' * (8 - len(bits)))
bits = ''.join(list(chunks(bits, 2))[::-1])
Replace those four lines with this one line:
Code:
bits = '%08x' % difficulty.byteswap()
February 05, 2012, 01:11:10 PM
Yes, your guide. It's the only one I've used.
Wow, I like easy. Sorry I still don't know what I'm doing.
Thanks a bunch
Wow, I like easy. Sorry I still don't know what I'm doing.
Thanks a bunch
February 05, 2012, 01:06:29 PM
Which guide? If you used my guide, you can go into the poclbm directory and issue "git pull" to update.
so:
cd poclbm
git pull
done.
so:
cd poclbm
git pull
done.
February 05, 2012, 01:04:59 PM
How difficult is that.
I don't know how other than to start from scratch following the guide
I don't know how other than to start from scratch following the guide
February 05, 2012, 01:01:04 PM
Your poclbm is out of date and needs to be updated.
February 05, 2012, 12:28:06 PM
Well it was a nice day until I shut down everything to change out a fan.
Now I'm getting this...
us3.eclipsemc.com:8337 05/02/2012 12:17:12, Unexpected error:
Traceback (most recent call last):
File "/home/mickey/poclbm/HttpTransport.py", line 45, in loop
self.queue_work(work)
File "/home/mickey/poclbm/Transport.py", line 117, in queue_work
self.process(work)
File "/home/mickey/poclbm/Transport.py", line 76, in process
self.set_difficulty(work.difficulty)
File "/home/mickey/poclbm/Transport.py", line 71, in set_difficulty
self.true_target = np.array(unpack('IIIIIIII', true_target.decode('hex')), dtype=np.uint32)
error: unpack requires a string argument of length 32
us3.eclipsemc.com:8337 05/02/2012 12:17:12, LP connected to us3.eclipsemc.com:8337
us3.eclipsemc.com:8337 05/02/2012 12:17:30, Unexpected error:
Traceback (most recent call last):
File "/home/mickey/poclbm/HttpTransport.py", line 50, in loop
rv = self.send(result)
File "/home/mickey/poclbm/Transport.py", line 88, in send
is_block = belowOrEquals(h[:7], self.true_target[:7])
TypeError: 'NoneType' object is not subscriptable
us3.eclipsemc.com:8337 [202.547 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)]^C
Can someone tell me what this means?
Now I'm getting this...
us3.eclipsemc.com:8337 05/02/2012 12:17:12, Unexpected error:
Traceback (most recent call last):
File "/home/mickey/poclbm/HttpTransport.py", line 45, in loop
self.queue_work(work)
File "/home/mickey/poclbm/Transport.py", line 117, in queue_work
self.process(work)
File "/home/mickey/poclbm/Transport.py", line 76, in process
self.set_difficulty(work.difficulty)
File "/home/mickey/poclbm/Transport.py", line 71, in set_difficulty
self.true_target = np.array(unpack('IIIIIIII', true_target.decode('hex')), dtype=np.uint32)
error: unpack requires a string argument of length 32
us3.eclipsemc.com:8337 05/02/2012 12:17:12, LP connected to us3.eclipsemc.com:8337
us3.eclipsemc.com:8337 05/02/2012 12:17:30, Unexpected error:
Traceback (most recent call last):
File "/home/mickey/poclbm/HttpTransport.py", line 50, in loop
rv = self.send(result)
File "/home/mickey/poclbm/Transport.py", line 88, in send
is_block = belowOrEquals(h[:7], self.true_target[:7])
TypeError: 'NoneType' object is not subscriptable
us3.eclipsemc.com:8337 [202.547 MH/s (~0 MH/s)] [Rej: 0/0 (0.00%)]^C
Can someone tell me what this means?
February 05, 2012, 11:55:11 AM
I am guessing that either of you could write something to monitor the API and send e-mails when a GPU stops hashing, and I haven't looked at the API myself, but it may not be difficult to set up a timer that resets per GPU when shares are submitted in order to catch problems that the mining software itself doesn't know about. Of course, I am not a programmer, so I could be 100% wrong on either count.
or 100% right.With the current 2.2.1 (and much older versions) you can see share count per GPU so yeah you could do it that way also ... but it would be better to also check other things like the 'Status' being 'Alive' (or not 'Dead' if you are only looking for 'Dead' GPUs) and the Hash Rate and maybe even the Activity
Here's the latest pull request output from one of my GPUs (I added line breaks):
Code:
Text reply:
STATUS=S,Code=17,Msg=GPU0,Description=Subaru|GPU=0,Enabled=Y,Status=Alive,
Temperature=75.00,Fan Speed=3380,Fan Percent=85,GPU Clock=870,Memory Clock=745,
GPU Voltage=1.175,GPU Activity=99,Powertune=0,MHS av=358.14,MHS 5s=358.59,
Accepted=2195,Rejected=3,Hardware Errors=0,Utility=5.02,Intensity=9,Last Share Pool=0,
Last Share Time=1328460687|
JSON reply example:
{"STATUS":[{"STATUS":"S","Code":17,"Msg":"GPU0","Description":"Subaru"}],
"GPU":[{"GPU":0,"Enabled":"Y","Status":"Alive","Temperature":75.00,"Fan Speed":3371,
"Fan Percent":85,"GPU Clock":870,"Memory Clock":745,"GPU Voltage":1.175,"GPU Activity":99,
"Powertune":0,"MHS av":358.10,"MHS 5s":358.66,"Accepted":2244,"Rejected":3,
"Hardware Errors":0,"Utility":5.03,"Intensity":"9","Last Share Pool":0,"Last Share Time":1328461198}],"id":1}
February 05, 2012, 11:44:12 AM
I am guessing that either of you could write something to monitor the API and send e-mails when a GPU stops hashing, and I haven't looked at the API myself, but it may not be difficult to set up a timer that resets per GPU when shares are submitted in order to catch problems that the mining software itself doesn't know about. Of course, I am not a programmer, so I could be 100% wrong on either count.
February 05, 2012, 11:07:47 AM
Firstly, I'm not trying to convince you to do anything, I'm pointing out that it is quite possible to do EXACTLY what you want to do using cgminer simply coz you said it can't do it.
It is quite simple to ask cgminer for it's status of each GPU ... ... ...
GPU 0 status on localhost even in a linux shell:
echo -n "gpu|0" | nc -4 localhost 4028 | tr "|," "\n" | grep -a "^Status=" | cut -d= -f2
Then if it's not "Alive" send out a notification
(or use a different grep for hash rate of that GPU ... or even the date/time of the last accepted share for that GPU)
Hell, for kicks I even wrote a script that will hop using the API ... yes it works
It's really not hard once you have an interface that doesn't require buckets of code for basic access ...
Any script will also know if cgminer is dead coz cgminer won't reply ...
So what this means is of course you DON'T need to run multiple instances you simply check each GPU on the single instance of cgminer.
Your requirement (which I said needs multiple instances) is to suit using the pool to notify you (hack)
... and if a pool doesn't have that or you use P2Pool ...
The other outage issue is the internet going down and well firstly that means you can't mine anyway ... until it comes back up.
And that really isn't the miners problem, that's the networks problem for how to deal with that ...
Edit: though I should point out the obvious that the 'devs' commands returns details of all GPUs using one command
(that you can then divide up as JSON or plain text depending on the request format being JSON or plain text)
Kano -
Yes, I could run multiple instances, but cgminer is too heavy as far as a mining client goes to run multiple instances on some of my stripped down rigs (they already struggle with a plain poclbm and nothing else). Additionally, one of the advantages of cgminer is suppose to be the multiple GPU support built in, so not being able to split up the GPUs defeats that purpose.
I'm not saying cgminer is bad... and that web interface is nice, but it doesn't really help unless you watch it like a hawk. I would probably use it as my primary miner if it would just let me split the GPUs up by miner in once instance. I can get by without native SMS alerts
Do any of them have native status SMS/email? Yes, I could run multiple instances, but cgminer is too heavy as far as a mining client goes to run multiple instances on some of my stripped down rigs (they already struggle with a plain poclbm and nothing else). Additionally, one of the advantages of cgminer is suppose to be the multiple GPU support built in, so not being able to split up the GPUs defeats that purpose.
I'm not saying cgminer is bad... and that web interface is nice, but it doesn't really help unless you watch it like a hawk. I would probably use it as my primary miner if it would just let me split the GPUs up by miner in once instance. I can get by without native SMS alerts
Quote
But, even then, lets say it encountered a bug like the poclbm bug that just happened... the client wouldn't even know there is a problem - it was busy hashing away at full speed, yet unable to submit shares. The pool knew, of course, and will alert if no more shares are coming in. So there are instances where the pool is better at alerting and instances where it's better for the mining client. But in either case, there's no SMS alerting built in to cgminer, sadly 
The webinterface is also kind of useless for people behind firewalls wanting to monitor multiple machines. Sure you can setup a bunch of firewall and port forwarding rules, but then you have to monitor each machine individually, which is impractical for large setups.
The web interface is simply what some people have written. The webinterface is also kind of useless for people behind firewalls wanting to monitor multiple machines. Sure you can setup a bunch of firewall and port forwarding rules, but then you have to monitor each machine individually, which is impractical for large setups.It is quite simple to ask cgminer for it's status of each GPU ... ... ...
GPU 0 status on localhost even in a linux shell:
echo -n "gpu|0" | nc -4 localhost 4028 | tr "|," "\n" | grep -a "^Status=" | cut -d= -f2
Then if it's not "Alive" send out a notification
(or use a different grep for hash rate of that GPU ... or even the date/time of the last accepted share for that GPU)
Hell, for kicks I even wrote a script that will hop using the API ... yes it works
It's really not hard once you have an interface that doesn't require buckets of code for basic access ...
Any script will also know if cgminer is dead coz cgminer won't reply ...
So what this means is of course you DON'T need to run multiple instances you simply check each GPU on the single instance of cgminer.
Your requirement (which I said needs multiple instances) is to suit using the pool to notify you (hack
)... and if a pool doesn't have that or you use P2Pool ...
The other outage issue is the internet going down and well firstly that means you can't mine anyway ... until it comes back up.
And that really isn't the miners problem, that's the networks problem for how to deal with that ...
Edit: though I should point out the obvious that the 'devs' commands returns details of all GPUs using one command
(that you can then divide up as JSON or plain text depending on the request format being JSON or plain text)
February 05, 2012, 11:02:36 AM
Hehe.. I join the pool.. and find a block
Fear my skills! NOT
https://blockchain.info/block-height/165489
Fear my skills! NOT
https://blockchain.info/block-height/165489
February 05, 2012, 10:07:53 AM
Kano -
Yes, I could run multiple instances, but cgminer is too heavy as far as a mining client goes to run multiple instances on some of my stripped down rigs (they already struggle with a plain poclbm and nothing else). Additionally, one of the advantages of cgminer is suppose to be the multiple GPU support built in, so not being able to split up the GPUs defeats that purpose.
I'm not saying cgminer is bad... and that web interface is nice, but it doesn't really help unless you watch it like a hawk. I would probably use it as my primary miner if it would just let me split the GPUs up by miner in once instance. I can get by without native SMS alerts
But, even then, lets say it encountered a bug like the poclbm bug that just happened... the client wouldn't even know there is a problem - it was busy hashing away at full speed, yet unable to submit shares. The pool knew, of course, and will alert if no more shares are coming in. So there are instances where the pool is better at alerting and instances where it's better for the mining client. But in either case, there's no SMS alerting built in to cgminer, sadly The webinterface is also kind of useless for people behind firewalls wanting to monitor multiple machines. Sure you can setup a bunch of firewall and port forwarding rules, but then you have to monitor each machine individually, which is impractical for large setups.
Yes, I could run multiple instances, but cgminer is too heavy as far as a mining client goes to run multiple instances on some of my stripped down rigs (they already struggle with a plain poclbm and nothing else). Additionally, one of the advantages of cgminer is suppose to be the multiple GPU support built in, so not being able to split up the GPUs defeats that purpose.
I'm not saying cgminer is bad... and that web interface is nice, but it doesn't really help unless you watch it like a hawk. I would probably use it as my primary miner if it would just let me split the GPUs up by miner in once instance. I can get by without native SMS alerts
But, even then, lets say it encountered a bug like the poclbm bug that just happened... the client wouldn't even know there is a problem - it was busy hashing away at full speed, yet unable to submit shares. The pool knew, of course, and will alert if no more shares are coming in. So there are instances where the pool is better at alerting and instances where it's better for the mining client. But in either case, there's no SMS alerting built in to cgminer, sadly
The webinterface is also kind of useless for people behind firewalls wanting to monitor multiple machines. Sure you can setup a bunch of firewall and port forwarding rules, but then you have to monitor each machine individually, which is impractical for large setups. February 05, 2012, 10:04:13 AM
To those of you having problems with Poclbm - the error has been found and you need to update your poblbm. This applies to raw poclbm AND GUIMiner. It will get rid of the "Unexpected error" you've been experiencing.
Jump to: