Public nodes updated to 0.7.1
Powerful EK, Pandora's Box is about to open, EK will be in the history of the block chain to leave a brilliant footprint
Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 210. (Read 450523 times)
November 24, 2016, 08:36:37 AM
Powerful EK, Pandora's Box is about to open, EK will be in the history of the block chain to leave a brilliant footprint
November 24, 2016, 05:30:50 AM
Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.
i'm running wallet 0.7.0, it is downloading blockchain (60 blocks left)
is that fine?
November 24, 2016, 04:21:05 AM
Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.
No (testing with 0.7.1).
Code:
No peers found.
Ps:
And it's confusing to do "java -jar target/elastic-core-0.6.0.jar" for launch 0.7.1
November 24, 2016, 03:31:22 AM
Does anyone else except @EK was successful in launching 0.7.0 node? (compiling from source, not docker image). By successful I mean that after start there are preserved connections to other nodes.
November 24, 2016, 03:28:32 AM
MiningSev: I think a GPU miner is trivial, at least for the current version of the ElasticPL language and if we (for now) leave out the special crypto functions. Maybe, if I find some time, I can create a variant of coralreefers xel_miner which compiles "OpenCL" code and executes it inside its "execute_vm" function instead of running the compiled program on the CPU.
November 24, 2016, 03:22:15 AM
Ok, stupid question:
If there are methods to effectively monitor power usage, wouldn't miners use them already? I mean, it's in their best interest to monitor this anyway, no matter what they mine.
If there are methods to effectively monitor power usage, wouldn't miners use them already? I mean, it's in their best interest to monitor this anyway, no matter what they mine.
November 24, 2016, 12:35:55 AM
Obviously it's limited to Intel's CPUs only, so graphic cards, and other mining equipment won't b possible.
Additionaly CPU is rather bad idea for mining, however, it would be something ... for the start
Additionaly CPU is rather bad idea for mining, however, it would be something ... for the start
For the long run - I'm not a coder - but a medical-engenieer (and so an electronics-guy) and as far i know the CPU is the only Processing-Unit which is able to run all processes - slower than other propietary devices but most flexible.
You can't know before the Mainnet lauch what our main-usecase would be ("cusomers decide") - so we aren't able to know if a gpu miner for these funcions would be possible.
Correct me if i'm wrong.
November 23, 2016, 11:12:42 AM
I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.
Thank you.
Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.
I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.
I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.
I really appreciate your time and effort spent trying to find a solution into this matter. I think it could give a very tangible feature for the users to enable them to have real life / realtime information regarding profitability of using a product like elastic. At the end of the day people are gonna be selling their computational power to generate profit and the easier it is to know where is your cut off point for profit the better.
I tried to find a reliable method for this measurement in the past but didnt find something convincing...
If anyone has any idea about it, it could be highly useful to add to the elastic client.
Not sure if it wil be of any use for you, but Intel has something like this
https://software.intel.com/en-us/articles/intel-power-gadget-20
which is able to log CPU power to an external file.
Obviously it's limited to Intel's CPUs only, so graphic cards, and other mining equipment won't b possible.
Additionaly CPU is rather bad idea for mining, however, it would be something ... for the start
On the other hand, I think it's pure waste of time at this stage.
The current development should be focused on launching the mainnet + initial distribution.
Once the mainnet is live with no major issues, we can start thinking on additional features.
November 23, 2016, 10:43:55 AM
I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.
Thank you.
Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.
I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.
I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.
I really appreciate your time and effort spent trying to find a solution into this matter. I think it could give a very tangible feature for the users to enable them to have real life / realtime information regarding profitability of using a product like elastic. At the end of the day people are gonna be selling their computational power to generate profit and the easier it is to know where is your cut off point for profit the better.
I tried to find a reliable method for this measurement in the past but didnt find something convincing...
If anyone has any idea about it, it could be highly useful to add to the elastic client.
November 23, 2016, 10:27:48 AM
EK, I've moved longpoll back to it's own thread. Please let me know if you find any other issues.
Edit: I still have to add some additional error handling as well as some general cleanup, so feel free to offer suggestions if you see a way to improve something. It's still very much a work in progress.
Edit: I still have to add some additional error handling as well as some general cleanup, so feel free to offer suggestions if you see a way to improve something. It's still very much a work in progress.
November 23, 2016, 09:48:22 AM
I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.
Thank you.
Sorry for the late response, I am truly sorry for not coming back to you earlier. However, I have spent the day before yesterday to research on several methods related to your suggestion.
Your suggestion was to include some sort of "measurement" of the actual power usage of the miner so that people can quickly assess the "ROI" which results directly from the mining income and the power usage of their mining rigs.
I have tried different ways to measure the "power usage" programmatically. While it is easy to do if the computer is on battery power (this only requires pulling the battery statistics repeatedly) it becomes almost impossible to achieve on a computer on AC.
I have even tried to implement a PoC measurement tool that would read the CPU type, get its "TDP Power" in watts and estimate the real usage by observing the CPU usage, so on "100%" CPU usage one could assume that the entire TDP power is used.
I have compared the results to what I see when I measure the actual power usage with a power meter plugged into the wall (i had purchased one only for this experiment) - but the results were bad! Sometimes overestimated, often underestimated.
I have no real idea here and I keep thinking about it for days now! That's why I did not yet come back, but you are right ;-) Maybe I should be open about my thoughts (see above) and probably someone comes up with something more reliable.
November 23, 2016, 09:47:48 AM
@coralreefer:
Found a serious bug in the miner
Take a look at that
I think that this check throws away a great deal of valid solutions into the trash can.
What if the target is:
And our solution has the perfectly right hash:
It won't make it through the check, will it?
Found a serious bug in the miner
Take a look at that
Code:
// POW Solution Found
if ((swap32(hash32[0]) <= g_pow_target[0]) && swap32(hash32[1]) <= g_pow_target[1])
rc = 2;
else
rc = 0;
I think that this check throws away a great deal of valid solutions into the trash can.
What if the target is:
Code:
000000cc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
And our solution has the perfectly right hash:
Code:
000000aa ffcccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
It won't make it through the check, will it?
Good catch, I'll fix this and throw longpoll back into it's own thread. I originally consolidated it as I thought it was causing an issue, but i've since found the root cause of that issue and is fixed in the latest on github.
November 23, 2016, 09:39:22 AM
I will appreciate it if you honor me with a proper response Evil knievel (that would be a minimal courtesy from your end).
Thank you.
Thank you.
November 23, 2016, 09:24:41 AM
@coralreefer:
Found a serious bug in the miner
Take a look at that
I think that this check throws away a great deal of valid solutions into the trash can.
What if the target is:
And our solution has the perfectly right hash:
It won't make it through the check, will it?
Found a serious bug in the miner
Take a look at that
Code:
// POW Solution Found
if ((swap32(hash32[0]) <= g_pow_target[0]) && swap32(hash32[1]) <= g_pow_target[1])
rc = 2;
else
rc = 0;
I think that this check throws away a great deal of valid solutions into the trash can.
What if the target is:
Code:
000000cc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
And our solution has the perfectly right hash:
Code:
000000aa ffcccccc cccccccc cccccccc cccccccc cccccccc cccccccc cccccccc
It won't make it through the check, will it?
November 23, 2016, 09:00:29 AM
@coralreefer: I know the problem.
It is here:
Longpoll blocks (by design) at most 5 seconds until it times out when nothing happened. If something happens (like a new block) it returns an event earlier.
Maybe it's better to leave it in a separate thread?
It is here:
Code:
new_block = check_new_block(curl);
Longpoll blocks (by design) at most 5 seconds until it times out when nothing happened. If something happens (like a new block) it returns an event earlier.
Maybe it's better to leave it in a separate thread?
November 23, 2016, 08:39:20 AM
Hi EK,
I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.
Also, I fixed that "unknown request type" error you reported earlier. Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.
I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.
Also, I fixed that "unknown request type" error you reported earlier. Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.
Runs smoothly, however, there is still a 5 second delay. And it's not the slow response time of the server. When you take a look at this:
Code:
[14:37:50] CPU1: Submitting POW Solution (000000CC23914E1AFDA22E46...) [t:000000FFFFFFFFFFFFFFFFFF...]
[14:37:55] CPU2: 815.21 kEval/s
[14:37:55] CPU1: 877.87 kEval/s
[14:37:55] CPU0: 860.86 kEval/s
[14:37:55] DEBUG: Submit request - http://127.0.0.1:6876/nxt?requestType=createPoX deadline=3&feeNQT=0&amountNQT=0&work_id=8543365767744104724&multiplicator=010000000000000000000000000000000000000000000000A22B4F26EED0F06C&is_pow=true&secretPhrase=test
[14:37:55] CPU1: ***** POW Accepted! *****
[14:37:55] DEBUG: Submit complete...deleting request
You see that the solution is found at 14:37:50, but the submit request is issued at 14.37:55.
I am also looking hard, but I did not identify the cause yet.
November 23, 2016, 08:34:05 AM
Hi EK,
I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.
Also, I fixed that "unknown request type" error you reported earlier. Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.
I think I have your changes incorporated as well I have updated to miner to include a queue between the miner thread and the workio thread (renamed from the longpoll thread)...this should completely separate the miner from all the i/o once and for all.
Also, I fixed that "unknown request type" error you reported earlier. Please let me know if you see anything else and once this stabilizes a bit, I'll go in and clean everything up.
November 23, 2016, 08:33:46 AM
@coralreefer: pull request for a command line option to skip "renice" just submitted ;-)
Hi hardworking people!
@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.
Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.
Keep up good work.
Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.
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.
Hi hardworking people!
@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.
Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.
Keep up good work.
Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.
Code:
// Redeemer-Account is not allowed to do any transaction whatsoever
if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){
throw new NxtException.NotValidException(
"Redeem Account is not allowed to do anything.");
}
Awesome. Hope this piece of code will remain rock solid
Thank you for clarification. I'm sure that if I had not asked that question someone sooner or later would have similar doubts.Any info about your testnet peers from github config? Do they take incoming connections w/o any problems? Should I look on my side?
November 23, 2016, 08:24:03 AM
@coralreefer: pull request for a command line option to skip "renice" just submitted ;-)
Hi hardworking people!
@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.
Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.
Keep up good work.
Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.
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.
Hi hardworking people!
@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.
Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.
Keep up good work.
Everyone knows the private key to XEL-9HQ9-BXCV-TARZ-BRDNA ;-) I agree that we can use some other address here, but nobody will ever know if I really do not have any access to that address.
That's why the "REDEEM" address is not allowed to submit any transactions and not allowed to generate any blocks.
Code:
// Redeemer-Account is not allowed to do any transaction whatsoever
if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){
throw new NxtException.NotValidException(
"Redeem Account is not allowed to do anything.");
}
if( this.getSenderId() == Genesis.REDEEM_ID && type != TransactionType.Payment.REDEEM){
throw new NxtException.NotValidException(
"Redeem Account is not allowed to do anything.");
}
November 23, 2016, 08:15:12 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.
Hi hardworking people!
@EK, I'm trying to install .7.0 but there is no connection to the network. Are you sure your peer(s) running correctly and not banning anyone? When blockchain is downloading it stops at height 2. No connections to any peers show up.
Also I have little concern. I've seen that all (100M) XEL are in possesion of XEL-9HQ9-BXCV-TARZ-BRDNA. Of course it's address to which you (or someone else also) know private key. After someone redeem, XEL are transfered from XEL-9HQ9-BXCV-TARZ-BRDNA to his address. If mainnet will be live situation will be simillar? Coins will be distributed from address that someone (in this case you) know private key? I think no one should have access to the distributing address. Unclaimed coins should remain unclaimed to the end of Elastic network. Please correct me if I'm wrong in this case.
Keep up good work.
Jump to: