There could be a couple of problems with this.
1) If by "push" you mean "send to client", what happens to clients/miners who are behind a firewall and can't/don't want to have port forwarding setup? Or those who use Tor?
There exists stuff like Comet or so. I will probably prefer something TCP based to avoid HTTP overhead (which is significant in our case). 2) My 3 miners all come from the same IP, so I'm doing a new get work request every 3-6 seconds. Limiting that would suck cause my miners would start to idle...and I want them turning 24/7.
I'm not talking about limiting requests per second. Push based protocl just don't need polling every 3-6 seconds. Workers will receive new job immediately when merkle changed... Interesting. Never read about Comet until now. Does that mean my clients get updates within seconds of a new block?  What would happen to the "work" my miner is currently working on when a "push" is received? Would my miner stop working on it's current getwork and start working on the new getwork right away? :O Would my current work be discarded or counted? Even bigger though, what would the miner clients have to update to get this all working correctly. I've gotten 7 blocks so far, and anything that helps increase those chances would be cool. |
|
|
|
Why must it "getwork" each 5 seconds?
I think technohog described it well. I'm thinking about push based protocol instead of current getwork, where server will send a job to client only on merkle hash change (so only few times per minute, in the worst case). But it will takes long time before it will be stable enough to switch pool to this. There could be a couple of problems with this. 1) If by "push" you mean "send to client", what happens to clients/miners who are behind a firewall and can't/don't want to have port forwarding setup? Or those who use Tor? 2) My 3 miners all come from the same IP, so I'm doing a new get work request every 3-6 seconds. Limiting that would suck cause my miners would start to idle...and I want them turning 24/7. |
|
|
|
Lost account password. What to do now?
Make a new one. It's free. I have only 2 workers and it can work for me. But what if someone has 20? Then this will be another reminder for them to either 1) Not forget or 2) Write it down in a secure place |
|
|
|
Lost account password. What to do now?
Make a new one. It's free. |
|
|
|
|
It took 2 days for funds to be transfered to my account.
|
|
|
|
OK well it's obviously micro-budget but it'll improve over the next 6 months. Gotta fix the sound especially. Looking for constructive crit on these rough drafts. I figure the intro's too slow, do you agree? HERE: http://www.youtube.com/watch?v=IpCcuPYdRNISorry I haven't repsonded to some of the replies on my other threads. Been very busy. Happy New Year! Your fuzzy text is killing my eyes. Make the text crisp and clean plz. Good work. |
|
|
|
I'm running miners on 18 machines at the moment, each connecting directly to slush's server. 15 are even at the same location. Does the number of connections matter for the performance? If so, maybe we should find a way to proxy the minders? It could give a count of my total M or k hash/s :-)
And off course I'm continously refreshing the Statistics and My bitcoin page. I'm probably not the only one...
I do not know the answer to your question....but... I ran 64 *CPU* instances on Amazon's EC2 cluster...and it did VERY, VERY little work compared to a decent ATI Video card. As a matter of fact, I'm going out and building a new box today with a couple ATI cards. Just FYI...if you're using CPU....save your money, or sell some hardware, and get more GPU's.  |
|
|
|
|
Literally just had this show up:
2011-01-03 21:16:03 Found Hash!
Sending to server: {"method":"getwork","params":["00000001cca6575b326247fd9b8aa8
77735d86fb4b7eab51838297660003f7ef00000000f1bdf21a7dca2de2139aa60dae0877c3b2e31 9
f3be6b9c8a346f69251500b1ea4d223c561b0404cb16ae4de900000080000000000000000000000 0
000000000000000000000000000000000000000000000000000000000080020000"],"id":1}
Retrying
Retrying
Retrying
Retrying
Retrying
Error while sending found block to server!
27242 khash/s
2011-01-03 21:16:06 Found Hash!
One or more of the blocks you are working on is stale.
You or the server might be having connection issues.
27931 khash/s
2011-01-03 21:16:23 Found Hash!
One or more of the blocks you are working on is stale.
You or the server might be having connection issues.
27976 khash/s
Now, I know you're working on the server right now, but wouldn't that just be our luck that I find another block (already found 2 blocks in the last week for the server!) and it doesn't get reported?
Do you think that could be the case?
While a "Block" get you 50 BTC when you find it (or the Pooled mining gets it in this case)....so when I see the word "BLOCK", I think 50bitcoins...
Or did puppinpop call all these "blocks" instead of "meta-hashes" or "mini-blocks", which helps confuse the crap out of everyone...IMO.
|
|
|
|
I am wondering (and worrying) if something is (slightly) wrong with the pool server and if some work is duplicated. Slush, did you check if all the shares are unique or if there are some stale/invalid shares?
I know about this disbalance, too. I'm logging _all_ shares for few days ago (actually it is 355303 logged shares) and I'm working on uncovering possible problems. This can be still explained by probability and luck, but I want to be sure there is nothing bad behind those numbers. To your question - yes, all shares are unique, except few re-submitted from miners when pool was unstable (yes, sometimes is database overloaded; I'll move pool to standalone server soon to avoid interferences with another services). But those re-submitted shares was not count twice. So let me play with gathered shares, I'll try to find any possible problems here. I'm also interested, if there is anybody else with large hashing power to ask him if their miners have correct probability distribution. I'll also publish share logs soon to allow other people to review share stats by self. Just FYI, found these in my log: 02/01/2011 11:01, 49fd10bf, invalid or stale 02/01/2011 11:01, 0d157919, invalid or stale 02/01/2011 12:21, 493e637c, invalid or stale 02/01/2011 16:07, 6d716d59, invalid or stale 02/01/2011 16:07, 293de62e, invalid or stale 02/01/2011 16:10, 751cdf81, invalid or stale 02/01/2011 16:11, 4dc33d31, invalid or stale 02/01/2011 17:13, 5f8cf672, invalid or stale 02/01/2011 17:13, 7e306be7, invalid or stale 02/01/2011 19:00, 4603c922, invalid or stale 02/01/2011 19:01, 469d4616, invalid or stale Hope this information helps you out somehow. |
|
|
|
The only problem I have now is the clients crash at random....so I wrote a batch/bash script to start the process in a loop, so that when the app dies, it just restarts back up.
What miner? What crashes? Do you have some traceback/error message? Miner: poclbm Unhandled exception is the error. I do not have a trackback/error message as of late because of the script I wrote to catch it. I just restarted the process *without* using my script....so I'll post here the next time it crashes. |
|
|
|
6-8 bitcoins using a GPU? or CPU?
GPU ATI HD RADEON 5750 ~150,000 khash/s |
|
|
|
I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes! Just started to search a thread to put about the same question to the BTC community.  Can you plz link to that thread? Thx |
|
|
|
I've not had any luck connecting to slush's pool using this miner with the -o flag. I set it to mining.bitcoin.cz and I get an error reading "Problems communicating with bitcoin rpc". I got the actual IP address for the server (109.74.195.190) and put that in for -o and got the same error.
I tried setting the -p flag to 8332, and get an error saying non-numeric port.
try "--port 8332" |
|
|
|
FairUser, please describe your setup with as many details as possible. When did it start showing this?
Does anyone else see something similar?
False alarm. My bad. The log file is not showing repeats. We running on a console, it's fine too. When displayed through my ssh session, it does. I think it's the way I have my shell setup. Whatever it is that's causing it to show up on my remote session twice, is NOT because of the miner. I repeat. The problem is NOT because of poclbm. False alarm, my bad. Sorry for the mistake. Please ignore the previous posting.  Thanks again for the awesome work! What's your bitcoin address, I want to send you a little something for your efforts... |
|
|
|
Yeah, Slush did a good job on the pooled mining server. Thank you slush! I've received several payments, and I'm starting to spread the word to my tech savvy friends. The only problem I have now is the clients crash at random....so I wrote a batch/bash script to start the process in a loop, so that when the app dies, it just restarts back up. I'm making about 6-8 bitcoins/day now.  Spread the word and lets get this mining operation really going! |
|
|
|
FairUser, please describe your setup with as many details as possible. When did it start showing this?
Does anyone else see something similar?
AMD Athlon(tm) X4 620 Processor 8GB RAM 1TB HD ATI RADEON 5750 Using the following to run my miner: python poclbm.py --user=<removed> --pass=<removed> --port 8332 --rate=2 -f 1 -d 1 -a 5 -w 128 -v -o mining.bitcoin.cz~149,000 khash/s average speed I'll start dumping the output to a log to keep better track than using the buffer on my terminal. |
|
|
|
Several blocks are found in less than 1-2 minute, some even have been found in negative time (like block 100557 found in -19 seconds). Today it seemed like many of the blocks are being found well underneath the average time.
I also noticed that when the mining pool @ bitcoin.cz got a block, my windows Bitcoin client didn't get notified of the block update for 6 minutes!
That means the Pool got a 6 minute head start of everyone else @ 5.5 Bhash/s ... that's a good head start. I'm not sure what caused this behavior, but it was interesting to watch happen before your eyes. Go figure, the bitcoin pool got several blocks after that too, then didn't get any for several hours.
I doubt that there is anything untoward happening here. The timestamps in the blocks are based off of the generating machine's clocktime, which can vary considerably. Even if it's being attempted by someone, it's not detrimental to the network. I'm not talking about the blocks time stamps. I saying I sat in front of my PC, watched the pool get a block, noted the time on MY desktop, and 6 minutes later (again on my desktop) my bitcoin client updated it's block count by 1. To be clear, my windows client is just being used to monitor when blocks go up or when I generate coins. My Linux box has the GPUs in it, and is contributing to the pool. When the bitcoin.cz pool got a block, it was 6 minutes before my windows client saw the update. WHY???Explain how a 6 minute delay occurs before my bitcoin client on my windows box sees the block count get updated after it was solved on my other PC (yes, I found the block for the bitcoin pooled mining). |
|
|
|
|
Edit: False alarm, please ignore.
Does anyone know why I'm getting double or triple accepted hashes?
01/01/2011 18:09, e62d8177, accepted
01/01/2011 18:09, e62d8177, accepted
01/01/2011 18:09, a753edb1, accepted
01/01/2011 18:09, c46b1614, accepted
01/01/2011 18:10, 51ccbc9c, accepted
01/01/2011 18:10, 51ccbc9c, accepted
01/01/2011 18:11, 2b411e8b, accepted
01/01/2011 18:11, 2b411e8b, accepted
01/01/2011 18:11, 2b411e8b, accepted
01/01/2011 18:13, 3ddfdb84, accepted
01/01/2011 18:13, 9e29c06c, accepted
01/01/2011 18:13, bdc65504, accepted
01/01/2011 18:13, bdc65504, accepted
01/01/2011 18:14, f4d73c8f, accepted
01/01/2011 18:14, 7229e2dc, accepted
01/01/2011 18:15, af861f38, accepted
01/01/2011 18:15, c5d3b074, accepted
01/01/2011 18:16, c446c905, accepted
01/01/2011 18:16, 5e9072e6, accepted
01/01/2011 18:16, 5e9072e6, accepted
|
|
|
|
After finding the main through on technical support that is what I'm doing right now. I'm not particularly sure if I am up to date or not so I'm just get my latest drivers and hope it works. -.- Edit: It finally works. You gotta love bleeding edge technology...changes every month. |
|
|
|
|
Show Posts
