I just signed up, but when I click start mining it says 'unknown login CryptikEnigma', I'm positive I have my username and password right, and I know I'm using the right server, any ideas whats wrong?
If you're having problems with this pool, you're more than welcome @ BitcoinPool. Plus there are no fees. |
|
|
|
I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at. I don't think that's possible. This is why we log it on the client side in a log file though.
FairUser, I really hope you're just making fun from us. When you see nonce in the Block Explorer for every block you found, there _must_ be some way how to check this on the pool, because you own full block source. Hint: Check data string submitted from the miner to the pool, especially find the difference between two shares found from the same job. I'm sure you'll find what you need... Did neither of you read what I said? Let me put it another way so maybe you'll understand what I'm asking. When a share is submitted, how can the pool server know the percentage that the share was found at in the getwork? Was it found at 4%, 32% or 100% in the getwork?? AFAIK, that information is not sent to the server. I'm not asking about the nonce, cause yes, I can see that. I'm asking the about the percentage where the nonce was found at inside it's getwork. Is that being tracked, if so, where? I don't believe this percentage is being tracked by the server at all, but if I'm wrong, please explain where in the share the percentage, not the nonce, is listed. |
|
|
|
We need to get more logs from other users.
Afaik you can collect those stats directly on the server, in the same way as I'm doing it. I would like to know how a pool operator could track, from server side, at what percent of the getwork the share was found at. I don't think that's possible. This is why we log it on the client side in a log file though. If you figure that out, let me know. |
|
|
|
Here is a good example of what Geebus and I are talking about.
Did you noticed that graph shows significantly higher shares probability on every second nonce range? 8-12, 16-20 etc. Why not skip all those ranges with lower probability? You'll earn +1/4 results in the same crunching time. And of course filter out beginning of the range with the lowest possibility. We need to get more logs from other users. If those of you who are using our modified miner, could you please add the "--log" option to your command line and PM Geebus or myself when you get a few logs generated? It would be helpful to get the most stats possible to see if this distribution evens out. Thank you. |
|
|
|
The client probably just doesn't calculate the percentage correctly, there are way more hits on even percentage numbers than odd. Also, you don't include 0 in your statistics, "0%" has 488 hits.
Thank you for pointing that out. The counting code got mixed up when tallying the results. Original post edited. |
|
|
|
Here is a good example of what Geebus and I are talking about. This an example of 21,010 getworks that had the entire getwork processed. You can find the full data set at: http://bitcoinpool.com/data/found-share-stats.html We can see that there is plenty of shares found throughout the entire space of (2^32) possible hashes. So this begs the question, why do we even need an askrate when we have long polling now? Couldn't the miners just work through the entire getwork, and ask for more when they're done with what they had? The obvious exception is to stop working on what you got when a new getwork comes back down the long polling channel. Edit: Grinder just pointed out a flaw in the counting code and hence the stats were off. Graph and stats updated. Thank you grinder. |
|
|
|
Wish this round was over
added a couple machines
I'll have to wait and see what that means
now its now down to can you keep up (do enough crunching) with added shares
..and added users
hope it gets done soon
It's down to you can, bobR, keep up with others in the pool. The more you can crunch, the more you earn. Yes, our server can handle it with no problems. I would like the round to end soon too. |
|
|
|
Correct me if I'm wrong, but you probably invented new scientific method called 'believing'. Miner IS sha256 cruncher. So you're talking about two possibilities:
What we currently believe personally is not a scientific method. If the data changes and shows something else, then our believes could change. So show me exact statistics. As you have collected milions of shares to confirm that, this won't be surely a problem.
To be correct, I _did_ the analysis with ~15 milions of shares on end of January and I can say that shares are perfectly spreaded inside whole nonce range. So this is the reason why I don't believe you.
I'm not up to a million yet, but I'll let you know when I am. Oh, 15 million....care to share them? If you do, that would shut us up. Here's you chance to put this to bed ... |
|
|
|
So show me exact statistics. As you have collected milions of shares to confirm that, this won't be surely a problem.
To be correct, I _did_ the analysis with ~15 milions of shares on end of January and I can say that shares are perfectly spreaded inside whole nonce range. So this is the reason why I don't believe you.
I'm not up to a million yet, but I'll let you know when I am. Oh, 15 million....care to share them? If you do, that would shut us up. Here's you chance to put this to bed ... |
|
|
|
And I don't know of ANYBODY that has ever advocated askrate being set to 1 second. The various mining programs have (had before long polling) varying defaults from 5 to 10 to 15. Now with long polling, it is set to 60 seconds in order to include new transactions in the same block.
I never said anyone advocated it. I said people are DOING it. You're basing all of your assumptions about SHA256 on a perfect environment, but there are MANY variables that come into play that could cause a flux in results. The miner, the cl kernel, it's implementation of SHA256, the card itself, the driver, the OS, etc... each of these could be having an effect on the ability of a miner to actually process the full one percent in a matter of seconds. It's based on the hash speed of the card, and whether or not it can even process a full iteration of the CL kernel before the askrate is met and it dumps it's current work to grab new work. I've never once stated, EVER, that SHA256 is flawed... I have on the other hand stated that, observationally, the miner itself is not generating perfectly distributed results. THE MINER. Not SHA256. So, fuck you very much, and STFU. ++ Geebus is not saying that the mining programs *are* missing the first 1% of the getwork, he's saying he (and myself) has *observed* this when looking at the recorded getwork's from a log and *believe* that something is not right here. This causes us to wonder, so we research further to figure out why this is happening. You are right that it should be a nice, even distribution of answers from 1% to 100%, but what we are *observing* is NOT a perfect distribution. We never made such an outrageous claim as to breaking SHA256. You are the one implying we broke SHA256 when we have never said that. We are saying what we are observing, and we are observing a far less than perfect distribution of shares found at 1% of the getwork...that's all. Quit trying to put words in our mouth with outrageous claims in an attempt to discredit what we're observing. Instead of talking trash, why don't you download the miner, log about 30000+ shares submitted, and get back to us with those results. The more results we can collect, the better chance we have at figuring our what is causing this observed behavior. If you're not going to do any research yourself or anything other than trying to make false claims on our behalf, then do yourself, us, and everyone else a favor and say nothing. |
|
|
|
Okay, another newb question then. Is it possible to hand out larger (say 64-bit) getworks. Or is this a limitation of Bitcoin. Only thinking of ways to make faster clients less taxing on the server. With long-poll in play there is no reason to pester the server until the server says otherwise.
Yes, we could do that if we wanted to. |
|
|
|
In the latest version (03.21.2011), the --defspd flag was removed due to the fact that the miner now works slightly different under the hood. There are now two situations that will result in new work being retrieved:
1) You've worked through the entire getwork and actually need more work.
2) Long polling on the server has told your miner to update because the block has changed.
Both of these situations negate the need for an askrate to even be present, so I removed the option of '--defspd', and an askrate doesn't need to be set any longer since the miner will effectively work through the entire (mostly) hashspace on every request.
Base lies I say. I understand the need for keeping long-poll alive, so wouldn't it be more useful just to do so, and not call another getwork. No. If my video card can do 200,000,000 hash/s, and there are 4,294,967,296 (2^32) possible hashes in a getwork, it would take ~21 seconds to go through all the (2^32) possible hashes. After that 21 seconds, what would we do without another getwork? Nothing. Hence, this is why you need to get another getwork from the server. Long polling was designed to tell the miner "Yeah, the block just changed on us, stop what you're working on, and here is a new getwork for you to start working on." |
|
|
|
BTW, why do you think bitcoinpool not grow? With zero fee?
I can only speak for myself, but they don't have PPS, their hash rate is too low to provide a steady payout, they require a special client, and they whine too much about their efficiency. I like to make a correction here. We support any client on our pool. We just recently added support for long polling too. We also released our own modified version of m0mchill's miner, it is not required to be a part of our pool, but we would prefer you use it. |
|
|
|
wow >250% EFF, really unbelievable. But the saying "DUPLICATE NOT SUBMITTED" makes me feel both good & bad that i mined same share 2 times in same time(like giving birth to twins) & one is rejected, coz its a duplicate.
lol, that's a funny way of looking at it. |
|
|
|
Why are stale messages being kicked up on a slow machine  The block is changing before you find a share. This is why we recommend that people start using long polling with our server, so that wouldn't happen. Again you are talkin above my head i'm usin pudinpops miner What does long polling have to do with it I get ... every so often as per your edit why should it be stale when i'/v never hashed the whole chunk You want wait before I ask for another my wait and hash times ... i never hash a whole chunk Why should it go stale I don't use pudinpops miner, and I do not know if it supports long polling. You should ask him that. You could get jgarzik's CPU miner which does support long polling: http://bitcointalk.org/index.php?topic=1925.0The bitcoin network has a "block count". This "block count" changes anytime someone finds an answer for the current block. A share is a *possible* answer for the block. If the block count of the bitcoin network increases, and your mining is still working on finding an answer for the older block, it has become stale. So the idea behind long polling is that when the block count increases, it will notify your miner right away, and then your miner starts working on the new getwork instead of the old one. Or to put it another way, your "getwork" request may have a share (answer), and that answer may solve the current block. If it takes you too long to find an answer on your current getwork, it will go stale when the block count increases on the network. The only reason the block count increases is because someone found an answer for the block. A share can become stale at any moment, so you are literally racing against time. If you want to find more shares, you need to get a good ATI video card. It sounds like your CPU just isn't cutting it for you. Also, it makes perfect sense why our pool hasn't found anything in 24 hours. Put the speed of the pool into the bitcoin calculator: http://www.alloscomp.com/bitcoin/calculator.phpThe pool speed is about: 4600000 khash/s or 4.6 Ghash/s That comes out to: Probability Time Average 19 hours, 45 minutes 50% 13 hours, 41 minutes 95% 2 days, 11 hours, 12 minutes At the speed we're going, it could take 2 days. Be patient. If don't like being patient, you might want to check out another pool. |
|
|
|
Why are stale messages being kicked up on a slow machine The block is changing before you find a share. This is why we recommend that people start using long polling with our server, so that wouldn't happen. |
|
|
|
Fixed. Thank you for reporting it. |
|
|
|
Slush - 2% commission = around 50 BTC per day, whereas paying for a dedicated server only costs around 100 BTC per MONTH.
[Tycho] - 3% commission, but he supports long polling and you do have the option of being paid immediately instead of waiting for 120 confirmations.
Geebus - 0% commission + long polling support - Really everyone should be on here pushing the average work time down and making it the best of the three pools.
Is there something I'm missing?
++ But I would call it BitcoinPool, not Geebus.  Technically it's in my house, but Geebus and I both work on it and regularly bounce ideas off of each other. It's a team effort.  |
|
|
|
Guys, I really respect your hard work providing another pool. But please cut all this 'efficiency' pseudo-science.
+1 agreed This is not "pseudo-science", it's a fact. We spent over a month working, testing, and analyzing results. There is no correlation between searching whole 'nonce space' and the results you find.
I'm not sure what you're trying to correlate, but we never said you get more or less shares/nonces using this miner vs yours. In fact, you get about the same number of them in a given amount of time, but ours does it with less getwork requests. That's all we're saying. I'd love to see any data you have proving your statement, cause we have LOTS of results to prove ours. Besides, I like being able to find more than one nonce in a single getwork request. It happens quite often too. 03/20/2011 15:54:21, 666bb698, accepted at 24% of getwork[7379]
03/20/2011 15:54:29, 1eda3c61, accepted at 56% of getwork[7379]
03/20/2011 15:54:29, 5a64d0d1, accepted at 56% of getwork[7379] Yes, it affects server load, but there are other methods to solve this.
What other methods would you propose? BTW, thanks for the code. We didn't want to tell you how to manage your miner, hence why we forked it and did our own. Have you looked at the changes at all? We did all of this because slush started charging people a "forced donation" or a fee under the notion that his amount of used resources was too high and he needed to cover the cost. So we looked into why the usage of resources was so high, and excessive getwork request end up costing him $$$ on his VPS provider. The tweaks we made to your miner would help slush, but he said he didn't want it and likes his miners using a askrate of 1 second (causing a flood of getwork), so we launched our own pool instead of complaining about it. Our goal wasn't to 'find more faster' or anything like that, we simply wanted to be more efficient about the way our miner worked with the pool. We don't see the need to excessively call to a server for a new getwork every 10 seconds. Now with long polling, their really is no need for that type of behavior. Working through the entire getwork isn't a bad thing. If you feel it is, please elaberate. ------------------------------------------------------------------------------------ http://dictionary.reference.com/browse/efficiency ef·fi·cien·cy
[ih-fish-uhn-see] Show IPA
–noun, plural -cies.
3. the ratio of the work done or energy developed by a machine, engine, etc., to the energy supplied to it, usually expressed as a percentage. |
|
|
|
Now you can really increase effeciency to the level of other pools.
ROFL. You're funny. Please prove that statement and post the # of getwork request and # of submitted shares (which you already do) for each round on your site, and that will show the efficiency of your pool. I'll show you mine if you show me yours....oh wait....we already do show that. It's ok, i don't mind if truth is funny for you I was talking about mining efficiency, not the getworks/shares proportion (which is not important for miners). Oh I wasn't offended. I just like giving people shit sometimes, and I totally knew what you meant. You seem like you can take it better than most. |
|
|
|
|
Show Posts
