Topic: Join a pooled bitcoin mining effort - page 5. (Read 53323 times)

Got it running, but if you want to attract more people, the process to get it running could be simpler.
Especially because this is a good incentive for new users so they get faster new coins, but imho these user will make less effort to get it running.

It's just a low-end 9500GT with an Intel E5200 Dual-core for the CPU. I should of put a second CUDA client up before I left home.

what GPU/CPU do you use?

the cuda-client is still experimental and sadly burns the CPU by ~50% (on a dual-core)
and at the same time only loads the GPU to 50%.

that's why i usually don't use the cpu-client on the same machine,
but i just tried and it gets ~1000khash/s, like on my other machine per core too,
and it doesnt really slow down the cuda-miner, it still gets it's <18M.

it's more efficient though (at least on my config) to start a second cuda-client,
results in 100% CPU, ~70% GPU load and a few more Mhashes (<18M single, 2x~13M 2 instances).

but everything will be even more sluggish.

I'm running the CPU and CUDA client at the same time. Am I doing it wrong? One client claims to have 1100 khashes and the GPU has 5000 khashes; however, everything is really sluggish.

Yep, the server program exited overnight - not sure why. I've restarted it.

Maybe it would be useful to have a backup server? You could have users enter two IP addresses and have it try the second if the first goes down. Seems easy to me, but I wouldn't know.

Ok!  Everybody back in the pool! 

http://www.youtube.com/watch?v=YV-3wV7gfo8

yep, server seems down right now,
keep mining on your own machine as long as it takes, maybe you are (very very very) lucky.  

Looks like the server is down…

etc…

Welcome.

I don't think that would be hard to at all. I actually assume it would just be a variable change. Right now it looks at something like contributed in the last minute as a proxy for current hashing speed. Increasing this to an hour or even a day might be reasonable. But again given the choice between joining two otherwise equal pools the one with the least dead weight will tend to be preferred.

I don't think any of this has to do with fairness as long as there is no deception. I was only suggesting that it total contributed might not be an equilibrium.

Hi, I'm relatively new to the Bitcoin community (only discovered it a few days ago) and am still trying to get my feet wet here, but I've run this mining client for a day or two and wanted to give my two cents regarding the "contributed" vs "connected" issue.

As people before have said, it really depends on whether you view it as a chance effort (which it actually is) or a contribution effort.  Personally I'd feel rather ripped off if I'd been running the server for a week solid, only to have the block found when my connection randomly died for a split second, and not receive anything at all for my contributed CPU time.  At the same time, I understand FreeMoney's point that when in "contributed" mode, you won't get barely anything unless you joined immediately after the previous block was discovered.

So why not try a hybrid of the two?  In other words, work in contributed mode, but only consider contributions for the past X amount of time, where X is some percentage of the average time between block discoveries.  

Let's say for instance that on average, it takes 7 days for the mining group to discover a new block.  How about every few minutes we recalculate the contribution percentages based on the past 24 hours?  That way, the person who contributed 50 high-end servers to the effort still gets his share if he happens to drop offline for a brief moment, but if he goes offline for an extended period of time, his claim gets redistributed to those who were present around the time the block was actually discovered.  While technically less accurate than connected mode, it makes people feel better about their contributions without the stacked unfairness suggested by FreeMoney.

I don't know how difficult it would be to code this type of thing up, but it's food for thought at least.  

Suppose there are two pools with roughly equal hashing power, one that got a block 1 day ago and one that got it's last block 1 week ago. They are equally likely to hit the next block, but if I jump on to the first one I will get a much larger share. Anyone paying attention will do the same.

Imagine an extreme case, a group works for a week making no block and they all quit. How silly would I be to join with all the shares owed to them?

I'm conflicted on this... I can see either way making a lot of sense. It's a matter of whether you think of generation as working toward a goal, with everyone who worked toward it deserving credit, or closer to the non-pooled setup, where each second (or Arbitrary Small Time Unit of your choice) there's a total number of hashes and thus an X% chance of "hitting the lottery" and making some coins, which should only go to those clients who were connected for that "second" and thus were part of the hashes that succeeded. I would expect that they should behave about the same on average over time. I'm leaning toward the "connected" method at the moment, but I was leaning toward "contributed" when I first heard of it being an option. The concern someone mentioned about how "contributed" might be gamed somewhat as people switch around as each client knows how much has been contributed to each server I think may be valid, but maybe it too just averages out over time.

I think the theory is that there will be servers of both types set up, and each user can connect to the type that they think is most "fair", and everyone will be happy.

Wild swings in the total hash rate again. 80k to 140k.

Nevermind, appears to have recovered. Something strange in the code possibly.

Looks like the calculation for total server khash is broke, getting zero reported khash result, and totals for server in messages.

xx00 xx33 xx66 is rounding issues i guess (i'm not into the code, so i actually have no idea).

speed for me is like
standard 3800khash/s
pooled 3300khash/s (3x1100)

maybe we get the 4way-algo into the remote-miner soon, that would speed up some CPU-cores for the pool

I am using a quad-core. I run 3 instances which sum to ~2100 khash/s. This results in >95% CPU usage since the rest of the system also needs some percent. The standard client does ~3600 khash/s.

Btw, why are the reported khash/s always xx00 xx33 and xx66?

seems to work nicely although it's somewhat slower indeed, but i wasnt getting any blocks anyway so maybe this gives a a few bitcoins