|
@simonk
What miner are you using? It looks like your miner is giving up to quickly and just dumping oodles of getworks on bitHopper.
And yeah it should use request.notify and exit the requests appropriately but I haven't written it yet.
|
|
|
|
|
@gentarkin / HOW DOES IT WORK
We assume if the LP response from deepbit is first then deepbit owns it. We actually reset the owner to take into account if another pool drops but currently we don't reset deepbits starts due to that.
It looks like efficiency is good. Parai got about 168% and magnet got about 559% efficiency. I just did the calculations for you guys.
EDIT:However I haven't actually gotten my server to mine on deepbit. Only my dev machine. So there may still be errors.
|
|
|
|
|
If we could get deepbit to change from proportional to empps or something similar it would be amazing. I'm sure they will just degrade their LP responses though...
|
|
|
|
|
mine_deepbit should have worked. What scheduler are you using?
|
|
|
|
|
I just fixed the LP system, I shouldn't have tried to be lazy and use an int as a semaphore.
It should work with all of the schedulers.
|
|
|
|
|
Yeah but see how it doesn't make another lp call? Thats a problem. And why it works for at most 1 round for eveybody. I think I fixed it, but I'm still testing.
|
|
|
|
|
There is a bug with deepbit and LP in general where once it gets called once it isn't called again. I'm debugging.
@gtrrkicw
No need to set disabled pools to info. It works with all schedulers. It looks like you make the most money off of olddefaultscheduler
|
|
|
|
|
@rampone
Footer on this message is correct.
|
|
|
|
|
Just start with --startLP and have deepbit in you user.cfg. No need to play with anything else. No guarantees it works however.
|
|
|
|
|
It only resets pools with mine_Deepbit as role. And at least one of those blocks was from btcguild and the LP based ID was probably wrong.
EDIT: And some pools push out invalid LP's So far I've noticed Monkey doing it along with some others.
|
|
|
|
|
Yeah btcguild will work. Anything will work although it may not be that accurate
EDIT: But really: MINE DEEPBIT. They will make you the most money. Seriously.
|
|
|
|
|
Um bclc shouldn't affect anything either way. In fact if you want to mine them and not deal with their messing around use re_rate and mine_deepbit and scrape them with LP. You have to change the regular expressions to supply rate instead of shares though.
|
|
|
|
|
@djex
Um we actually don't use the other servers in the latest iteration. We probably should. But our cutoff times are a lot better.
|
|
|
|
Wiki history shows who did what. I'll track em down  |
|
|
|
|
Um, I just redid the whole deepbit system again to produce estimated share counts. So every scheduler now works!
|
|
|
|
|
Um. Enable everything which produces valid share counts. If in doubt: don't. Then add deepbit with role:mine_deepbit in user.cfg.
Then start bitHopper with --startLP.
Soon that option will be by default once I get the deepbit share estimator working.
If any errors appear: Tell me.
|
|
|
|
|
Deepbit Hopping is finally working for the default slice scheduler. I'm going to add in an estimation function and then get it working for the old scheduler since it looks like that might be a better scheduler.
|
|
|
|
|
@organ
What about slicing? Worth it or not?
|
|
|
|
|
Show Posts
