[NEW POOL & MINER] - BitcoinPool.com - Jump In! ~NO FEES~ :)

[FairUser]

I miss NullVoid.

I miss it so much that I found a cached copy of the statistix php code on this forum and dropped it on our site.  This is lacking the nice graphs that nullvoid had, but it's a start if you want some stats about the rate at which blocks are being found.

http://bitcoinpool.com/statistix/

If anyone else can dig up some more cached code from nullvoid and wants it hosted somewhere, find the cached code then point me at it.  I'll do my best to get it up and working.

[srty]

Someone please help me out. I had the first miner working, but thought checking for stales was a good idea, so I tried to set that up.  Does the new client (GUI or otherwise) support Nvidia cards?  If it does, then clearly I have no idea what I'm doing.  If it doesn't that would definitely explain my problem.

[geebus]

Someone please help me out. I had the first miner working, but thought checking for stales was a good idea, so I tried to set that up.  Does the new client (GUI or otherwise) support Nvidia cards?  If it does, then clearly I have no idea what I'm doing.  If it doesn't that would definitely explain my problem.

It should support anything that the normal poclbm supports. If your nvidia card was supported before, it should still be supported on our version.

Are you getting error messages? Let me know whats happening and I'll see what I can do to help.

[srty]

At one point, it just kept saying "connection problems". I changed something though, and now I don't see that anymore.  Here's all my settings.  I'm trying to get it to check a local client for stales since my card isn't very fast. It's a 9600 GSO, which gets about 21 M/hash.  I only have 1 machine, and it's connected to the internet through a wired connection, but through a router.  I'm trying to set it up for pooled mining.

GUI settings...
server: bitcoinpool.com
port: 8332
username: srty
password: password
device: 9600gso
extra flags: -b -w 128          <--it doesn't like -v(that makes it run at about 13M/Hash)

.conf settings...
rpcuser=srty
rpcpassword=password
rpcallowip=*.*.*.*          <--should this be my actual IP address or do asterisks allow anything?

.cfg settings
host=localhost             <--What should this be?(do I even need this for the GUI)?
port=8332
rpcuser=srty
rpcpass=password

[jgarzik]

At one point, it just kept saying "connection problems". I changed something though, and now I don't see that anymore.  Here's all my settings.  I'm trying to get it to check a local client for stales since my card isn't very fast. It's a 9600 GSO, which gets about 21 M/hash.  I only have 1 machine, and it's connected to the internet through a wired connection, but through a router.  I'm trying to set it up for pooled mining.

If you're using long polling, you should not need a local client, nor get any stales.

[dishwara]

I too tried with Extra flag -b in GUI & also in cmd, both unable to connect & removed -b & its working fine.
Don't know how to make miner to know new block came.

[geebus]

I too tried with Extra flag -b in GUI & also in cmd, both unable to connect & removed -b & its working fine.
Don't know how to make miner to know new block came.

If it's saying that it's unable to connect, it's due to the fact that your local running version of bitcoin does not have the -server flag set on it.

[srty]

Ok, if you say long polling will make it so I don't need to check against a local client, I'm more than happy to try that, but how do I set it up on the GUI client?

[walidzohair]

How can i transfer the bitcoins to my account ? or is it fully automated ?

and what about if i want to change my bitcoin address ?

[geebus]

Ok, if you say long polling will make it so I don't need to check against a local client, I'm more than happy to try that, but how do I set it up on the GUI client?

The newest version of Kiv's gui has long polling support. I've updated our command line version, but not the GUI version yet. It seems the long polling helps a bit to keep your efficiency up, but isn't quite as effective. I tested with Kiv's latest GUI and had between 77% - 85%. Not too much of a drop though.

Anyway...
[urlhttp://bitcointalk.org/index.php?topic=3878.0]Kiv's latest GUI miner[/url]

poclbm-mod 03.16.2011 (Latest) [Win32/Source] 7.8MB

[geebus]

*** UPDATES ***

• I re-wrote the pool daemon to use a completely different framework that is much faster, and more scalable. This should result in dramatically less server outages and connection issues.
• I've updated the latest version of m0mchill's poclbm to have additional statistical output and better handling of keyspace. Even with long polling, the main version is still averaging 5 - 10 seconds before asking for more work, which prevents you from working through the entire getwork.
• We support long polling; Long polling is essentially a side-channel socket that is held open by the client while it waits for the server to deliver data. In the case of long polling on a bitcoin pool, when the block changes, the server will provide a new getwork to each of the miners connected via long polling. This prevents the miners from working on old blocks and stale work.
  
  Currently, only m0mchill's poclbm, Kiv's poclbm-gui. and our poclbm-mod support long polling.

Download now: poclbm-mod 03.16.2011 [Win32/Source] 7.8MB

Kiv's latest poclbm-gui: http://bitcointalk.org/index.php?topic=3878.0

Please update your miners.

[[Tycho]]

It's nice that you adopted long polling too :)
Now you can really increase effeciency to the level of other pools.

Poclbm-mod was really quite ineffective - some users are running it in my pool, so i can compare statistics.
Stale shares percentage with usual GPU miners (w/o long polling) is currently ~1-2% and with poclbm-mod (w/o long polling) is ~3-4.2%
Some users managed to get less than 1% of stale shares w/o long polling by using luck or getwork intervals shorter than 7 sec.

Even with long polling, the main version is still averaging 5 - 10 seconds before asking for more work, which prevents you from working through the entire getwork.

Are you sure about that ? It should request new getwork only after checking through all the nonce or 60 seconds of work, whatever comes first.
All nonce is checked in ~7 seconds on 5870 GPU.

[jgarzik]

Currently, only m0mchill's poclbm, Kiv's poclbm-gui. and our poclbm-mod support long polling.

CPU miner supports long polling, as noted in the CPU miner thread:  http://bitcointalk.org/index.php?topic=1925.msg67246#msg67246

Switching CPU miners to long polling will likely have more beneficial effect on server load, versus GPU miners + LP, because CPU miners under long polling change to 60-second polling intervals.

[jgarzik]

All nonce is checked in ~7 seconds on 5870 GPU.

...unless nTime field is also incremented, which is a permissible optimization...

In the coming months, it is expected that the standard miner will use the algorithm of

     1. server sends new work, interrupting current miner work
     2. miner crunches nonce+ntime
     3. when new block arrives, go to step #1

That completely eliminates polling, unless a new block is not found on the P2P network in ~2 hours or more.

[[Tycho]]

All nonce is checked in ~7 seconds on 5870 GPU.

...unless nTime field is also incremented, which is a permissible optimization...

Yes, but i was talking about existing version.

[FairUser]

Even with long polling, the main version is still averaging 5 - 10 seconds before asking for more work, which prevents you from working through the entire getwork.

Are you sure about that ? It should request new getwork only after checking through all the nonce or 60 seconds of work, whatever comes first.
All nonce is checked in ~7 seconds on 5870 GPU.

Line 114 - 115 of BitcoinMiner.py

Code:

self.askrate = max(int(askrate), 1)
self.askrate = min(self.askrate, 10)

Yes, we're sure.  If you use more than 10 seconds for the askrate, it will force a maximum of 10 seconds.  So that great that it's ~ 7 seconds on that card, but not everyone uses the same card, and can take longer than 10 seconds to work through an entire getwork.

Also, poclbm requests a new getwork when the first nonce is found, and doesn't keep working through the rest of the getwork looking for more nonce's. You can find more than 1 nonce in a getwork.
These are just a few changes to our modified version.  We thought that checking the miner's local bitcoind would be a viable way to detect when the block changed and request a new getwork, but that's not always the best solution.  The reason that it is not the best solution is my local bitcoind may have been notified that the block count changed, but the pool's bitcoind may not have gotten the memo at the same time my local bitcoind did.  So a race condition is in effect, and the miner requests a new getwork, then seconds later the pool's bitcoind got the memo and updated it's block count, and the getwork my miner just got becomes stale.  But sometime's it's the other way around too.

So long polling seems to be the better solution.

[FairUser]

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.

[dishwara]

I don't know what improvement you did in your new release.
Before i used your poclbm-mod in other pools to mine which gave good result.
Now for the first time, my efficiency gone less than 44%, it never gone below 92% before.

Please is it me or some others also getting low efficiency with new release (16/2/2011).
So, i again gone back to use old version of your poclbm-mod.exe

[geebus]

I don't know what improvement you did in your new release.
Before i used your poclbm-mod in other pools to mine which gave good result.
Now for the first time, my efficiency gone less than 44%, it never gone below 92% before.

Please is it me or some others also getting low efficiency with new release (16/2/2011).
So, i again gone back to use old version of your poclbm-mod.exe

I'm noticing this happen on a few clients. I think I've tracked down the issue and I will have a new version up tomorrow night, or the following afternoon.

[[Tycho]]

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).
Who would care how many times miner requested getwork per one submitted share ? It would make sense only if pool is overloaded by requests.

Sorry if you were offended by my statement.