[ Bonus PPS Pool - 130% PPS - OPEN ]

[-ck]

I was reluctant to switch to cgminer, but i did.... Works perfect... Very easy to use

[1713557225]

1713557225

[1713557225]

1713557225

[Math Man]

Yeah, I have a working cgminer installed as well as Phoenix2.  I get 10% high hash rate with Phoenix2 though.  So, cgminer is definitely my last resort.

[Clipse]

Yeah, I have a working cgminer installed as well as Phoenix2.  I get 10% high hash rate with Phoenix2 though.  So, cgminer is definitely my last resort.

Which kernel do you use in cgminer and phoenix2 ? I used to run poclbm+phatk2 / phoenix2 + phatk2 and my cgminer setup is on par if not faster than the old setup.

Also make sure its not an old cgminer version in case you havnt updated, alot of updates happened recently.

Lastly, try increase you getwork queue size for phoenix2 from its default value by 1 and see if that works better.

[Math Man]

Yeah, I have a working cgminer installed as well as Phoenix2.  I get 10% high hash rate with Phoenix2 though.  So, cgminer is definitely my last resort.

Which kernel do you use in cgminer and phoenix2 ? I used to run poclbm+phatk2 / phoenix2 + phatk2 and my cgminer setup is on par if not faster than the old setup.

Also make sure its not an old cgminer version in case you havnt updated, alot of updates happened recently.

Lastly, try increase you getwork queue size for phoenix2 from its default value by 1 and see if that works better.

Thanks for the ideas.  I'm going to give it a shot later tonight.  I have to go help my sister-in-law move.  Oh how I wish that mining software could be a priority over helping her move.

[Clipse]

Yeah, I have a working cgminer installed as well as Phoenix2.  I get 10% high hash rate with Phoenix2 though.  So, cgminer is definitely my last resort.

Which kernel do you use in cgminer and phoenix2 ? I used to run poclbm+phatk2 / phoenix2 + phatk2 and my cgminer setup is on par if not faster than the old setup.

Also make sure its not an old cgminer version in case you havnt updated, alot of updates happened recently.

Lastly, try increase you getwork queue size for phoenix2 from its default value by 1 and see if that works better.

Thanks for the ideas.  I'm going to give it a shot later tonight.  I have to go help my sister-in-law move.  Oh how I wish that mining software could be a priority over helping her move.

Hehe np

Just something to remember when using cgminer make use of the following launch switches by using phatk for 5xxx/6xxx cards and diakgcn for 7xxx cards, cgminer -k phatk/or diakgcn --no-submit-stale --no-pool-disable  then the rest of the stuff you can enter once as it prompts then in the gui simply goto pool management to configure the backup pools then to settings and write the config, next time you simply need to run cgminer without any extra switches.

If you knew all that, ignore what I said.

[Clipse]

NOTICE TO GPUMAX/BACKUP ONLY USERS:

I am only accepting dedicated miners from now on for the waitinglist so if you are interested in using signing up to use Bonuspool as your backup pool then you dont have to bother signing up at all right now.

Also if there is no spots available I will start pruning GPUMAX/Backup users from the pool first in order to make room for dedicated miners.

GPUMAX/Backup users, changes will be announced soon either before this coming Sunday otherwise before next week Wednesday regarding the future of Bonuspool for you, stay tuned to this thread as I will only make the announcement here. Our dedicated miners have grown large enough to maintain Bonuspool for now and I wish to give them priority/peak performance at all time.

[-ck]

Just something to remember when using cgminer make use of the following launch switches by using phatk for 5xxx/6xxx cards and diakgcn for 7xxx cards, cgminer -k phatk/or diakgcn --no-submit-stale --no-pool-disable

You know I think your users would be unhappy if there was a problem on your pool again and they started getting infinite rejects and cgminer didn't disconnect them. That's why that feature is there in cgminer in the first place. Plus the code to try to reconnect afterwards has been upgraded so there's a chance it may work by now. To me it would seem more important to the miners that they were hashing sensibly rather than staying connected 100% to your pool.

[Clipse]

Just something to remember when using cgminer make use of the following launch switches by using phatk for 5xxx/6xxx cards and diakgcn for 7xxx cards, cgminer -k phatk/or diakgcn --no-submit-stale --no-pool-disable

You know I think your users would be unhappy if there was a problem on your pool again and they started getting infinite rejects and cgminer didn't disconnect them. That's why that feature is there in cgminer in the first place. Plus the code to try to reconnect afterwards has been upgraded so there's a chance it may work by now. To me it would seem more important to the miners that they were hashing sensibly rather than staying connected 100% to your pool.

Fair enough, I have however been testing by forcing multiple times killing the pool and at worse it would spam a few rejects and either drop for backup pool or reconnect to bonuspool. Ive not noticed a single instance since the recent updates where it would just continually hang with neverending reject spamming.

There is however alot of instances with some users where they manage a large farm and bonuspool on only a few of their rigs remain disabled indefinitely, did you add code that would automaticly re-active disabled pools perhaps ? If you do have such code in cgminer then it would obviously remain beneficial for everyone not to add the --no-pool-disable line.

[-ck]

Just something to remember when using cgminer make use of the following launch switches by using phatk for 5xxx/6xxx cards and diakgcn for 7xxx cards, cgminer -k phatk/or diakgcn --no-submit-stale --no-pool-disable

You know I think your users would be unhappy if there was a problem on your pool again and they started getting infinite rejects and cgminer didn't disconnect them. That's why that feature is there in cgminer in the first place. Plus the code to try to reconnect afterwards has been upgraded so there's a chance it may work by now. To me it would seem more important to the miners that they were hashing sensibly rather than staying connected 100% to your pool.

Fair enough, I have however been testing by forcing multiple times killing the pool and at worse it would spam a few rejects and either drop for backup pool or reconnect to bonuspool. Ive not noticed a single instance since the recent updates where it would just continually hang with neverending reject spamming.

There is however alot of instances with some users where they manage a large farm and bonuspool on only a few of their rigs remain disabled indefinitely, did you add code that would automaticly re-active disabled pools perhaps ? If you do have such code in cgminer then it would obviously remain beneficial for everyone not to add the --no-pool-disable line.

As said above in red. But it has not been tested, or if it has, it's done it without anyone even knowing it.

[AndrewBUD]

I send in stales/rejects... Has been working fine. under 1%

[Clipse]

I send in stales/rejects... Has been working fine. under 1%

Yep it doesnt work sometimes but Ive actually tested this over a long run and from what I saw submitting stales caused high rejects/stales than using the no-submit-stale switch, each to their own and if people dont mind it then its fine with me, the difference wasnt big but definitely noticable.

[-ck]

I send in stales/rejects... Has been working fine. under 1%

Note that KNOWN stales in cgminer do not count towards disabling a pool. It is only if there is a 3 minute run of unexpected rejects in a row without a single accepted share. Only an extreme situation would cause this. Using --no-submit-stale does not change the chance of hitting this either... As always I put a lot of thought into my defaults. Using --no-submit-stale only decreases the reported stale rate and occasionally you miss out on a possible share you would have gotten paid for due to laxity at the pool end so you lose nothing but stats by submitting them.

[AndrewBUD]

That's what I figured.... with the stales/retards so low now...... I feel it makes no difference..... IMO.....

[bulanula]

I send in stales/rejects... Has been working fine. under 1%

Note that KNOWN stales in cgminer do not count towards disabling a pool. It is only if there is a 3 minute run of unexpected rejects in a row without a single accepted share. Only an extreme situation would cause this. Using --no-submit-stale does not change the chance of hitting this either... As always I put a lot of thought into my defaults. Using --no-submit-stale only decreases the reported stale rate and occasionally you miss out on a possible share you would have gotten paid for due to laxity at the pool end so you lose nothing but stats by submitting them.

Defaults are perfect for me.

Don't use --no-submit-stale because there is a chance you might miss on a good share.

Don't use --no-pool-disable because I tested it and it works just fine on another pool which also had problems like Clipse's pool. It will stop talking if the pool freaks out and rejects all shares for like 5 minutes then it will come back up automatically when pool behaves again - I have this tested on LAN proxy too and it works extremely well FYI.

Thanks ckolivas !

[Clipse]

Server is a tad overloaded right now and you may notice occasional stalerate spikes but shouldnt be much higher at all.

As said before I will look into best approach to deal with this scaling issue over the weekend.

[Gomeler]

Is this simply a case of too much hashing power being directed @ bonus pool? Would be interesting/fun to see a page with server load/throughput stats.

[Clipse]

Is this simply a case of too much hashing power being directed @ bonus pool? Would be interesting/fun to see a page with server load/throughput stats.

Too much irratic hashrate bumps due to alot of come-and-go'ers. I will have that sorted out though.

[Clipse]

Waiting for 2 new dedicated server allocations, I should have it within the next 48hrs. In the meantime I will test the configuration to end up on that.

[AndrewBUD]

Does that mean we get a 80% increase on the PPS rate? ...


have a nice weekend bud

[Clipse]

Quick reset, gotta increase the current pool caching for the influx of trolls and they hashing powahs.

re rates: When you start seeing more stales than the extra earnings we can talk