|
241
|
Bitcoin / Mining support / Re: [ERROR] Pushpoold "unkown-work"
|
on: July 09, 2011, 02:53:29 PM
|
Thanks for the hint  . I'm now testing, with and without the patch suggested by redditorrex. so far it's not looking that good :/. edit: it got a little bit better. did you upgrade to newest pushpoold 0.5.1 and newest bitcoind and restart them both after editing the server.json file ? |
|
|
|
|
243
|
Bitcoin / Mining support / Re: [ERROR] Pushpoold "unkown-work"
|
on: July 09, 2011, 02:14:44 AM
|
Try adding this to your server.json config # disable X-Rollntime support
"roll.ntime.disable" : true
Dont forget to add an extra comma at the end of the config option above it if you put this at the end of your config.
|
|
|
|
|
244
|
Bitcoin / Development & Technical Discussion / Re: PROOF-OF-WORK submitted upstream. Result: false
|
on: July 09, 2011, 01:08:15 AM
|
fpgaminer, Thats absolutely the best explanation i have been able to find anywhere and answers all my immediate questions. Thank you so much for taking the time to write that all out! You are most welcome I'm glad it was understandable; these concepts are not necessarily straight-forward so I'm always worried what I write will come out as unintelligible spaghetti. You Couldnt have been clearer thanks again! |
|
|
|
|
247
|
Bitcoin / Development & Technical Discussion / Re: PROOF-OF-WORK submitted upstream. Result: false
|
on: July 09, 2011, 12:20:44 AM
|
|
how is the rpc.target.rewrite toggle related to this? I have found that blocks are solved extremely quickly on a testnet when this is set to false but very long when set to true. Is there any benefit to setting this to false in a production environment on the live net? It seems that you would not want to rewrite the target but hand it off as received from bitcoind to the client or am i missing something fundamental here?
|
|
|
|
|
248
|
Bitcoin / Development & Technical Discussion / Re: PROOF-OF-WORK submitted upstream. Result: false
|
on: July 08, 2011, 09:24:48 PM
|
1) pushpoold will submit all solutions with at least 40 leading zero bits.
2) cpuminer (and cgminer?) will submit all solutions with at least 32 leading zero bits.
This implies that some solutions will be rejected, because they do not meet the mainnet target difficulty.
Thank you! Is it normally for this to be happening 30-40 times an hour with a pool running at 35GH/s ? |
|
|
|
|
249
|
Bitcoin / Development & Technical Discussion / Re: PROOF-OF-WORK submitted upstream. Result: false
|
on: July 08, 2011, 08:45:08 PM
|
I don't fully understand, but I will probably need to at some point if I'm going to start writing client software. Though, even though this simple task doesn't seem like a lot of work, I do see pools like BTCguild constantly struggling to handle the load of the all the connected miners. Clearly, something is stressing them out, though I suspected it might be a network bottleneck instead. With even CPUs able to do millions of hashes-per-second, I can't imagine this computation would be a bottleneck even with a million miners connected.
So what is it that causes unbearable loads on the pool servers?
Its a couple things actually. FD and socket limitations in the kernel which need to be tweaked but still have limits, inefficient coding for this type of thing in bitcoind (which has been vastly improved with some patches by a great guy on this forum). and then you have large pools getting ddos'd for the lulz by the kiddies. If a small pool is having problems i would guess misconfiguration of the server, large pools are probably being ddos'd or have run into limitations in the the kernel, code, or network. |
|
|
|
|
252
|
Bitcoin / Pools / Re: [ ~25 GH/s ] Mainframe.nl Mining Cooperative - New Promotion coming soon!
|
on: July 08, 2011, 03:13:51 PM
|
Ok The early adopter special for first 35 users has been reached! Thanks to all of you who have come on board! We are gonna make this thing a success and couldnt have been done without you guys! If you didnt make it into the first round of Early Adopter no-fee accounts, stay tuned! I have a similar special in the works and will be announced later today or tomorrow! |
|
|
|
|
255
|
Bitcoin / Project Development / Re: mmcFE - A Clean & Simple Pushpool frontend (PHP/BASH/JS/MYSQL)
|
on: July 08, 2011, 02:15:53 PM
|
Forgot to ask also, about how long do you suggest to run the pool_update.sh script? Should we set the crontab to run it every 60 seconds? I am wondering about the sleep commands you used for the different update php files and how this relates to how I should setup the crontab to run the .sh master script?
I am assuming this "timing" would be based on the size of the DB and how they start to take to run or should I say complete.
Thanks as always for your help and time Anni!
Peace!
Im still running every 60 seconds. This should be fine until you are very large or unless your server is very slow. Just watch the overall time it takes for the master script to run and then make sure your load is ok if you run it in windows of time smaller than the time it takes for the script to complete. |
|
|
|
|
257
|
Bitcoin / Project Development / Re: mmcFE - A Clean & Simple Pushpool frontend (PHP/BASH/JS/MYSQL)
|
on: July 08, 2011, 01:53:40 PM
|
I just downloaded the new release .28 R30 and I even built and imported new .sql file as well. My stats shows I have like 12,087 workers connected and I have none in reality? Not sure what is happening.
Peace!
Oh shit your DB got overwritten with default data then. You should only update your db if specified. That DB schema included is only meant for a fresh install (hence the name 'install.sql') Hope nothing else was messed up. Try running the cronjobs once and hopefully that fixes it. |
|
|
|
|
258
|
Bitcoin / Pools / Re: [ 4.3 GH/s ] Mainframe.nl Mining Cooperative - Early adopter offer extended!
|
on: July 08, 2011, 01:18:16 PM
|
Note to yourself: consider offering new pools "catch 22 elimination" service  That's actually a pretty damn good idea We can beta test the service on our pool? hehe OK let's get this lil pool started... I'll add some more horsepower for a while. Disclaimer: this is not all my capacity, just a few boxes/racks will get switched. Excellent! Huge smile on my face over here |
|
|
|
|
259
|
Bitcoin / Project Development / Re: mmcFE - A Clean & Simple Pushpool frontend (PHP/BASH/JS/MYSQL)
|
on: July 08, 2011, 12:21:02 PM
|
- Too many places with the hardcoded $includeDirectory. Should be in a config file or setup through the admin section.
- Forcing Apache and its rewrite might still be valid, although we're not in 1998 anymore, but making it more generic (lighttpd, nginx) would be adequate.
totally agree.... its on the list! that special user var should be the same way. configurable from admin panel would make the most sense. Trying to get some useful user management for the admin in there first and also tweaking the design a bit as well. |
|
|
|
|
260
|
Bitcoin / Pools / Re: [ 4.3 GH/s ] Mainframe.nl Mining Cooperative - Early adopter offer extended!
|
on: July 08, 2011, 12:17:20 PM
|
Glad to help. I need to sort a few lil problems first.. than I might just for fun throw in 100 Ghps to solve the first block.
Wow! that would rock! Let me know if i can help you troubleshoot anything from this end. Note to yourself: consider offering new pools "catch 22 elimination" service That's actually a pretty damn good idea We can beta test the service on our pool? hehe |
|
|
|
|
Show Posts
