Search content
Sort by
Showing 20 of 50 results by ed64
Updated AltSliceScheduler to allow for round time biasing. Available at:
https://github.com/echiu64/bitHopper
Tested for a few hours, everything looks like it works. Tested with startLP enabled.
New options:
--altsliceroundtimebias Bias slicing slightly by round time duration with respect to round time target (default false)
--altsliceroundtimetarget Round time target based on GHash/s (default 1000 Ghash/s)
--altsliceroundtimemagic' Round time magic number, increase to bias towards round time over shares (default is 10)
https://github.com/echiu64/bitHopper
Tested for a few hours, everything looks like it works. Tested with startLP enabled.
New options:
--altsliceroundtimebias Bias slicing slightly by round time duration with respect to round time target (default false)
--altsliceroundtimetarget Round time target based on GHash/s (default 1000 Ghash/s)
--altsliceroundtimemagic' Round time magic number, increase to bias towards round time over shares (default is 10)
Wow, took forever to catchup. Looks like I'll need to merge in two methods of calculating round duration and pool speed. I have a different pools.cfg setup that works for re/json, as well as a time averaged estimate, rather than a point in time, which tends not to be very accurate. Borrowing from ryo's initial impl, I believe typically the estimates aren't "shared" until at least 5 minutes (or more) have passed (should probably be done on a per pool basis)...
All the LP work looks interesting, not sure how much relevant some of the slicing schedulers will be once that gets perfected...
All the LP work looks interesting, not sure how much relevant some of the slicing schedulers will be once that gets perfected...
@GenTarkin For me mine_slush works nice in the default scheduler, dunno if it matters but I played with penalty too (1-4)
Personally I think mine_slush should be removed and replaced by penalty, it's more dynamic and can account for say a 100ghash pool that delays stats by 1 hour (still hoppable). While a pool that delays stats for 1 hour > 1Thash/s, it's impossible to know where they are....
Or for smaller/slower pools, I put in a penalty so I don't mine too much on them, since payouts take forever...
Ya, that's the messed up part, just went from Chrome/13.0.782.107 to Chrome/13.0.782.109
So they must be doing something whacky, because a user agent like "curl" will work, but the Chrome/13.0.782.107 won't. Seems pretty unreliable whatever is that is happening....
Maybe an IE user agent string is better, those don't change as often and would impact more users should they choose to do anything based on user agent
So they must be doing something whacky, because a user agent like "curl" will work, but the Chrome/13.0.782.107 won't. Seems pretty unreliable whatever is that is happening....
Maybe an IE user agent string is better, those don't change as often and would impact more users should they choose to do anything based on user agent
Try updating your user agent, looks like digbtc is messing around a little
Oddly a user agent like 'curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18' works fine as well. wth...
Oddly a user agent like 'curl/7.21.0 (x86_64-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18' works fine as well. wth...
Code:
diff --git a/work.py b/work.py
index bcac801..836ef1d 100644
--- a/work.py
+++ b/work.py
@@ -73,7 +73,7 @@ def jsonrpc_lpcall(agent,server, url, lp):
@defer.inlineCallbacks
def get(agent,url):
- d = agent.request('GET', url, Headers({'User-Agent':['Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1']}),None)
+ d = agent.request('GET', url, Headers({'User-Agent':['Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.109 Safari/535.1']}),None)
response = yield d
finish = Deferred()
response.deliverBody(WorkProtocol(finish))
index bcac801..836ef1d 100644
--- a/work.py
+++ b/work.py
@@ -73,7 +73,7 @@ def jsonrpc_lpcall(agent,server, url, lp):
@defer.inlineCallbacks
def get(agent,url):
- d = agent.request('GET', url, Headers({'User-Agent':['Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.107 Safari/535.1']}),None)
+ d = agent.request('GET', url, Headers({'User-Agent':['Mozilla/5.0 (Windows NT 5.1) AppleWebKit/535.1 (KHTML, like Gecko) Chrome/13.0.782.109 Safari/535.1']}),None)
response = yield d
finish = Deferred()
response.deliverBody(WorkProtocol(finish))
If BH can't get the round shares, it defaults to current difficulty, which is 1888786
There seems something wrong with DIGbtc. On BH there are 1888786 shares 100.00%,.. on their site it's "Round Shares: 1133369".
FYI still working on AltSliceScheduler, no updates to push yet. Working on getting pool speed, duration time from JSON/RE. Have maybe 50% of pools done. Next step will be to add in a new option to hop based on some combination of round time and # of shares.
Finding an optimal point on duration vs shares will be interesting.
Also merged in some of ryouiki's code to estimate round time / pool speed as well, takes hours to stabilize and have anything reasonable though.
I may add an option of how much the round time factors into each slice as well.
And yes I do have a solution for btcmp.com, but i'm concentrating on the round time solution first.
Will need some volunteers in the next few days. Any takers?
Finding an optimal point on duration vs shares will be interesting.
Also merged in some of ryouiki's code to estimate round time / pool speed as well, takes hours to stabilize and have anything reasonable though.
I may add an option of how much the round time factors into each slice as well.
And yes I do have a solution for btcmp.com, but i'm concentrating on the round time solution first.
Will need some volunteers in the next few days. Any takers?
It looks like LP is returning a url which is "" based on that error message.
I see something similar with digbtc recently, went away though. I set a penalty of 2 or so it slices less frequently... I penalize smaller pools since their stability isn't that great.Odd, I didn't touch anything to do with sending/getting work. Seems unrelated... do the logs tell you which pool? I find the newer/smaller pools more buggy and will cause these types of errors (like digbtc)
Getting quite a few of these errors in your version Ed, ill see if c00w's bithopper doing the same.
Strange part is it doesnt actually seem to matter, it still continues at the pool.
I have btcmp.com working, but it's been flaky the last few days (the pool itself). If it stabilizes, I'll release my patch (I didn't push it to github yet).
FYI i've patched up AltSliceScheduler, should be stable and a little more aggressive in switching pools when threshold is met (rather than finishing it's slice). Also the slices are truly proportional now.
FYI i've patched up AltSliceScheduler, should be stable and a little more aggressive in switching pools when threshold is met (rather than finishing it's slice). Also the slices are truly proportional now.
Getting quite a few of these errors in your version Ed, ill see if c00w's bithopper doing the same.
Strange part is it doesnt actually seem to matter, it still continues at the pool.
Code:
[Failure instance: Traceback (failure with no frames): : DNS lookup failed: address 'http' not found: [Errno -5] No address associated with hostname.
]
Unhandled error in Deferred:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 388, in errback
self._startRunCallbacks(fail)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 455, in _startRunCallbacks
self._runCallbacks()
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 542, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1076, in gotResult
_inlineCallbacks(r, g, deferred)
--- ---
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1020, in _inlineCallbacks
result = g.send(result)
File "/home/miner1/bitHopper_c00w_echiu64/work.py", line 66, in jsonrpc_lpcall
body.deliverBody(WorkProtocol(finish))
exceptions.AttributeError: 'NoneType' object has no attribute 'deliverBody'
]
Unhandled error in Deferred:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 388, in errback
self._startRunCallbacks(fail)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 455, in _startRunCallbacks
self._runCallbacks()
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 542, in _runCallbacks
current.result = callback(current.result, *args, **kw)
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1076, in gotResult
_inlineCallbacks(r, g, deferred)
--- ---
File "/usr/lib/python2.7/dist-packages/twisted/internet/defer.py", line 1020, in _inlineCallbacks
result = g.send(result)
File "/home/miner1/bitHopper_c00w_echiu64/work.py", line 66, in jsonrpc_lpcall
body.deliverBody(WorkProtocol(finish))
exceptions.AttributeError: 'NoneType' object has no attribute 'deliverBody'
I have btcmp.com working, but it's been flaky the last few days (the pool itself). If it stabilizes, I'll release my patch (I didn't push it to github yet).
FYI i've patched up AltSliceScheduler, should be stable and a little more aggressive in switching pools when threshold is met (rather than finishing it's slice). Also the slices are truly proportional now.
FYI i've patched up AltSliceScheduler, should be stable and a little more aggressive in switching pools when threshold is met (rather than finishing it's slice). Also the slices are truly proportional now.
Would like something between neutral blue and firenze, neutral blue a little too monochromatic for me. In anycase, not too fussed, except for the latest christmas tree changes, very startling...
Something ipad/iphone friendly would be my preference (not color wise, just in general)
Something ipad/iphone friendly would be my preference (not color wise, just in general)
one minor issue ED with your fork...
if you change the status of one of the miners with slices.. it just goes to back up until you change it back.
I was having issues with bloody again..and just decided to turn them off for a while.. well they had 300 of my slice shares.
the hopper decided to mine arsbitcoin for a good while, despite bitclockers had 6%.. if i disabled ars it just went to a different backup.. it was only when i reenabled bloody and let it finish did it reslice.
this makes it kinda hard to disable a bad server without having to actually restart.
if you change the status of one of the miners with slices.. it just goes to back up until you change it back.
I was having issues with bloody again..and just decided to turn them off for a while.. well they had 300 of my slice shares.
the hopper decided to mine arsbitcoin for a good while, despite bitclockers had 6%.. if i disabled ars it just went to a different backup.. it was only when i reenabled bloody and let it finish did it reslice.
this makes it kinda hard to disable a bad server without having to actually restart.
Thanks, didn't test that, will take a look today...
one minor issue ED with your fork...
if you change the status of one of the miners with slices.. it just goes to back up until you change it back.
I was having issues with bloody again..and just decided to turn them off for a while.. well they had 300 of my slice shares.
the hopper decided to mine arsbitcoin for a good while, despite bitclockers had 6%.. if i disabled ars it just went to a different backup.. it was only when i reenabled bloody and let it finish did it reslice.
this makes it kinda hard to disable a bad server without having to actually restart.
if you change the status of one of the miners with slices.. it just goes to back up until you change it back.
I was having issues with bloody again..and just decided to turn them off for a while.. well they had 300 of my slice shares.
the hopper decided to mine arsbitcoin for a good while, despite bitclockers had 6%.. if i disabled ars it just went to a different backup.. it was only when i reenabled bloody and let it finish did it reslice.
this makes it kinda hard to disable a bad server without having to actually restart.
Thanks, didn't test that, will take a look today...
Yo Ed, last time I will bother you but please tell me if this is the intended functionality of your altslice set to 1200 .
- It remains on pools until slice time runs out, no matter if a pool is >43.5% or in case of mine_slush >~11%, it will continue until timeslice is finish.
- If there is a new server with fresh block and that server have a timeslice assigned to it, it would jump to a timeslice on higher shares server ie. bitclockers were at 0% and timesliced at 600s whereas bloody is at 35% and timesliced at 600 aswell, now what happened it moved from btcpool24(finished timeslice there) and jumped to bloody and not bitclockers?
If this is the way it should work, Id like to understand this method better cause I cant for the life of me figure out how this could be more profitable than hop lowest share or dynamic penalty+hop lowest share.
Yes that's the intended behaviour. Try the latest pull, I (bone headedly) weighted based on most shares and not least shares, so that should fix your issue... stupid mistake! - It remains on pools until slice time runs out, no matter if a pool is >43.5% or in case of mine_slush >~11%, it will continue until timeslice is finish.
- If there is a new server with fresh block and that server have a timeslice assigned to it, it would jump to a timeslice on higher shares server ie. bitclockers were at 0% and timesliced at 600s whereas bloody is at 35% and timesliced at 600 aswell, now what happened it moved from btcpool24(finished timeslice there) and jumped to bloody and not bitclockers?
If this is the way it should work, Id like to understand this method better cause I cant for the life of me figure out how this could be more profitable than hop lowest share or dynamic penalty+hop lowest share.
SliceScheduler is c00w's implementation, I never pushed mine out. The latest one looks like it might be working now. I implemented AltSliceScheduler as a variant of flower's original work. Will do some patches later this week to make it a little more aggressive, for now it's a moderately simple weighted time slicer.
Personally, I'm using that for now. Not sure what slice size works best, I think 600-900 is ok. With the getwork store, I find that it reduces stales and doesn't matter much if you hop around pools. Doesn't seem to make bitHopper send more getworks, so on the surface seems harmless? Didn't pay attention too much. The drawback is maybe sending the clients too many LPs?
Personally, I'm using that for now. Not sure what slice size works best, I think 600-900 is ok. With the getwork store, I find that it reduces stales and doesn't matter much if you hop around pools. Doesn't seem to make bitHopper send more getworks, so on the surface seems harmless? Didn't pay attention too much. The drawback is maybe sending the clients too many LPs?
Ed, does your SliceScheduler option work? Or is it only AltSliceScheduler that works for now? If not which is best to use?
I'm currently using altslice at 900, does that sound about right?
I'm currently using altslice at 900, does that sound about right?
re: penalty option, this is where the dynamic penalty option of ryo worked so well.
Ha, I guess I don't trust anything I don't understand... I found for non-prop pools or delayed pools, dynamic penalty would push those quite low and I felt like I was mining unprofitable pools quite often. Oh well, in anycase, hopefully I'll have time to port it over, but not sure how well I can test it.
I think I'm secretly hoping Ryouiki or someone else will take the plunge, I just set the stage by extracting out most of the "scheduling" code
Ed, I see you defined mine_slush at 0.4*difficulty, is that correct afaik it should be something between 0.10 - 0.25 if I remember correctly.
I heard something like 15%? I think with the *4 factor (copied from the default scheduler), it ends up around 11%, since it's 1/4 of the default threshold of 0.435*difficulty.Will add in "penalty" option to user.cfg and then people can muck as they please...
Could be sheer luck? At 1 hour delay, wouldn't they have found a block by then (on average)? Almost like jumping in blind...??
Ryo has a simulation where time slicing pays off:
https://github.com/ryouiki/bitHopper/pull/3#issuecomment-1699605
Alas, that's the whole point of the scheduler class, to be able to add in as many as we like and to each their own!
With ryo's fork using dynamic penality, deepbit(backup) and btcguild(based on poolspeed it actually worked out positive jumping in even with the hour delayed stats). Im not going to discuss the efficiency level before someone spams btcg owner with this post. Lets just say its +EV so far.
Ryo has a simulation where time slicing pays off:
https://github.com/ryouiki/bitHopper/pull/3#issuecomment-1699605
Alas, that's the whole point of the scheduler class, to be able to add in as many as we like and to each their own!
is it really worth hopping btcguild? with the hour delay?.. how are you working out when to hop? are you just saying like 23% takes an hr and adjusting what you think the shares should be in reality bashed on their total mh?
With ryo's fork using dynamic penality, deepbit(backup) and btcguild(based on poolspeed it actually worked out positive jumping in even with the hour delayed stats). Im not going to discuss the efficiency level before someone spams btcg owner with this post. Lets just say its +EV so far.
Ugh, who likes the new christmas tree colour scheme?
Time to use some complimentary colour schemes:
http://www.colorschemer.com/online.html
http://kuler.adobe.com/
The graphs look better now though... not sure how useful they are...
Time to use some complimentary colour schemes:
http://www.colorschemer.com/online.html
http://kuler.adobe.com/
The graphs look better now though... not sure how useful they are...