However, it did not really fix the 6 seconds delay bug.
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 211. (Read 450523 times)
November 23, 2016, 08:10:06 AM
@coralreefer: I have created a pull request for what I think might be a good thing (renice the miner threads ... and only those ... to +7 in order to ensure system responsiveness). It does not slow down mining noticeably at all.
However, it did not really fix the 6 seconds delay bug.
However, it did not really fix the 6 seconds delay bug.
November 23, 2016, 07:23:55 AM
[quote author=coralreefer link=topic=1396233.msg16963757#msg16963757 date=1479899821Thanks for all the feedback EK. I just updated my git with a fix for what I believe was that submit memory leak I've been chasing for days. I also think this may address that 6 sec submit delay you observed earlier.
[/quote]
Not really ;-)
I suspect that the delay is due to the high CPU load slowing down the main client and its responsiveness. I'll try something.
And, with the latest GIT version, this artefact came up:
[/quote]
Not really ;-)
Code:
[13:22:45] CPU2: Submitting POW Solution (00000076E9FC4C13674D68E8...) [t:000000FFFFFFFFFFFFFFFFFF...]
[13:22:47] CPU0: 876.47 kEval/s
[13:22:47] CPU2: 890.56 kEval/s
[13:22:47] CPU1: 887.20 kEval/s
[13:22:51] CPU2: ***** POW Accepted! *****
[13:22:47] CPU0: 876.47 kEval/s
[13:22:47] CPU2: 890.56 kEval/s
[13:22:47] CPU1: 887.20 kEval/s
[13:22:51] CPU2: ***** POW Accepted! *****
I suspect that the delay is due to the high CPU load slowing down the main client and its responsiveness. I'll try something.
And, with the latest GIT version, this artefact came up:
Code:
[13:23:36] CPU0: Submitting POW Solution (0000007CF731DCB4EED0CF97...) [t:000000FFFFFFFFFFFFFFFFFF...]
[13:23:36] ERROR: Unknown request type
[13:23:36] ERROR: Unknown request type
[13:23:36] CPU0: ***** POW Accepted! *****
[13:23:40] CPU1: 796.49 kEval/s
[13:23:41] CPU2: 740.96 kEval/s
[13:23:41] CPU0: 757.11 kEval/s
[13:23:42] ERROR: Unknown request type
[13:23:36] ERROR: Unknown request type
[13:23:36] ERROR: Unknown request type
[13:23:36] CPU0: ***** POW Accepted! *****
[13:23:40] CPU1: 796.49 kEval/s
[13:23:41] CPU2: 740.96 kEval/s
[13:23:41] CPU0: 757.11 kEval/s
[13:23:42] ERROR: Unknown request type
November 23, 2016, 06:17:01 AM
Found the bug @coralreefer:
g_pow_target is not getting updated!
Example:
Target is:
g_pow_target is:
Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.
g_pow_target is not getting updated!
Example:
Target is:
Code:
e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229
g_pow_target is:
Code:
000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.
Code:
[11:22:43] CPU1: Submitting POW Solution (00000050469D1E28E55464C705DF2AECCDFA78570B79541EFE425E76342381A7) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:46] CPU1: 789.40 kEval/s
[11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:47] CPU0: 848.44 kEval/s
[11:22:48] CPU2: 846.27 kEval/s
[11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! *****
[11:22:46] CPU1: 789.40 kEval/s
[11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:47] CPU0: 848.44 kEval/s
[11:22:48] CPU2: 846.27 kEval/s
[11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! *****
Thanks for all the feedback EK. I just updated my git with a fix for what I believe was that submit memory leak I've been chasing for days. I also think this may address that 6 sec submit delay you observed earlier.
I'll take a look at why the pow target was not getting updated in the miner now.
November 23, 2016, 05:24:28 AM
Found the bug @coralreefer:
g_pow_target is not getting updated!
Example:
Target is:
g_pow_target is:
Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.
g_pow_target is not getting updated!
Example:
Target is:
Code:
e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229
g_pow_target is:
Code:
000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Any POWs submitted to jobs with a target other than 000000FF... are only "valid" accidently when their hash meets the lower target unintentionally.
Code:
[11:22:43] CPU1: Submitting POW Solution (00000050469D1E28E55464C705DF2AECCDFA78570B79541EFE425E76342381A7) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:46] CPU1: 789.40 kEval/s
[11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:47] CPU0: 848.44 kEval/s
[11:22:48] CPU2: 846.27 kEval/s
[11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! *****
[11:22:46] CPU1: 789.40 kEval/s
[11:22:46] CPU1: Submitting POW Solution (0000008EF17A408A1CD8F56462E153C7DD340BD81B3B50F26794E2AD263770F0) [t:000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF]
[11:22:47] CPU0: 848.44 kEval/s
[11:22:48] CPU2: 846.27 kEval/s
[11:22:48] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target e618618618618568b29adc5e3e91408900f505bbc7e03a18ce278a0229 for work_id = 17802030119850927464! *****
November 23, 2016, 05:06:45 AM
Coralreefer:
The bug is in the miner.
See this:
Target was:
The miner found these two solutions:
Comparison of the hashes to the target:
You see that the first one, 0x000000F16..., is certainly bigger than the target 0x000000CC... and so the error message is valid!
(Edit: I have created a pull request including the additional debug output)
The bug is in the miner.
See this:
Target was:
Code:
000000cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
The miner found these two solutions:
Code:
[11:03:30] CPU2: Submitting POW Solution (000000F16E65B6C934C0A240E0C6B15EA8B931AEC6F3C80EF3A489A68B54A2EF)
[11:03:31] CPU1: 815.32 kEval/s
[11:03:31] CPU1: Submitting POW Solution (0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA)
[11:03:33] CPU0: 828.84 kEval/s
[11:03:34] CPU0: ***** POW Accepted! *****
[11:03:34] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc for work_id = 17802030119850927464! *****
[11:03:31] CPU1: 815.32 kEval/s
[11:03:31] CPU1: Submitting POW Solution (0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA)
[11:03:33] CPU0: 828.84 kEval/s
[11:03:34] CPU0: ***** POW Accepted! *****
[11:03:34] CPU2: ***** POW Rejected: Proof of work is invalid: does not anylonger meet target cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc for work_id = 17802030119850927464! *****
Comparison of the hashes to the target:
Code:
000000cccccccccccccccccccccccccccccccccccccccccccccccccccccccccc
000000F16E65B6C934C0A240E0C6B15EA8B931AEC6F3C80EF3A489A68B54A2EF
0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA
000000F16E65B6C934C0A240E0C6B15EA8B931AEC6F3C80EF3A489A68B54A2EF
0000008EC171FDDE9FF4EF22A4995D620940D1D9BCE7F4EE584E6C99495861CA
You see that the first one, 0x000000F16..., is certainly bigger than the target 0x000000CC... and so the error message is valid!
(Edit: I have created a pull request including the additional debug output)
November 23, 2016, 03:53:10 AM
Also, @coralreefer:
I noticed the "does not meet hash anylonger" bug on one of two worker threads suddenly. A restart of xel_miner fixed that.
Checking if it's a bug in the retargeting method!
I noticed the "does not meet hash anylonger" bug on one of two worker threads suddenly. A restart of xel_miner fixed that.
Checking if it's a bug in the retargeting method!
November 23, 2016, 03:44:49 AM
Hi EK, I uploaded an updated miner to my git...I completely rewrote the i/o. Please let me know if this addresses the issue you observed earlier, and if so, I will finish cleaning up this approach.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
Hi, coral reefer! Runs stable for now :-) Woow, awesome work.
A little thing that I noticed, there is a strong delay before finding a solution and actually submitting it (in the example below around 6 seconds):
Maybe it's because the worker threads "max out" the machine. We could think about giving the IO thread a higher priority, as its mostly idle it should not hurt, but it should help to get the results to the server as quick as possible. However, in this case the worker threads might still "slow down the core client" if its running on the same machine.
Another idea, but not sure if too fancy or stupid at all: We could "nice" the worker threads during every IO operation maybe with an additional "grace period", to quickly get the solutions to the core-client and, from there, broadcast to the world.
Code:
[09:41:45] CPU2: Submitting POW Solution
[09:41:45] CPU1: Submitting POW Solution
[09:41:46] CPU1: 778.11 kEval/s
[09:41:46] CPU1: Submitting POW Solution
[09:41:47] CPU2: 792.52 kEval/s
[09:41:47] CPU0: 803.76 kEval/s
[09:41:49] CPU1: Submitting POW Solution
[09:41:51] CPU2: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
[09:41:45] CPU1: Submitting POW Solution
[09:41:46] CPU1: 778.11 kEval/s
[09:41:46] CPU1: Submitting POW Solution
[09:41:47] CPU2: 792.52 kEval/s
[09:41:47] CPU0: 803.76 kEval/s
[09:41:49] CPU1: Submitting POW Solution
[09:41:51] CPU2: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
[09:41:51] CPU1: ***** POW Accepted! *****
November 23, 2016, 01:22:56 AM
now we have three projects focusing on decentralized computing: Elastic, Golem, Iex
XEL might be the first open market soon, and personally i estimate market cap should be around 25 million compared to golem and iex.
they are all legit, with somewhat pros and cons. but i believe Elastic is much more ready than those two. and the approach of XEL is more cryptographic than P2P.
So XEL may more catering to blockchain savvy.
I doubted this project at very first phase, but now i am a firm believer.
we have to be optimistic! look at those stupid big for nothing scammy projects in top20.
XEL is 20 times better than those sh*ts. lol
XEL might be the first open market soon, and personally i estimate market cap should be around 25 million compared to golem and iex.
they are all legit, with somewhat pros and cons. but i believe Elastic is much more ready than those two. and the approach of XEL is more cryptographic than P2P.
So XEL may more catering to blockchain savvy.
I doubted this project at very first phase, but now i am a firm believer.
we have to be optimistic! look at those stupid big for nothing scammy projects in top20.
XEL is 20 times better than those sh*ts. lol
November 22, 2016, 10:13:02 PM
Hi EK, I uploaded an updated miner to my git...I completely rewrote the i/o. Please let me know if this addresses the issue you observed earlier, and if so, I will finish cleaning up this approach.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
Edit: I think I spotted one more issue with the submit array. I'll try to fix that issue tomorrow.
November 22, 2016, 01:27:52 PM
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild".
For serious testing, please wait for 0.7.1.
just want update my public node to latest git but compile.sh and run.sh is missing intentionally ?For serious testing, please wait for 0.7.1.
regards
You'll need to use the build instructions at the following link:
http://elastic-project.com/installing_and_running_elastic
November 22, 2016, 01:14:59 PM
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild".
For serious testing, please wait for 0.7.1.
just want update my public node to latest git but compile.sh and run.sh is missing intentionally ?For serious testing, please wait for 0.7.1.
regards
November 22, 2016, 12:42:59 PM
Not so sure if the "retargeting" thing works correct. I am seeing far less than the wanted 10 PoW per block:
Do you think this may simply be due to the work already being at the minimum difficulty?
November 22, 2016, 12:11:27 PM
Not so sure if the "retargeting" thing works correct. I am seeing far less than the wanted 10 PoW per block:
November 22, 2016, 10:59:45 AM
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
3. It is hard to say, but right now there are just two options when a duplicate transaction may occur for the POW: a) it is really a duplicate and b) we have reached 20 in this block. Since duplicate POW submissions are nearly impossible if not handcrafted by a script kiddie (look how huge the search space of the deterministic input ints is), I think it is safe to assume that any duplicate message for the POW submission means that the 20 limit kicked in.
1.) 2.) I will try to reproduce them now
4.) Also taking a look on that, maybe 4 eyes see more than 2
November 22, 2016, 10:53:52 AM
One more thing, I still can't enter any jobs with crypto functions via the UI, (i.e. if I include "sha256 3 80;" in the job I get a "syntax error")
I think they have to be upper case
November 22, 2016, 10:24:46 AM
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
One more thing, I still can't enter any jobs with crypto functions via the UI, (i.e. if I include "sha256 3 80;" in the job I get a "syntax error")
November 22, 2016, 10:13:05 AM
EK, here are a couple of observations.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
1) The miner has a rare memory leak somewhere that causes the work_id submitted to the server to get corrupted. It's hard to reproduce and I thought I fixed this already, but I'll keep looking into it. But if you see "invalid work_id" errors, just ignore that for now as I'll get it fixed.
2) Things run great for a while, then I'll get several:
***** POW Rejected: Proof of work is invalid: does not anylonger meet target ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff for work_id = 2449324862526339719! *****
messages in a row. It does seem to occur after the miner switches to the second job, but not consistently.
3) Can you confirm which message indicates that there are no more POW for this block. Is it the uppercase "Duplicate" or the lower case "duplicate"?
4) One thing I'm just starting to look at is whether or not the values in the work response message are correct, or if there is some sort of lag. For example, it seems like I'll get 3 accepted POWs for a specific job, but when I look at the next work response message for that job, it may say Accepted POW = 1. I haven't spent much time on this yet so this may not be an issue, but just wanted to give you a heads up.
November 22, 2016, 08:57:50 AM
Inofficial testnet started using the 0.7.0 version, and the public nodes were updated. May be buggy, but we need to test out some things "in the wild".
For serious testing, please wait for 0.7.1.
For serious testing, please wait for 0.7.1.
November 22, 2016, 08:57:03 AM
Hi EK,
So far longpolling is working great and the interactions between the miner & server are greatly improved. I'll play around with it more later today and let you know if I encounter any issues.
So far longpolling is working great and the interactions between the miner & server are greatly improved. I'll play around with it more later today and let you know if I encounter any issues.
November 22, 2016, 08:22:52 AM
For testing, use
to redeem >300,000.00 XEL, signing can be done here: https://ordinarydude.github.io/offline-bitcoin-signer/
Code:
* 1AktLQnreNm585z1r1QbAjgrrJCuYuXtZm - L1SmPPpHtqR8na6ZvCC2Yu59fEQuavTkU72fQNte6bP4PYrKfYwX
to redeem >300,000.00 XEL, signing can be done here: https://ordinarydude.github.io/offline-bitcoin-signer/
Jump to: