It's expected value is higher of what I get on slush's pool, and since the pool is meant to get your throughput (almost) at the expected value, it's either something wrong with me and the pool, or an over optimistic calculator.
Also, I went mining for about 5 days, with an expected 3 days of payout, but I found nothing. But that sounded perfectly normal to my ears.
1) My pool keeps 2%, not 10% 2) Mining is still probabilistic, even in the pool. Even pool have bad or good days. 3) There were some outages, because keep getwork based pool up is quite difficult. This also cut the daily reward 4) I don't know your hashrate, but score based system makes pool mining more probabilistic than share based. If you have poor hashrate, you still might be more unlucky. |
|
|
|
FYI, connections with the pool are going up/down right now, and have been for about an hour. I'm getting two different errors - that "A connection with the server could not be established" and "The operation timed out", but it always reconnects. A friend of mine said that his is down completely, and has been for about an hour. I'm currently connected, but he isn't, and can't get reconnected.
It is up again, sorry. |
|
|
|
|
I set up send threshold to 0.01 for all blocked accounts, so when your rewards will be confirmed, you receive them into your wallets.
|
|
|
|
|
Thanks to little mistake, registration was accidentaly open for last few hours. I fixed it now and disabled all user accounts registered inside this window. Please understand that server capacity is full for now.
|
|
|
|
Yikes, the server acting crazy weird right now, just got about 15 of these in the last 10 min.
Because I had to restart main server. |
|
|
|
mining should still be super profitable
psssst!!! quietly! :-) (You rised next difficulty to 50000 right now.) |
|
|
|
How does this work with 3 servers
Think i got the new method part
smaller payout but more of them = the same daily profit
There is one main server with Nginx reverse proxy on it. Using "upstream" module to handle traffic to more backend pool instances. |
|
|
|
Did anybody test the -nolisten with the GUI bitcoin on Windows?
I believe there is windows-specific code for checking to see if another bitcoin is running that looks at window titles; file an issue at github if -nolisten isn't doing what you expect.
Thanks for the answer. I think that -nolisten does what it should -> does not open listening port. I don't know if -listen directive should also turn off the window title checks... I created ticket #75 for this. |
|
|
|
|
Thank you for new release! I have two little questions:
- Windows build use little different skin than previous version. Is this a mistake or intention? Nothing which I really care about, I just noticed.
- Is there a reason why "bitcoin.exe -datadir=c:\bitcoin2 -nolisten" don't start second client instance?
|
|
|
|
Any news on when registration will be open again? I have a friend that wants to get in on the action.
When the pushwork will be in production. |
|
|
|
Not sure if this is relevant or important:
I just answered your question in poclbm thread. This is just cosmetic bug of poclbm and is related mainly to today's server upgrade; this should appear much less often in normal pool condition. |
|
|
|
I too am getting intermittent errors while using slush's pool with win7-64:
If you hit that before hour or two, I was upgrading the pool servers and many connections were cut. This just means that data from connection were corrupted (probably because connection was forcibly closed) and poclbm don't catch it. It is just cosmetic. |
|
|
|
I mean from a practical view, I think I understand that the push will tell your miner to stop working on a block and get a new piece of work. Will the miners need to be modified to take advantage of the change?
There will be two possibilities how to use push: a) Use miner which will understand the push protocol b) Use getwork proxy, small script running on localhost, which will communicate with pool on push protocol and with miner on getwork protocol. |
|
|
|
You can see the selected date on the first picture 31.1.2011, but the label on the graph says Feb. 1.
Thanks for the screenshots, I'll try to investigate it a bit. Looks like bug in rendering x-axis. That means info in should be correct.Oh, which timezone are you? It might be the reason, because now I see that JS renders x-axis as UTC, but popup dates in local time of browser. As I'm UTC +1, I miss the difference until now. |
|
|
|
hah you should do that more often, just nailed 3 blocks in <30 minutes.
Haha  Three servers are up and running. Looks like it helped, invalid shares should be much less often. |
|
|
|
|
I'm going to add the third server. Because of cloning, I have to shutdown second one, so pool will operate on one server for few minutes.
|
|
|
|
Chrome is my primary browser, and the pop-up date is different from the date at the bottom of the graph. I did Internet Explorer and Firefox for testing purposes - I rarely use them. The pop-up in both Chrome and Firefox is one day behind the graph's label.
Can you post the screenshot, please? I don't see any troubles in Chrome and Firefox. In IE8 I see no graphs at all, which is known bug of used version of Flot JS library. |
|
|
|
Problem happens on a Windows XP machine: Google Chrome 9.0.597.94, Firefox 3.5.14. Internet Explorer 8.0.6001.18702 reports this error:
Damn, looks like flop isn't working in IE8 properly. Upgrade to flop trunk should fix that. I'll add this to my TODO. Firefox and Chrome works for me without a problem. |
|
|
|
FYI slush, I'm seeing the same thing here. Couldn't see the pop-up from my last post since I was writing/checking from my tablet, and pop-ups don't work very well (if at all) with a mobile device.
Well, cache is set to one hour, so this should not be the problem. Which browsers do you use? Maybe this is just the JS problem. |
|
|
|
Cannot fix it, checked on another machine with same result.
Maybe a problem with my account.
I can't remember how long the cache for this graph is, but it is definitely just a cache issue. |
|
|
|
|
Show Posts
