dga
|
|
June 10, 2014, 04:49:34 PM |
|
I am testing to see if this resolves the error.
If you have an easy way to reproduce it, I can test too. I don't have my own pool set up, so I was just testing on extremehash. I didn't see the bug before or after the fix, but...
|
|
|
|
cubydu
|
|
June 10, 2014, 04:55:40 PM |
|
I am testing to see if this resolves the error.
If you have an easy way to reproduce it, I can test too. I don't have my own pool set up, so I was just testing on extremehash. I didn't see the bug before or after the fix, but... You can test with my pool http://79.135.200.108/ . I got errors with this pool. And I can give you shell access to pool if you need.
|
|
|
|
btc-mike
|
|
June 10, 2014, 05:24:29 PM |
|
After about 45 minutes, I get continuous authentication errors and low-diff errors. But the jobs are still coming. Restart simpleminer resolves.
|
|
|
|
cubydu
|
|
June 10, 2014, 05:33:40 PM |
|
After about 45 minutes, I get continuous authentication errors and low-diff errors. But the jobs are still coming. Restart simpleminer resolves.
these are old errors
|
|
|
|
btc-mike
|
|
June 10, 2014, 05:36:31 PM |
|
After about 45 minutes, I get continuous authentication errors and low-diff errors. But the jobs are still coming. Restart simpleminer resolves.
these are old errors Were these already resolved? How to fix?
|
|
|
|
cubydu
|
|
June 10, 2014, 05:41:15 PM |
|
After about 45 minutes, I get continuous authentication errors and low-diff errors. But the jobs are still coming. Restart simpleminer resolves.
these are old errors Were these already resolved? How to fix? I wrote dga only about a time to get new job. And open ticket about low-diff https://github.com/LucasJones/node-boolberry-pool/issues/1
|
|
|
|
cubydu
|
|
June 10, 2014, 05:47:52 PM |
|
I am testing to see if this resolves the error.
If you have an easy way to reproduce it, I can test too. I don't have my own pool set up, so I was just testing on extremehash. I didn't see the bug before or after the fix, but... I changed some parameters in config. Maybe it matters for errors . "varDiff": { "minDiff": 50000, "maxDiff": 10000000, "targetTime": 50, # from 100 "retargetTime": 30, "variancePercent": 30, "maxJump": 150000 },
|
|
|
|
tc61
|
|
June 10, 2014, 06:45:12 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
|
|
|
|
c18machine
Newbie
Offline
Activity: 59
Merit: 0
|
|
June 10, 2014, 06:47:34 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
dont pool mine for now.
|
|
|
|
cubydu
|
|
June 10, 2014, 06:48:51 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
dont pool mine for now. Why ?
|
|
|
|
cubydu
|
|
June 10, 2014, 06:50:54 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
(Pool hash rate * 86400) / current diff = blocks per day
|
|
|
|
tc61
|
|
June 10, 2014, 06:51:05 PM |
|
Any newb tutorial on how to solo mine
|
|
|
|
pt7
Member
Offline
Activity: 98
Merit: 10
|
|
June 10, 2014, 06:52:02 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
dont pool mine for now. Why ? Pools are not yet ready for prime time. Unfortunately they are bodly listed at the top of the OP page. I think they should be be moved to near the bottom, and with a disclaimer.
|
|
|
|
cubydu
|
|
June 10, 2014, 06:55:52 PM |
|
hi all, newb to berry, mining on a pool. how long does it take to find a block, been on a while blocks found never..am I doing something wrong?
dont pool mine for now. Why ? Pools are not yet ready for prime time. Unfortunately they are bodly listed at the top of the OP page. I think they should be be moved to near the bottom, and with a disclaimer. http://bbr.extremepool.org/ found 8 blocks http://79.135.200.108/ found 4 blocks (1 I deleted) Solo mining profitable only if you have cpu farm.
|
|
|
|
crypto_zoidberg (OP)
|
|
June 10, 2014, 07:22:28 PM |
|
Please all pool owners and solo miners, check your daemon logs now, we stuck again. It seems that some bug in miner.
|
|
|
|
dga
|
|
June 10, 2014, 07:46:33 PM |
|
Please all pool owners and solo miners, check your daemon logs now, we stuck again. It seems that some bug in miner.
Might be coincidence - I restarted my mining daemon to be able to print_block and see what was going on, and found the next block very shortly thereafter. I'm *sure* that the latter part was luck - it's a very fast machine but not *that* fast - but I wonder if there was something about the restart that triggered some updates. The only things I notice about the blocks: The "extra" field in 16755 is larger than any of the previous several blocks; 16756 included two tx hashes, which none of the previous blocks did. 16756 "timestamp": 1402428976, 16755 "timestamp": 1402425579, <- last block found before the gap 16754 "timestamp": 1402425570, ...
And extra fields: 16756 "timestamp": 1402428976,
"tx_hashes": [ "9d0367bd319b128856c4b5c0039d81d77da14594753f849a4b2cff25642e43b2", "5f52cc1f3922edaaccac6a226b0c1db4981952c2ead97550c80ba27d8a4bf031"
"extra": [ 1, 12, 170, 236, 106, 246, 128, 1, 64, 237, 160, 188, 139, 26, 60, 183, 2, 138, 33, 11, 78, 91, 223, 3, 160, 14, 147, 223, 31, 190, 15, 162, 14, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
16755 "timestamp": 1402425579, "extra": [ 1, 254, 90, 32, 214, 169, 66, 142, 107, 82, 112, 69, 141, 195, 9, 6, 153, 36, 236, 134, 174, 29, 214, 163, 233, 119, 179, 189, 81, 22, 225, 246, 0, 2, 32, 48, 46, 49, 46, 49, 46, 49, 49, 40, 51, 48, 49, 55, 52, 102, 50, 45, 100, 105, 114, 116, 121, 41, 0, 0, 0, 0, 7, 89, 162, 98, 0
16754 "timestamp": 1402425570, "extra": [ 1, 28, 48, 231, 241, 73, 242, 252, 185, 15, 227, 86, 12, 140, 79, 7, 171, 166, 109, 180, 100, 186, 97, 81, 74, 6, 20, 191, 82, 131, 53, 136, 111, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
The second of those two tx hashes was a pretty large transaction.
|
|
|
|
crypto_zoidberg (OP)
|
|
June 10, 2014, 08:19:31 PM |
|
Please all pool owners and solo miners, check your daemon logs now, we stuck again. It seems that some bug in miner.
Might be coincidence - I restarted my mining daemon to be able to print_block and see what was going on, and found the next block very shortly thereafter. I'm *sure* that the latter part was luck - it's a very fast machine but not *that* fast - but I wonder if there was something about the restart that triggered some updates. I agree with you. I guess in some situations on_block_chain_update() is not called for miner and scratchpad becomes invalid, that's why we have seen wrong PoW hashes. It's just guess, it's hard to reproduce it. I've pushed hotfix with regular scratchpad update, once 30 sec, for first time it's ok, but it will become expensive when scratchpad will be more than 10-20 MB, hope we gonna find bug by then. The only things I notice about the blocks: The "extra" field in 16755 is larger than any of the previous several blocks; 16756 included two tx hashes, which none of the previous blocks did. 16756 "timestamp": 1402428976, 16755 "timestamp": 1402425579, <- last block found before the gap 16754 "timestamp": 1402425570, ...
And extra fields: 16756 "timestamp": 1402428976,
"tx_hashes": [ "9d0367bd319b128856c4b5c0039d81d77da14594753f849a4b2cff25642e43b2", "5f52cc1f3922edaaccac6a226b0c1db4981952c2ead97550c80ba27d8a4bf031"
"extra": [ 1, 12, 170, 236, 106, 246, 128, 1, 64, 237, 160, 188, 139, 26, 60, 183, 2, 138, 33, 11, 78, 91, 223, 3, 160, 14, 147, 223, 31, 190, 15, 162, 14, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
16755 "timestamp": 1402425579, "extra": [ 1, 254, 90, 32, 214, 169, 66, 142, 107, 82, 112, 69, 141, 195, 9, 6, 153, 36, 236, 134, 174, 29, 214, 163, 233, 119, 179, 189, 81, 22, 225, 246, 0, 2, 32, 48, 46, 49, 46, 49, 46, 49, 49, 40, 51, 48, 49, 55, 52, 102, 50, 45, 100, 105, 114, 116, 121, 41, 0, 0, 0, 0, 7, 89, 162, 98, 0
16754 "timestamp": 1402425570, "extra": [ 1, 28, 48, 231, 241, 73, 242, 252, 185, 15, 227, 86, 12, 140, 79, 7, 171, 166, 109, 180, 100, 186, 97, 81, 74, 6, 20, 191, 82, 131, 53, 136, 111, 2, 22, 48, 46, 49, 46, 49, 46, 57, 40, 48, 46, 49, 45, 103, 101, 54, 50, 50, 99, 97, 48, 41, 124
The second of those two tx hashes was a pretty large transaction. I thought about some combinations of transaction that broke create_block_template(), but since there are no errors in log about this i guess transactions is not related. Not sure about this.
|
|
|
|
cubydu
|
|
June 10, 2014, 08:35:15 PM |
|
|
|
|
|
surfer43
Sr. Member
Offline
Activity: 560
Merit: 250
"Trading Platform of The Future!"
|
|
June 10, 2014, 08:43:37 PM |
|
PoolBerry.org updated.
|
|
|
|
cubydu
|
|
June 10, 2014, 08:44:28 PM |
|
Please update daemon to version v0.1.1.12(90ec703) (miner hot fix)!!! Is this update only for pool/solo daemons ?
|
|
|
|
|