|
As far I understand the code switch for each node is when share chain for last 24hrs is 95% on v9, so it should be in matter of seconds in all nodes to switch- we all have same share chain.
High pool DOA and stales are because "old" (under v9) nodes are trying to connect and put own shares into our chain. Ofc they all become stale/doa instantly because they not fit our share chain.
When forrestv will apply patch that disallow to connect <v9 nodes totally it will stabilize stale/doa to real value.
|
|
|
|
now we just have to get rid of v5 and v7 ppl  It looks like the LTC network switched over about 20min ago... showing no v8 and below in the desired version graph now. (not counting the mean indicators) -- Smoov Yep, only pure red-ish v9 on LTC side  |
|
|
|
|
- Run cmd
- navigate to cgminer directory
- run "cgminer.exe -n"
It shows you opencl devices it see.
- backup/delete cgminer.conf
- run "cgminer.exe"
- input pool address/user/pass
- after it start working press keys: S W <enter> to save config
If it crash somewhere at this point copy output form cmd window and post it.
|
|
|
|
I guess the reason for all those 0 - 1 second intervals between longpolls are somehow due to p2pool popularity increase / many people giving it a try, let's hope it will stabilize somehow, so web have at least a few seconds between longpolls Nope. This is only function of share diff, pool rate and luck - more share diff shares posted in row to chain. Maybe you see moment when some 10GH or more user join and put few shares on lower diff b4 pool catch this and increase share diff to keep avg 10s longpool Scan time 60 is good enough, I never see longer longpool interval. |
|
|
|
Longpool in p2pool is every 10 seconds (average). I`m mining at avg 150MH/s and there are times that I not get any share over 24hrs and sometimes I get 5 of them. This is only luck Your miner settings are ok, higher queue leads to more DOAs and more threads in that MH/s power is just useless. Sometimes longpools can hit every second or so, but it is 30s sometimes too. Avg form last few is always 10s - this way p2pool share chain is regulated (shares are too frequent -> share diff goin up). |
|
|
|
It is a good thing rav3n_pl isn't prone to gloating...
-- Smoov
Cmon Smoov, I`m just happy that math just proven my good thoughts about p2pool |
|
|
|
*blushing* (...) *reading* (...) "There is no correlation between pool luck and pool hashrate, or orphaned block production and pool hashrate"Eat this, infidels!  In some way I see pattern in "Shares per round / D as function of p2pool hashrate" graph, it looks like this:  ;] |
|
|
|
Update progress: v9: 81% v8: 12% v5: 6% Rest is under 1% I`ts final git pull time! Latest binary 9.0-6-gf18f763 for win32 and win64 on my skydrive if any1 interested |
|
|
|
Updated to v9. It seems I'm always one of the last ones to move over (because I'm not as active on these forums anymore). Could I possibly get someone to shoot me an email when a new binary is released? That way I don't get left behind, and we can move the transition to the next version along? Why not add a notify on this thread, otherwise if your not willing to update yourself, then why should anyone make that effort for you. If you want to benefit, then take a proactive approach and stop waiting for someone to spoon feed you. Grow up, we are not your mom and dad. One of ways to keep node automagically updated: https://bitcointalk.org/index.php?topic=18313.msg836949#msg836949Edit to your config, put it to cron weekly and forget. |
|
|
|
for you guys running the latest git versions of bitcoind, are you building these locally or is there someone trustworthy doing nightly builds?
Once you make compiling machine up and running it is not a problem to compile new git yourself even everyday cd bitcoin
git pull
cd src
make -f makefile.unix bitcoind
strip bitcoind
|
|
|
|
You're right "--fix-protocol" fixes cgminer too.  Funny thing, cause 2.9.3 was working fine the last 3 days. I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used. Posted a backtrace to #cgminer, hopefully it will help debug the problem. If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone. |
|
|
|
Remember to |
|
|
|
|
Memory usage on my 3GB VM:
bitcoind 6,4%
p2pool btc 10,5%
litecoind 4,0%
p2pool ltc 10,5%
namecoind 3,2%
ixcoind 4,0%
i0coind 40,3% O_O
I0C eating more than rest of stuff...
|
|
|
|
|
Stale/doa shares depends on miner config and p2pool server load.
Orphan shares are just luck.
Shares are ONLY to calculate payout.
All shares are tested for possible block found.
Share diff is scaled to pool ratio/share about every 10s.
So stale and orphan ratio are NOT responsible for pool luck/block finding ratio.
|
|
|
|
In mean time V9 is passing 40% of pool.
Trouble is, that V5+V7 is about 10%, so if those ppl will not switch to v9 95% hardfork will not happen soon...
Upgrade mates! Upgrade!
v8 update rush has worked after some time, then no fork. ppl disappointed -> longer time to do it now. v7 was fork update, v8 - anti-v7-fork ;] Now finally v9 I just hope that tx sending will be rolling again. Maybe do it in this way: - preload: get all current txns form bitcoind - found new txn in bitciond -> ask connected peers about that txn - send full tx data to peer that want it - got ask from peer -> check that you have it and ask for data if not - all txns that are not in block need to be cashed to prevent asking/sending same txes over and over - node forget txes that are put in block 2 blocks back - to prevent asking txes from nodes that are 1 block behind network when new block is propagated - purge tx cache data from txes that are not in block every few blocks/refresh from bitcoind |
|
|
|
|
In mean time V9 is passing 40% of pool.
Trouble is, that V5+V7 is about 10%, so if those ppl will not switch to v9 95% hardfork will not happen soon...
Upgrade mates! Upgrade!
|
|
|
|
(...)
Got Yasm copied in and finally configure line didn't error.
Windows build.txt is missing this step entirely.
Did the Libcurl actually change between 2.7.5 and 2.9.3?
I only ask because it looks the same as the older windows build instructions but it is erroring on a line with curl listed.
I am more interested in how to fix it then why it happened though.
Actually yasm is a red herring. It does nothing on windows builds since it is only for 64 bit linux cpu mining support. The libcurl requirement DID change at around 2.8, due to new requirements for stratum support, but they're not the problem you're running in to. The real issue is that support for compilation on *BSD was added recently to cgminer, and unfortunately that broke compilation directly on windows mingw32 compilation. I didn't notice because I now compile the mingw binary via a cross-compiler on linux. So it's not a problem at your end. When I can get back to code soon I will try and address this issue... but then there are other problems with cgminer on windows in 2.9.x, to which I do NOT have a good explanation for yet... God I hate windows. There is cure for windows: https://bitcointalk.org/index.php?topic=118288.msg1329247#msg1329247 |
|
|
|
|
Show Posts
