[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[pekv2]

We're on a biggie.

atm Current round duration:   7:35:22 

[slush]

We're on a biggie.

atm Current round duration:   7:35:22  

Yes, I checked pool status, but everything looks good and it's just unlucky round. Still not the worst round of pool history, but we aren't on the end yet .

[AniceInovation]

10 hours, 1 minute and 17 seconds.
That was A block!

[dishwara]

10 hours, 1 minute and 17 seconds.
That was A block!

Reason is very simple.
So far LP not implemented & many left the pool.
The total hashing power of pool reduced to ~1500 GH/s. While deepbit still has 5000+ GH/s

[pekv2]

Despite this last 10 our block, on a normal bases of a good round block of 2 min to 1 hour, I make a shit load more at slush's versus deepbit.

For Slush's, I made 0:34:49    696301    0.02788551

If that was deepbit, same duration time, I would have pulled in something like 0.00325225

Don't know why it is like that, but I won't leave slush's.

[AniceInovation]

Me myself am waiting for the RollNtime  update, i have an unstable internet, and if my miners get some troubles to connect to the pool, they won't get idle and keep mining.

[slush]

Hello,

today I upgraded pool backends, maybe you noticed few extra "rejected" shares because of restarts. Now everything runs smoothly again.

Thanks to this update, you can now connect as many miners to one "worker account" as you wish; I finally reworked pool core so this stupid rule isn't needed anymore.

[RobertRibbeck]

Hello,

today I upgraded pool backends, maybe you noticed few extra "rejected" shares because of restarts. Now everything runs smoothly again.

Thanks to this update, you can now connect as many miners to one "worker account" as you wish; I finally reworked pool core so this stupid rule isn't needed anymore.

A FEW -- try a lot -- and still commimg

[slush]

A FEW -- try a lot -- and still commimg

I don't understand. Do you see some problems on your side? Higher stale ratio? What miner, what username/worker login, please?

[RobertRibbeck]

A FEW -- try a lot -- and still commimg

I don't understand. Do you see some problems on your side? Higher stale ratio? What miner, what username/worker login, please?

I didn't before your change

phoenix.exe -u http://RobertRibbeck.  gt220 and gt430 :xxx@api.bitcoin.cz:8332/;askrate=15 -v -q 1 -a 25 -k poclbm platform=0 DEVICE=0 AGGRESSION=5  FASTLOOP BFI_INT

[slush]

RobertRibbeck: How many stales did you receive?

I also reported to phoenix developers that phoenix is very unstable on some conditions. It has probably too short network timeout, so phoenix prints 'rejected' although pool accept that share without any problem. It is case of one my miner, where phoenix reports almost 10% stale, but I in fact all of them are accepted. Network latency was 60ms + pool response time under 10ms in case of debugging... I still don't have any response from developers about this issue, but I'm almost sure that phoenix is just too much sensitive to network quality.

[slush]

Beta testers wanted!

I'm proud to announce public beta of long polling and ntime rolling on my pool. This update should lower stale ratio and reduce network overhead for your miners.

Because all of that code is pretty fresh and isn't tested under heavy load, I don't want to turn it on for everybody right now. It is also impossible to carefully test all miner versions and other special tools which some of you are using. Now you have a chance to test your miners and report any problems to me (please contact me directly to info@bitcoin.cz instead of writing to forum to keep this thread sane).

Beta version is running on one backend only, so it can become quite unresponsive in case of big interest. I recommend you to connect only one GPU core to test. Also keep on mind that it's beta and backend might be restarted few times to fix some minor issues.

If you're interested to help me with testing, connect your miner to api.bitcoin.cz, port 8331 (not api2.bitcoin.cz!). Of course all submited shares are calculated to your reward, beta environment is *not* a standalone pool.

[slush]

Notice to miners: I tested beta version heavily with poclbm, diablo, phoenix and cgminer. There is only one known issue with phoenix (latest SVN version) as is described also in previous post:

Phoenix is very sensitive to some conditions and may print many 'rejected' although those shares are perfectly valid and accepted by pool. I have such problem on one my machine and also one other user confirmed this. On the other hand, I know about many phoenix instances which run without any problem.

I'm trying to discuss that issue with developers, but currently I'm waiting to their response. If you see higher stale ratio on your phoenix, please check number of accepted shares on your profile page before you'll report that problem.

[RobertRibbeck]

RobertRibbeck: How many stales did you receive?

I also reported to phoenix developers that phoenix is very unstable on some conditions. It has probably too short network timeout, so phoenix prints 'rejected' although pool accept that share without any problem. It is case of one my miner, where phoenix reports almost 10% stale, but I in fact all of them are accepted. Network latency was 60ms + pool response time under 10ms in case of debugging... I still don't have any response from developers about this issue, but I'm almost sure that phoenix is just too much sensitive to network quality.

Where I saw 5% in the past now it's near %40
and they are not accepted on your listing

[cosurgi]

Where I saw 5% in the past now it's near %40
and they are not accepted on your listing

On beta test (LP+ntime) I have 0.1% rejects so far (only 7000 shares submitted so far), and I use latest phoenix version r116. On regular pool without LP (not-beta) I have about 1.2% rejects.

Did you try beta pool?

[pekv2]

Thanks Slush, I've joined the beta testing just now. Using GUIminer v2011-08-24, openCL.

As I am using the newest guiminer, I don't think it reports any rejects/stales even if there are any. So I would not know on how to report if any happen or not.

[slush]

As I am using the newest guiminer, I don't think it reports any rejects/stales even if there are any.

Menu -> View -> Summary :-)

[pekv2]

As I am using the newest guiminer, I don't think it reports any rejects/stales even if there are any.

Menu -> View -> Summary :-)

Yea, they are at 0 but I could have sworn I've seen that the new guiminer does not display correctly for stales "somewhere in GUIminer thread, when it was released" , if I am wrong please correct me. If it does display correctly I have received 0 stales since the newest guiminer was released.

[slush]

Yea, they are at 0 but I could have sworn I've seen that the new guiminer does not display correctly for stales "somewhere in GUIminer thread, when it was released" , if I am wrong please correct me.

I'm not regular guiminer user, maybe you're right. But there should be also console view showing raw miner output, including stales. But that's thin ice for me, I didn't tried it...

[cosurgi]

after whole night of mining on beta pool I have:
- 0.04% rejects with phoenix r116 (13 rejects on 34028 shares)
- 0.2% rejects with cgminer 2.0.4 (22 rejects on 10693 shares)