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

Thanks bud, I knew there would be a good reason not to do it. 

Hey Slush.  Would you consider charging only a 1% commission out of the goodness of your heart?

Hey Slush have you switched payout to only daily or something?  Usually it goes out hourly but have been over the payout minimum for a few hours now.

Well, it is little complicated under the hood. Server must remember jobs which served you, to be able to perform some checks on share submitting. As the server has limited memory for every worker jobs, with knowledge of user/password, the attacker can make your mining impossible by erasing your worker queue. Well, it is nothing to too much worry about, but posting your full worker credentials on the web isn't generally good idea.

Correct me if I'm wrong, but if someone uses my worker's username they just generate bitcoins for me. So what is the purpose of the password?

There are some technical reasons why it isn't good idea. In some cases your miners might duplicate the effort (and from two same submitted shares, only one will be accounted). Simply - don't do that, really .

Please select one from supported miners (in your case, it will be probably jgarzik's CPU miner) and follow instructions in his forum thread. The link is on the pool homepage. If you will have any troubles with that, don't hesitate to ask more specific directly in that thread.

Slush,

Do I actually need a seperate user entry for each miner? I just noticed that I accidentaly gave two of my miners the same username to use and it simply added both their shares together...

Pretty much wasting your time to put in simply.

But if you want to do it anyway, download the poclbm GUI miner which will come in a .7z archive. Extract this to a folder of your choice, then run the guiminer.exe file. Go to File>New Miner and give it a name. Then enter mining.bitcoin.cz for the server address.

Go to mining.bitcoin.cz and register an account, and then make a miner (It's under the "My Account" page, just click on "Add new miner".

Now back in poclbm under the new miner you just made, enter the username and password for your miner. This can be found under the my account page on mining.bitcoin.cz.

The go to File>Save Settings, and then start the miner. It will say in the bottom right how many Hash/s you are doing.

I fit in to this boat but for the life of me can't figure out how to use these "miner programs" to contribute to mining.bitcoin.cz
 

p.s. I'm currently not generating coins. I use windows xp. I have an IBP p4 think center. 

No, leave it as is. I had to restart bitcoin daemons on the server, so the stale shares were probably caused by short outage.

im getting some stales (1 per 20 valid blocks). should i set my askrate lower? right now, its 5 (poclbm default)

Hey Dude, thnx for your idea. I launched two processes on the problem GPU and it is now stable for over 6 hours (at best it was 1 hour before). If anyone is interested here is my convoluted launch process to get this thing crunching ...
in one terminal
$export DISPLAY=:0.(speedy GPU adapter number)
$fgl_glxgears
wait for some output to indicate fps are being crunched in gears then in another terminal (should have these commands ready to go with terminals and shells prepped)
$nice -20 ./poclbm.py -u miner0_username --pass=miner0_passwd -o mining.bitcoin.cz -p 8332 -v -w128 -f10 -d(speedy GPU)
and in yet another terminal
$nice -20 ./poclbm.py -u miner1_username --pass=miner1_passwd -o mining.bitcoin.cz -p 8332 -v -w128 -f10 -d(speedy GPU)
and as soon as processes report back hashing numbers kill (CTRL+C) fgl_glxgears.

Dirty hack I know but it works and is now stable, I can do a little script to launch this with a timer included. It was worth it because this core actually hashes 1-2MH/s quicker than other cores and wasn't worth sending back 5970 card for protracted warranty claim as it passed all the graphics tests anyway.

I think it is a problem with Xserver, (Xorg) fglrx kernel module and poclbm and a hardware weirdness whereby GPU doesn't like stopping and ramping up after a getwork pause but is fine if it is kept crunching maxed out .... maybe multiple processes can optimise GPUs in other ways ... -w 32 x 4?

Currently the poclbm does not drop job when share is found. Afaik the whole network stuff is in separate thread, so it should work 'asynchronous'. But I didn't do any debugging, maybe it is really handing somewhere. m0mchil performs new getwork before whole nonce space is crunched, so unless you have really crappy line, it should work fine.

Btw ongoing improvements in the pool will make network load waay lower than it is now. And I'm not talking only about long polling .

Anybody know if the poclbm.py miner is asynchronous? (I'll ask m0mchill also I guess) It is apparent on screen that hash rate drops after a block is accepted and new one is begun but is that what is happening on the core?

I wasn't going to bother with overhead of solo-mining set-up just yet but maybe it is way to work around buggy fast hot core ... or maybe put two processes on same core so it is always doing something regardless of getwork calls ....hmmm, thnx for the ideas.

I have a fairly crappy net connection, so to deal with it I run one copy of poclbm with a -f of 30-60 connected to the pool and a second copy with a -f of 200+ solo mining. The second copy gets about 5% of the gpu power when both are running but it picks up the slack immediately if there is a delay in the get work.

Edit: I have a satellite internet connection plus I use a VPN to avoid the 250MB a day download cap, but that puts me last in line for getting any bandwidth. About the only way my connection could get worse is if i used Tor as well.

Well, with well written miner, there is no reason why cores should wait on submitting shares; it can be done fully in asynchronous way (just send, don't wait - at least in blocking state - to response). Maybe the feature request to the miner developers? Blocking getworks are another issue, but I'm working on it - its long polling and next stuff comming soon.

The higher difficulty for fast cards are good idea, it is already on my list for some time. It will definitely come, I have some algorithms to find 'idea' difficulty for given worker in my head; will see how it will work in real life . Keep in mind that higher difficulty does not mean only lower network overhead, but also higher variance in round rewards and maybe also some new kind of pool attacks, so it need some care to don't break anything.

Hi slush,

I am wondering if you had considered increasing the difficulty for your pool shares?, i.e. making it >1

It would reduce getwork calls across the internet, for the higher hash rate cards it seems to make more sense to be working on a harder problem, maybe a separate pool for bigger cards? They spend quite a bit of time waiting for the new work, taken in clock cycles versus wall-clock ...

(also I'm a bit biased because I seem to have a speedy core that likes to run hot, fast and not stop ... it hangs when it ramps up after a getwork 1 in 1000 times??)

Then  your earnings are OK (I didn't recalculate it, but I'm 2.2 and have ~2x higher reward).


Well, it is generally true for all current pools - you don't earn anything when you're disconnected .

But if you're asking to score based system - it works quite differently than other pools. Extremely shortly - when you disconnect, reward for your contributed shares is going slightly down (is halved every 5 minutes), but when you connect in, it goes also up faster. When you connect in the middle of the round, after few minutes your reward is almost same as if you connected on the round beginning. So the score based system only affect behaviour of connecting/disconnecting, but does not affect your final reward, at least in long term (1000+ shares contributed to the pool by your miner). As you have >1Ghash/s, this does not affect you at all. So don't be affraid with connecting/disconnecting to the pool as you want.

This works as (quite effective ) defense against some possible pool attacks. Thanks to score based system, pool can also offer all system statistics in realtime (round start, current shares in round etc). Drawback of this method is that it introduce some bigger variance in reward for CPU users (but in all cases, after 1000+ shares it is statistically without difference).

You can read more details & watch pretty graphs done by cosurgi in previous thread post.

All shares are worth something. The older that a share is, the more that it degrades in value. As such, the shares that are submitted right at the end of a round are worth the most.

Because the end of a round is indeterminate, there is little to no incentive for waiting to submit shares until towards the end of the round because you don't know when the end of the round will actually be. For all that you know, the round could end 30 seconds after it began. In fact, this has happened many times, even with high difficulty. A round could also take 9+ hours (this has also happened).

The odds that any single miner will find shares towards the beginning of the round or the end of the round are the exact same, regardless of the hashing power of that particular miner. You may find most of your shares at the beginning of this round, and then the next round you find most of your shares towards the end. It all evens out over time with statistical certainty.

It only takes ~1,000 shares (over the miner's entire lifetime, not just since it was last started) for the variance of this score based method to converge tightly with the variance of a standard share based method. For a CPU miner, that would take about 1 week. For a 5970, that could take less than 2 hours.