Topic: bitHopper: Python Pool Hopper Proxy - page 31. (Read 355678 times)

Its right about 50% of the time. And people are working to try and increase that.

This LP "who solved the block" procedure exploits an assumption, that a pool that finds a block will be sending notifications to miners earlier than other pools. This may not always be correct.

One has to understand these delays and what long polling is.

When a pool's bitcoin detects a new block (whether they found it themselves or found out about it over the p2p network), the the job of sending notifications goes to pushpool. Pushpool looks at all the open RPC connections that have long polling enabled, and pushes out a notification of the new block to the miners. Long polling keeps a connection open between the miner and the pool, so the miners get a quicker notification of the new block than if they were to just request new work every 15 seconds or so. This reduces obsolete share submissions ("stale" shares), improving pool efficiency.

Pushpool can't instantaneously notify everyone however, due to network bandwidth. Essentially, it goes through a list of all open connections and sends each the LP push consecutively. Small pools can send all their miners the notification quickly, but depending on the pool implementation and the number of open connections, this can take more than five seconds on busy pools. If you are on the start of the list, you get notification fast; at the end of the list, it can take longer. This means that the pool delay can be random per miner, much more significantly than packet transit times. Profiling your pool connection time may give different results from others, and may give different results even if you restart bithopper on a different day and make new RPC connections to the pool.

Great! This feature adds X seconds to the LP receive time of the specified pool for figuring out who solved it. That means if you analyze the console log, and find one pool that is consistently faster in sending you it's LP block announce than others (especially if a pool responds to you before the one that actually found the block - causing the proxy to designate the wrong pool), then you can 'equalize' the time LPs are received by adding a delay to 'too fast' pools.

Block 140749 found by pool.bitp.it:

[19:28:09] received lp from: bitp
[19:28:09] New Block: 5ea4b4d35340f0a60c238a721e3b0bd72453873fe6a7cec6000005f700
000000
[19:28:09] Block Owner bitp
[19:28:09] LP Call pool.bitp.it:8334/longpoll
[19:28:10] received lp from: mmf
[19:28:10] LP Call mining.mainframe.nl:8343/LP
[19:28:10] received lp from: deepbit
[19:28:10] LP Call pit.deepbit.net:8332/listenChannel
[19:28:10] received lp from: mineco
[19:28:10] LP Call mineco.in:3000/LP
[19:28:10] RPC request [getwork] submitted to polmine
[19:28:11] received lp from: bclc
[19:28:11] LP Call bitcoins.lc:8080/LP
[19:28:12] received lp from: eclipsemc
[19:28:12] LP Call pacrim.eclipsemc.com:8337/LP
[19:28:12] received lp from: arsbitcoin
[19:28:12] LP Call arsbitcoin.com:8344/LP
[19:28:14] received lp from: eligius
[19:28:14] LP Call su.mining.eligius.st:8337/LP

Although this is not the best example (I actually had one block scroll by where mineco was the first to announce the block, beating the actual finding pool), we can see that pools take different amounts of time to respond. Bitp.it was almost beat in announcing their own block by mainframe. I can improve the results by tweaking like this (if I was only looking at the above results and not evaluating pool delays over many blocks):

[mmf]
lp_penalty: 4

[deepbit]
lp_penalty: 4

[mineco]
lp_penalty: 4

[bclc]
lp_penalty: 3

[eclipsemc]
lp_penalty: 2

[arsbitcoin]
lp_penalty: 2

[eligius]
lp_penalty: 0

[bitp]
lp_penalty: 3? (would need to evaluate blocks they didn't solve)

I will test this out and see if it can completely fix false pool block designation. Of course what would be wishful thinking would be if bithopper could learn for itself the average delays it sees from each pool.

You can put a penalty on deepbit if you've done the analysis for your location and determined it is getting too many blocks. Or any other site. Especially if there LP is super slow or delayed.

^ you´re quick man!! hehe..

what is the beneffit of that, or what value do you recommend?

@whoever wanted an lp_penalty option:
I added it. It is lp_penalty : seconds.

Need an update anyway..

[bmunion]
name: BitMinersUnion.org
mine_address: pool.bitminersunion.org:8341
api_address: http://64.244.102.89/stats.php
api_method: re
api_key: Shares this round:([ 0-9]+)

api_strip: ' '
url: http://www.bitminersunion.org/

move bitminers union to the unhoppable part of your lists

@c00w: I don´t know if this is what you´re asking, but i think no, deepbit is in yellow and the share count of the round count normal, but my miner (GUIMiner x3vgas), just stop.

I´ll try to run BH with --debug so i can give you more details! (if it worth it, you tell me)

@r2edu
Are you seeing any errors on the front end?

Lp Penalty?
Sure.

Oh and there already is a mine_nmc...

Yea, I could do that.  I think an easier way would just be a timer though.  Deepbit is almost always 26-27 minutes per block average.  So just hop after 26.5*.43 minutes = 11.395 or say 11.5 minutes.

Damnit, bithopper missed out on a fast round on bitcoinpool because it was too busy mining at deepbit for hours on end.  Back to cherrypicker.

I like aiming for 25% on db, but sometimes it skips over it and I'm there a little bit longer, but it's not exactly killing efficiency. I suggest fiddling with the penalties till you get what you're looking for.

@deepceleron: I don´t understand your final request.. (i´am from Arg. so my english is not that good), if you can explain me better i can help, i got a btcmine account

---

I´m with latest version 0.1.6.2-1, and deepbit doesn´t work.. when start a round my miner just die. I wait for about 2-5 min. and nothing, so i disable it and hop to another pool, then the share count of db never stops...

As i said, Polmine is working really good, and BCLC founds blocks that doesn´t belong to it (i mean in BH, resets to 0 but the stats in its web keeps counting for hours), so i´am mining it "the old way"

Maybe the problem is my location, Argentina?

I have it at the default of 43%.  If I do that then won't I leave sooner on the short round and kill my efficiency even more?  What I am saying is that something isn't right.

so why not just raise db's penalty so you leave sooner?

Random question here, if an LP new block comes in from a pool, should that not override anything the API is telling the scheduler?

Update:
I may have answered it myself after digging through lp.yc,  if the pool is set to mine_deepbit' and LP is going, ,it'll reset the shares count.

Its almost as if I am just mining exclusively on deepbit now.  I almost never leave.  I think instead of trying to estimate shares through the hashrate it would be better to just leave after 10-12 minutes after a round start.  I find on the longer rounds.  I SHOULD be submitting no more than 100ish shares per round as that is about the time that deepbit passes the 43% threshold.  I am submitting 2-500 shares on the longer rounds and its obliterating my efficiency.  I am at 115% efficiency with deepbit overall.



A round with 6 million shares should have no more shares submitted by me than a round with 1 million shares, but they have 2-4x as many.  Something is either causing bithopper to miscalculate the 43% threshold or allowing me to mine right through it.

I'm trying the pool block detection features in this software. The LP detection algorithm needs the ability to fine-tune timing. Some pools announce blocks by LPs faster than others; the problem manifests that a fast/close pool can get LP push to the miner before the pool that actually solved the block. A block-finding pool can be slower than others from the pool's infrastructure, number of pool miners in that pool needing the LP push, and geographic location (and perhaps even by pool ops messing with LP timing themselves).

The correction factor could be a pool.cfg option to 'slow down' fast-announcing pools that cause false positives, a user.cfg option like "Delay_LP: 2" seconds if block-finding pools are consistently being beaten in LP push speed by this fast/small pool by a second.

Also, if anyone with a btcmine account would be willing to add worker for me to get info with and PM me, it would be appreciated!

I'll see what I can do. NMCWatch looks quite promising and I thank you in advance for the regex Sukrim. c00w, I'd completely forgotten we already have NMC difficulty as well as bitparking, so I'd just need to do the math and override the percentages where necessary... And perhaps add a new role, similar to what you did with mine_slush (mine_nmc perhaps?).

Could also let someone else do the math for us and just compare the USD figures from http://tvori.info/bitcoin/charts/ - easy regex too, from the look of it.