Miner idles should have stopped yesterday for most users, however it is possible for them to start showing up as the hash rate of the pool has been increasing rapidly and is straining the hardware when a large number of shares + a block solve happen simultaneously.
I have a dedicated hosting provider lined up and they are going to be setting up a server with the specs I need this week. This will be a significantly more powerful system than what the pool is currently running on, has a 100 mbps connection, and very strong DDoS protection. The switch to the new server should happen on Thursday or Friday this week.
Topic: [~1000 GH/sec] BTC Guild - 0% Fee Pool, LP, SSL, Full Precision, and More - page 142. (Read 379078 times)
May 22, 2011, 06:48:33 PM
May 22, 2011, 04:16:37 PM
Website shows that I mine at 600-700 mhash, even though my miner shows 760-780, why are there so big differences ? Does it mean I get paid for 600-700 mhashes ?
Mine has varied between 80 mHash and over 110, personally. It's dependent on how many shares you solve, so it will only match your actual speed (98 mhash in my case) in the long run.
May 22, 2011, 04:14:46 PM
nvm, it's much higher now so it should break even
I think the whole site swings back and forth because mine is up ~60 MH now. The only thing that matter is when your Estimated Rewards changes, well, down at least. I don't think anyone will complain about it going up.
May 22, 2011, 04:12:45 PM
nvm, it's much higher now so it should break even
May 22, 2011, 03:50:48 PM
Website shows that I mine at 600-700 mhash, even though my miner shows 760-780, why are there so big differences ? Does it mean I get paid for 600-700 mhashes ?
Like Eleuthria mentioned, you get paid based on shares.
But it's interesting to note -- the rate my miner displays is much higher than what the BTC Guild site reports. This hasn't been the case with other pools I've used in the past though.
May 22, 2011, 03:28:24 PM
I'm getting idles here on my system.
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
Askrate is not necessary with Phoenix because it maintains a work queue and only requests work when needed. Phoenix also ignores the askrate setting automatically for RPC servers with long polling support.
Hmmm thanks. What do you suggest I do about it? Shouldn't phoenix have a queue of work so that it doesn't have to go idle?
Remove the askrate. The miner is idle errors is a bug they are still working out. They think they might have finally figured it out and it will hopefully finally be squashed in the next release. Make sure you are running the most current version 1.48 http://forum.bitcoin.org/index.php?topic=6458.0 or if you are still getting excessive idles try GUIminer http://forum.bitcoin.org/index.php?topic=3878.0 or poclbm.
May 22, 2011, 03:19:59 PM
I'm getting idles here on my system.
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
Askrate is not necessary with Phoenix because it maintains a work queue and only requests work when needed. Phoenix also ignores the askrate setting automatically for RPC servers with long polling support.
Hmmm thanks. What do you suggest I do about it? Shouldn't phoenix have a queue of work so that it doesn't have to go idle?
May 22, 2011, 02:21:35 PM
Website shows that I mine at 600-700 mhash, even though my miner shows 760-780, why are there so big differences ? Does it mean I get paid for 600-700 mhashes ?
You get paid according to the percentage of shares you submit divided by the overall shares. Shares aren't computed at a constant rate, some take your card longer, some shorter. The server isn't told how fast your card works so it calculates your speed as best it can according to the shares you submit. Sometimes it will show faster, sometimes it will show slower depending on how long it takes to complete calculations and submit to the server.
So what does it mean if it's constantly lower for me ? Can I do sth with it ?
May 22, 2011, 02:20:35 PM
I'm getting idles here on my system.
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
Askrate is not necessary with Phoenix because it maintains a work queue and only requests work when needed. Phoenix also ignores the askrate setting automatically for RPC servers with long polling support.
May 22, 2011, 02:15:35 PM
I'm getting idles here on my system.
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
start /DC:\Bitcoin\phoenix phoenix -v -u http://[email protected]:8332/;askrate=1 -k phatk device=1 WORKSIZE=128 VECTORS BFI_INT AGGRESSION=13 FASTLOOP=FALSE
Without askrate I was getting lots of idles if only for a short period (<1s it seems). I put on askrate=10 and it helped but had to keep reducing it to =1, and now I still get a few but not as many. This is on a dual 5870 system, while my 2 5850 systems don't seem to be having this problem at all. I was at slush's pool before this and never saw any idles, could this be due to the LP or is it something else?
May 22, 2011, 02:14:33 PM
Website shows that I mine at 600-700 mhash, even though my miner shows 760-780, why are there so big differences ? Does it mean I get paid for 600-700 mhashes ?
You get paid according to the percentage of shares you submit divided by the overall shares. Shares aren't computed at a constant rate, some take your card longer, some shorter. The server isn't told how fast your card works so it calculates your speed as best it can according to the shares you submit. Sometimes it will show faster, sometimes it will show slower depending on how long it takes to complete calculations and submit to the server.
May 22, 2011, 01:55:08 PM
Website shows that I mine at 600-700 mhash, even though my miner shows 760-780, why are there so big differences ? Does it mean I get paid for 600-700 mhashes ?
May 22, 2011, 11:39:37 AM
When transaction fees are required (due to the pool sending coins which are only recently created), I absorb the costs of the transaction fees. Our transactions do not reach the 1 kB amount though (normally 200-300 bytes).
May 22, 2011, 11:33:21 AM
I see.
I'm fairly new to bitcoin, but according to the wiki (https://en.bitcoin.it/wiki/Transaction_fees), a transaction fee of 0.01BTC / KB is recommended.
Though I guess it's not really important yet. It will become relevant when transaction fees become the main income for miners.
I'm fairly new to bitcoin, but according to the wiki (https://en.bitcoin.it/wiki/Transaction_fees), a transaction fee of 0.01BTC / KB is recommended.
Though I guess it's not really important yet. It will become relevant when transaction fees become the main income for miners.
May 22, 2011, 11:01:37 AM
When you hit the "Pay Me Now" button, are there any transaction fees? (like 0.01 BTC?)
I just paid out my balance, and I wasn't charged any fees. It was a little less than 2 BTC, though. I haven't heard anywhere that fees are charged. You could try it with a small amount and see what happens.
May 22, 2011, 10:39:07 AM
Adding SSL encryption would be nice, to protect the passwords. (There are cheap, and even free SSL certificates).
Another option would be Luke's idea (from the Eligius pool): http://forum.bitcoin.org/index.php?topic=6667.msg97375#msg97375
By using wallet addresses as a usernames, there's no need to protect the passwords.
I have a (totally unrelated) question:
When you hit the "Pay Me Now" button, are there any transaction fees? (like 0.01 BTC?)
Another option would be Luke's idea (from the Eligius pool): http://forum.bitcoin.org/index.php?topic=6667.msg97375#msg97375
By using wallet addresses as a usernames, there's no need to protect the passwords.
I have a (totally unrelated) question:
When you hit the "Pay Me Now" button, are there any transaction fees? (like 0.01 BTC?)
May 21, 2011, 08:38:31 PM
i still get stale shares a lot.
This was happening a bit yesterday but has cleared up for me!
May 21, 2011, 05:40:56 PM
eleuthria your pool are included now in the current version of "GUIMiner" by Kiv:
http://forum.bitcoin.org/index.php?topic=3878.0
http://forum.bitcoin.org/index.php?topic=3878.0
May 21, 2011, 04:35:29 PM
The pool did a very quick restart (< 1 second) to push the 0.4 pushpool updates live, and fix the Ufasoft CPU miner problems that people were having. TCP Keepalive connections are part of this update, which may provide a marginal performance increase, as well as reduce the load on the router, which was recycling connections constantly (and led to a slowdown earlier today).
May 21, 2011, 10:21:35 AM
The problem has been identified. The user running the pool service was hitting the open socket limits as we were above 100 gH/sec. I have modified the limits on the user the pool service runs under, and restarted the pool.
Jump to: