Topic: [NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :) - page 33. (Read 101960 times)
Just tried it again and it's working now I'm just going to use it with one of my gpu's for now to test if I like it I'll add the rest.
Is it possible to modify the current round stats to be sortable by the column headings?
It's possible, and will eventually be implemented, but its in no way on the top of my priority list.
Its currently sorted alphabetically by username.
Is it possible to modify the current round stats to be sortable by the column headings?
I've been making some moderate tweaks to the server throughout the day today, and while each one generates only a minuscule amount of downtime, there have been numerous resets in the past few hours.
Things should be mellowed out for now and we'll leave the server to function as-is...
We've still been trying to block any user that is excessively flooding us, so if your askrate is set to less than 5, and you're not submitting any shares, the likelihood is that you're getting your account locked.
Presently, with 50842 submitted shares and 60% pool efficiency, we should be seeing a total of ~84500 getworks being requested...
However... I've had to lock a few user accounts where there were upwards of 20k requests and less than 500 submitted shares.
There is absolutely no reason that a single user should be generating the equivalent of 25% of the traffic of the entire pool BY THEMSELVES.
So, we recommend increasing your askrate to a MINIMUM of 5 for GPUs, and 20 for CPUs. Or use our miner.
Things should be mellowed out for now and we'll leave the server to function as-is...
We've still been trying to block any user that is excessively flooding us, so if your askrate is set to less than 5, and you're not submitting any shares, the likelihood is that you're getting your account locked.
Presently, with 50842 submitted shares and 60% pool efficiency, we should be seeing a total of ~84500 getworks being requested...
However... I've had to lock a few user accounts where there were upwards of 20k requests and less than 500 submitted shares.
There is absolutely no reason that a single user should be generating the equivalent of 25% of the traffic of the entire pool BY THEMSELVES.
So, we recommend increasing your askrate to a MINIMUM of 5 for GPUs, and 20 for CPUs. Or use our miner.
Figured I'd give it a try but it's saying problem communication with RPC. My user and pass are definately right in fact created a whole new account to test site seems slow so maybe just overloaded?
The server seems to have intermittent network problems. I was seeing a constant stream of RPC errors a couple of hours ago, now it seems OK again. Using Kiv's poclbm GUI still, I'll try the custom client at some point.
Figured I'd give it a try but it's saying problem communication with RPC. My user and pass are definately right in fact created a whole new account to test site seems slow so maybe just overloaded?
Had been working pretty well for a while, now it will sit there some times saying "problems comunicating with bitcoin RPC". My connection is fine.
Also I am seeing some errors pop up that say:
Traceback:
File "bitcoinMiner.pyc", line 274, in mine
File "bitcoinMiner.pyc", line 223, in getwork
File "httplib.pyc", line 990, in getresponse
File "httplib.pyc", line 391, in begin
File "httplib.pyc", line 355, in _read_status
badstatusline
Seems to be working better again, fyi cause I did not see anyone else mention it.
Also I am seeing some errors pop up that say:
Traceback
File "bitcoinMiner.pyc", line 274, in mine
File "bitcoinMiner.pyc", line 223, in getwork
File "httplib.pyc", line 990, in getresponse
File "httplib.pyc", line 391, in begin
File "httplib.pyc", line 355, in _read_status
badstatusline
Seems to be working better again, fyi cause I did not see anyone else mention it.
I was making some changes to the pool daemon, you likely saw that when you tried to submit a share during the 2 - 4 seconds that the server was restarting.
Had been working pretty well for a while, now it will sit there some times saying "problems comunicating with bitcoin RPC". My connection is fine.
Also I am seeing some errors pop up that say:
Traceback:
File "bitcoinMiner.pyc", line 274, in mine
File "bitcoinMiner.pyc", line 223, in getwork
File "httplib.pyc", line 990, in getresponse
File "httplib.pyc", line 391, in begin
File "httplib.pyc", line 355, in _read_status
badstatusline
Seems to be working better again, fyi cause I did not see anyone else mention it.
Also I am seeing some errors pop up that say:
Traceback
File "bitcoinMiner.pyc", line 274, in mine
File "bitcoinMiner.pyc", line 223, in getwork
File "httplib.pyc", line 990, in getresponse
File "httplib.pyc", line 391, in begin
File "httplib.pyc", line 355, in _read_status
badstatusline
Seems to be working better again, fyi cause I did not see anyone else mention it.
Should average around 20 hours until payment once the block is solved. There also seems to be something weird going on with the statistics list, it says 0, 50, and next 100. But there isn't 50 in each list segment (there were 19 in the first segment when i checked)
Paging has been fixed and is now working as intended.
Also, hooray for solved block? 
YES, we found another block. Found by user "xxx" (which seems to have a lot of GPU power...thank you xxx).
We're just waiting for the block to be confirmed 120 times, then we'll be paying people on the 121st confirmation (which also shows the block as being "Confirmed" on the stats page).
We're still a few hours away from that though...
Yeah, the paging is broken right now and we're working on that.
Thank you for reporting it though.
Also, hooray for solved block?
YES, we found another block. Found by user "xxx" (which seems to have a lot of GPU power...thank you xxx).
We're just waiting for the block to be confirmed 120 times, then we'll be paying people on the 121st confirmation (which also shows the block as being "Confirmed" on the stats page).
We're still a few hours away from that though...
Also, hooray for solved block?
YES, we found another block. Found by user "xxx" (which seems to have a lot of GPU power...thank you xxx).
We're just waiting for the block to be confirmed 120 times, then we'll be paying people on the 121st confirmation (which also shows the block as being "Confirmed" on the stats page).
We're still a few hours away from that though...
Also, hooray for solved block?
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.
So if i understand correctly, slow miners will be subsidised from money of honest GPU users ?Just asking.
No. CPU and GPU users both have the same chance of submitting a share that is no longer current.
It's a (on average) 1200 second window of time, which actually overlaps as it progresses, that a user (cpu or gpu) will receive credit.
It should allow for CPU users to submit valid shares, some percent of which may be old, but in the same regard, also allows GPU users to submit shares for the prior block as well, which balances out.
GPU users may get their payout reduced by the value of a single share when a CPU user submits a stale share, but in the same regard, CPU users would have their payout reduced when a GPU user submits a stale share.
In this case, "stale" meaning, a share for the previous block.
The rate of occurrence is low however, and negligible.
I'm sure I could track previous block shares to show the exact amount of old work being done, but I find it moderately pointless.
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.
So if i understand correctly, slow miners will be subsidised from money of honest GPU users ?Just asking.
Your question also imply's that the CPU miner's are using a higher askrate, which at the time of writing this the CPU miner's appear to be using a askrate of 10 or less, so no.
But, if they were to use a higher askrate (say 600 seconds), then yes, their profits would be subsidised from the GPUs.
We've done this to accommodate them while we work on the CPU pool. We're hoping to have it up and going in the next few weeks.
When we launch that pool, we'll be back down to CurrentBlock submissions only.
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.
So if i understand correctly, slow miners will be subsidised from money of honest GPU users ?Just asking.
(I simply cannot stay outside)
Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.
Yes, less load on server for +/- same total pool hashrate. But you (as a miner) are not motivated to have huge hashrate on server, you're motivated to have high OWN hashrate. Higher pool hash rate does not make your payouts higher (only more steady). So with long ask rate to server, you're cutting your effective hashrate and losing some valid shares because you work on stale jobs.
< sarcasm >
Well well....look who showed up. Guess what we did....WE STARTED OUR OWN POOL!! I know what a concept, right?!
< / sarcasm >
First off, I think you should apologize to Geebus and I for calling us trolls a few weeks back. That would be the polite thing to do here. Trolls don't release their own pool AND miner, they just talk shit.
We talked about this with you, and wanted to help your pool become more efficient, but we also had problems with the way your pool was being run, and as a result of that you called us Trolls and then ignored us.
Apologize to us first ON YOUR THREAD, which would be the proper thing to do, then we'll address you on ours and we can continue this conversation civilly ... if that's what you want. Or we can treat you the way you treat us. It's up to you.
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.
That is not what is stated in the OP.
Quote from: FairUser
- Anti-fraud protection. We only accept shares from the current block, in the current round.
This pool is in beta, and many things have changed since the original post. This was one of the changes.
Edit: Even today, FairUser stated that the pool only accepts work from the current block.
[...] they risk working too long on a getwork and the network's block count increases by one making their work stale. [...]
And that original post is now updated.
Geez, we've been live less than 48 hours and we're still in beta....chill out.
It's very obvious that you're not a fan of our pool, but seem to love slush's pool, and have come here to stir up trouble by bringing up CPU users time and time again.
If you don't like our pool, and you're stuck with only your CPU, then I'll feel sorry for you.
But I could be wrong...so what is it your using, a CPU or GPU?
So you admit that your pool too favors faster miners when you specifically (incorrectly in every way except your one shortsighted emotions over statistics way) chided Slush's pool for doing so in your OP.
"Testing with" and "favoring" are two different things. We pay CPUs and GPUs the same amount for each share. We don't "favor" either one over the other.
Your pool asks the miners to keep a high Share/GetWork ratio. In order to accomplish this, your pool requests that miners process the entire solution space of every single GetWork before requesting another GetWork. This means that the slower a miner, the more likely that that miner's solutions will be Stale.
True. So if the CPU user's can't handle that, then it's time for them to upgrade to a $89 video card and get with the times.
Simple as that.
And no, the slower miners don't see any negative impact, because we accept shares, and pay them for shares for (CurrentBlock) and (CurrentBlock - 1). If a block is solved every 600 seconds, it would take them 1200 seconds to have their new shares for a getwork become stale.
That is not what is stated in the OP.
Quote from: FairUser
- Anti-fraud protection. We only accept shares from the current block, in the current round.
This pool is in beta, and many things have changed since the original post. This was one of the changes.
Before your post just a few minutes ago, this change was never mentioned. If this would have been stated a long time ago, this discussion could have been avoided.
Such as change should make stale shares nearly impossible for any miner at any speed and completely resolves the issue of slow miners and stale shares.
There are potentially problems that this could bring up, but they should be relatively minor unless specifically gamed in a similar fashion to the original (still existing in this pool) switching form of cheating. Although, I wouldn't put it past people to do such.
Edit: Even today, FairUser stated that the pool only accepts work from the current block.
[...] they risk working too long on a getwork and the network's block count increases by one making their work stale. [...]
Jump to: