Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 862. (Read 4382653 times)

Please set your zoom in browser back to 100% ;-). Logo has same size for at least one and half year.

However I agree that site design isn't ideal.

Logo became bigger, so there is less useful space on right side and in statistics table each row takes 3 lines
(1
confirmations
left)

The site design was not great before the logo size change and now it became worse :-(

Thanks for the previous site updates, though, but navigation is still can be done much better. For example, btcguild have "24h earnings" value is accessible with no clicks whatsoever and it's placed on the most visible place. On the mining.bitcoin.cz you have to click at least twice and scroll one page to get approximately the same info (that miners are working fine and everything is okay)

Thanks for the pool and your support anyway. It's the best even with the ui.

ps my screen res is 1280x800

Thank you. Works perfect.

Panda Mouse

It is fine, cgminer also see 32 (168/32). So far everything is working good. You have less submissions, but every is credited for 32 shares. That's the point of user-defined difficulty. Your mining income isn't affected, but network resource usage is much lower.

If you want higher submission rate, please change it on pool profile (Edit worker). Especially for your hashrate, 32 is quite optimal. But if you really-really want, you may change it to something around 20...


What do you mean? I'm not a specialist to cgminer, but if there's some bug, please report it to cgminer thread...

krzys13, diff 37..168/32 (cgminer), stratum say diff 32.
I worked a months without the problems. Please restore it :-)
cgminer api (localhost) is working inproperly!

Panda Mouse

What means "very slow"? I probably rise your difficulty (I did it for some users and I changed them to very conservative levels). What difficulty do you see in your miner?

Proxy problem - it's working very slow.

Panda Mouse.

This is known problem of GUIminers, they sometimes don't reconnect on pool server restart . But that "check hardware" errors are (to 99.9%) unrelated to pool restart.

Mine was shut down too. I had to kill the proxy, and use guiminer to get it back online

This is not related to the pool, it usually indicates some hardware error, because gpu generates invalid shares. Or it may be a bug in GPU drivers. Is it overclocked? Is temperature OK? Did you tried to restart your machine?

Slush I am having a problem with the pool with 1 of my cards:

2013-03-08 15:58:56: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 15:58:56, Verification failed, check hardware! (0:0:Redwood, 854ebb5a)
2013-03-08 16:01:13: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:01:13, Verification failed, check hardware! (0:0:Redwood, 3183ec2b)
2013-03-08 16:02:30: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:02:30, Verification failed, check hardware! (0:0:Redwood, 47e5dd77)
2013-03-08 16:04:40: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:04:40, Verification failed, check hardware! (0:0:Redwood, 4fd58290)
2013-03-08 16:08:56: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:08:56, Verification failed, check hardware! (0:0:Redwood, 2c2c4891)
2013-03-08 16:10:15: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:10:15, Verification failed, check hardware! (0:0:Redwood, d203069d)
2013-03-08 16:10:26: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:10:26, Verification failed, check hardware! (0:0:Redwood, f78cf4f2)
2013-03-08 16:11:19: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:11:19, Verification failed, check hardware! (0:0:Redwood, f7073cc2)
2013-03-08 16:13:01: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:13:01, Verification failed, check hardware! (0:0:Redwood, c935d101)
2013-03-08 16:13:36: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:13:36, Verification failed, check hardware! (0:0:Redwood, ca7ae314)
2013-03-08 16:15:14: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:15:14, Verification failed, check hardware! (0:0:Redwood, a14357d9)
2013-03-08 16:16:40: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:16:40, Verification failed, check hardware! (0:0:Redwood, ea73bd8d)
2013-03-08 16:16:49: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:16:49, Verification failed, check hardware! (0:0:Redwood, ea42a3fc)
2013-03-08 16:16:59: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:16:59, Verification failed, check hardware! (0:0:Redwood, f9a0ee29)
2013-03-08 16:18:05: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:18:05, Verification failed, check hardware! (0:0:Redwood, 937d93ee)
2013-03-08 16:18:12: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:18:12, Verification failed, check hardware! (0:0:Redwood, c4b25d79)
2013-03-08 16:18:39: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:18:39, Verification failed, check hardware! (0:0:Redwood, 1ca834b8)
2013-03-08 16:19:25: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:19:25, Verification failed, check hardware! (0:0:Redwood, b7ebc3f0)
2013-03-08 16:21:35: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:21:35, Verification failed, check hardware! (0:0:Redwood, 3fdaf310)
2013-03-08 16:21:52: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:21:52, Verification failed, check hardware! (0:0:Redwood, 16865cc7)
2013-03-08 16:25:18: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:25:18, Verification failed, check hardware! (0:0:Redwood, b80e1f9e)
2013-03-08 16:25:26: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:25:26, Verification failed, check hardware! (0:0:Redwood, d19a1157)
2013-03-08 16:26:59: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:26:59, Verification failed, check hardware! (0:0:Redwood, 83ecf93a)
2013-03-08 16:28:58: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:28:58, Verification failed, check hardware! (0:0:Redwood, 6ef74650)
2013-03-08 16:30:16: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:30:16, Verification failed, check hardware! (0:0:Redwood, 9d343a7e)
2013-03-08 16:30:31: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:30:31, Verification failed, check hardware! (0:0:Redwood, a32b1614)
2013-03-08 16:31:09: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:31:09, Verification failed, check hardware! (0:0:Redwood, 0c633d11)
2013-03-08 16:31:48: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:31:48, Verification failed, check hardware! (0:0:Redwood, 05e3be0a)
2013-03-08 16:31:49: Listener for "Default": api2.bitcoin.cz:8332 08/03/2013 16:31:49, Verification failed, check hardware! (0:0:Redwood, 83a7e1c6)

What is this?

User-defined (choosable) difficulty released!

I just made probably the biggest update of Stratum pool since stratum mining has been introduced. Now all Stratum miners can define their own difficulty for each worker. Until now, miners were generating difficulty-1 shares and they had been credited by one share in pool database. Now miners can work on higher difficulty, say 5, which means that it is 5x harder to find a share, but pool will credit the worker for five shares in database for every share submission.

This feature is aimed to ASIC miners and big mining operations, because it drastically optimized communication overhead. You can have 1Thash/s miner connected to the pool and network communication will consume less than 10kB/minute...

Downside of this feature is that it slightly increases variance in share submissions, which may increase variance in block rewards. However, it definitely doesn't affect overall mining income in longer timeframe like one day. It is still important to don't set the difficulty too high. Thanks to my calculations, having 10-20 share submissions per minute will give you very low variance.

How to change worker difficulty:
There's a new option on worker edit form (web profile -> edit worker). You have two options. First is to put difficulty to input box manually. This is aimed mostly to advanced users, who want fine-tune their settings. For most of others there's simple dropdown list. Just select hashrate range which fits your mining rig and pool automatically converts your selection to appropriate difficulty number. Once you change the settings, pool will apply this difficulty in two minutes even on existing stratum connections (no need of miner restart).

If you're using more miners behind stratum mining proxy, then all miners will use the highest difficulty of connected workers. It's not a bug, it's a feature :-). Please consider model case of one very slow (difficulty 1) and one very fast (difficulty 10) miner behind the proxy: the difficulty will be set to 10, which means that the slow one will need quite a long time to generate share. But when it happen (it happen with 10x lower probability than on difficulty 1), the submission will be still credited for 10 shares! For getting stable block reward, the important is the rate of submissions, not *which* miner generated it. Actually I encourage users to use stratum mining proxies if they have more miners on the same location, because it help optimize network overhead (because all miners re-use the single connection).

I'm also sorry that introducing such important feature took me too much time, but I'm currently busy with more Bitcoin projects (like Trezor). I'm still happy that I finished the project before #1 batch of Avalon ASIC miners come to their owners...

P.S. During the update I also changed block size limits on stratum servers (as Gavin and Mike asked me). Pool now creates blocks up to 500kB instead of previous limit of 250kB to help the network with increased traffic.

Actually I just forget to update json format . Very soon...

Slush, great job introducing "your_shares" column in the statistics. When will this field be included in Json files?
Thx.

It gives a possibility to slow down submission rate for fast mining rigs (in terms of GHashes or more). It improves network efficiency, lower communication overhead and lower pool load.

It's still just an option on website, it's not working yet. I'm working on release right now and I'll do full announcement soon...

What is the "Suggested difficulty" for the miners .... ?

Thanks !!

Would it be possible to show some proxy performance stats in future versions ? (and optional .log the current "INFO" ?)

Testing of new version is going well, I'll release it in few hours!

I'm waiting for a 1st confirmation of a 5 btc transaction (not pool related) for over 8 hours now. So, the issue is clearly with the btc network.

I changed maxblocksize already, but I'm waiting with bitcoind restart to tomorrow when i'll do pool update about user-defined difficulty, to keep downtime to minimum.