[dashninja.pl] Dash Masternode Ninja - Free Masternode Monitoring
- Thread starter elbereth
- Start date
The server was acting up. Should be ok now.
What does a red background mean in Masternode information?
The masternode has been paid several times but Last Paid (from dashd) is "Never/Unknown". Does it indicate a problem with the masternode?
What is the meaning of "missed" and "hijacked" in Total Paid (Last month)?
Attachments
Last Paid (from dashd) is the information retrieved from dashd and from blocks is directly from blocks information by Dash Ninja.
Sometimes they are not agreeing and the background is red. Nothing important as long as you get paid.
Missed payment means there was no payment in the block where your masternode was expected to be paid.
Hijacked means the reward was payed to another masternode but yours was elected in the block template.
Sometimes they are not agreeing and the background is red. Nothing important as long as you get paid.
Missed payment means there was no payment in the block where your masternode was expected to be paid.
Hijacked means the reward was payed to another masternode but yours was elected in the block template.
Thanks for your reply!Last Paid (from dashd) is the information retrieved from dashd and from blocks is directly from blocks information by Dash Ninja.
Sometimes they are not agreeing and the background is red. Nothing important as long as you get paid.
Missed payment means there was no payment in the block where your masternode was expected to be paid.
Hijacked means the reward was payed to another masternode but yours was elected in the block template.
But what if Last Paid (from dashd) is "Never/Unknown" but Last Paid (from blocks) shows the last payment that was 10 days ago? Is everything OK in this case? Status is "Active (100%)".
As long as you were paid correctly on your end it can be many things going wrong on Dash Ninja end.
It is just a monitoring site with info from a few nodes in different countries.
I don't know how dashd retrieve the lastpaid info, so you will need to ask the Dash core devs.
For Dash Ninja it can miss payments when the server goes offline and catch up later on (which happened this week).
It is just a monitoring site with info from a few nodes in different countries.
I don't know how dashd retrieve the lastpaid info, so you will need to ask the Dash core devs.
For Dash Ninja it can miss payments when the server goes offline and catch up later on (which happened this week).
Actually, Last Paid (from blocks) and status are correct.
The masternode does not show up in the list of the last 5000 winners. I wonder whether I should restart it or just wait?
The masternode does not show up in the list of the last 5000 winners. I wonder whether I should restart it or just wait?
Is it in the list of masternodes on Dash Ninja?
If it is and is Active, it should be ok. If not a restart might be a good idea, beware that if you do you will get on the end of the payment queue.
If it is and is Active, it should be ok. If not a restart might be a good idea, beware that if you do you will get on the end of the payment queue.
@dark_wanderer If it was 10 days already then dashd (12.0) could see it as "never paid" even if it was before but that's ok, it means that you are in top 10% from which MNs are picked randomly so just keep your mn online do NOT restart it via masternode start-* commands and it should be paid eventually. If you restart, it will be brought to the end of the queue and you'll have to wait 7+ days to get into that top 10% again.
Thanks, UdjinM6.
As a follow up on the randomness of the selection: if a masternode was "unlucky" in the last round, does that mean that it will be "luckier" in future rounds so that on average each masternode has the same expected payment?
No, the "luck" is "how close am I to some random-ish (but deterministic) hash?" and you can't predict that future hash
Sorry for off-topic here, but could you please post the name of the source file with the implementation of this random/deterministic selection?
no, static IP is only required to make it discoverable/available
masternodeman.cpp, look for `CMasternodeMan::GetNextMasternodeInQueueForPayment` and dig from there
@elbereth
In the old budget system we could see the masternodes who voted. For example: the old 10-Video-Tutorials proposal. https://www.dashninja.pl/budgetdetails.html?budgetid=10-Video-Tutorials . All masternodes' votes are visible.
Now, in the new governance system, where are the votes? I can see the new 10videotutorials proposal, but the votes of the masternodes are hidden from the public view. https://www.dashninja.pl/governance.html
Is there a way for your site to read the sentinel.db sqlite database? There is a database table in sentinel.db, named votes. Have you managed to read it? Can you show us who are the masternodes that supported a specific proposal in the new governance system?
In the old budget system we could see the masternodes who voted. For example: the old 10-Video-Tutorials proposal. https://www.dashninja.pl/budgetdetails.html?budgetid=10-Video-Tutorials . All masternodes' votes are visible.
Now, in the new governance system, where are the votes? I can see the new 10videotutorials proposal, but the votes of the masternodes are hidden from the public view. https://www.dashninja.pl/governance.html
Is there a way for your site to read the sentinel.db sqlite database? There is a database table in sentinel.db, named votes. Have you managed to read it? Can you show us who are the masternodes that supported a specific proposal in the new governance system?
I still have to code the front-end for the new system.
Even the governance page is not totally complete but I wanted to publish the work I had. I only have a few hours on weekends to work on Dash Ninja.
The votes are there in Dash Ninja database and you can also retrieve them using dashd or the Dash Core debug console.
I will be adding a detail page where you can check them.
I am not accessing Sentinel db at all, yet (maybe it will be needed for Evo). Everything I need is in dashd and can be retrieved via RPC calls.
Aha! Instead of asking the database directly, you are quering the votes from the dashd via rpc calls, and dashd asks sentinel's python, and python asks sqlite database, and the sqlite database is written into the disk drive directly as a file, and the disk is a network disk and it swaps awfully, and the sockets timeout, and the dashd threads timeout and a lock occurs! I think I discovered the reason of the sync problems!
@UdjinM6 , @camosoul come here! I caught the responsible of the sync problems!!!
Last edited:
Are you sure?
I think the votes are stored in a sqlite database.
Do you bet 0.1 dash on it?
100% sure, I have no Sentinel on my desktop but I can retrieve them from the debug console of my dash-qt.
Thanks for the easy dash...
Thanks for the easy dash...
You dont need to have sentinel on you desktop, as long as you read the debug console, or as long as you use rpc calls.
If you retrieve the votes as text from your debug console (you have to be online 24/7 for that!), then there are no sync problems for sure. But if you retrieve the votes via rpc calls, then you have to ask a dashd who has an installed sentinel nearby, and who asks the sqlite database.
If someone is 24/7 online like you, he can use the text from his debug console. But what if some people go offline, then ask the votes later? In that case there is no debug console at all. They have to ask the sentinel database, and if they do this via rpc, via dashd, via python, via sqlite, via disk drive, then this obviously may cause sync problems. Especially the last part of the chain, if it is a network drive, this may cause a tremendous disaster.
Let me remind you, or inform you if you dindt know: "SQLite is not a client–server database engine. Rather, it is embedded into the end program. SQLite stores the entire database (definitions, tables, indices, and the data itself) as a single cross-platform file on a host machine"
Sqlite is an embedded database, so if used with a network drive and/or rpc calls, and as long as sqlite is stored into a single file, this may cause sync problems.
Finnaly the votes are not stored in the debug console, they are stored into the sqlite database, so you didnt win the bet.
Last edited:
I read the code.
https://github.com/dashpay/sentinel/blob/master/sentinel.conf
It writes db_driver=sqlite
Isnt this the case? Have you changed your db_driver to something that is not sqlite?
Please forgive me, but I have not a runtime version of masternode. My whole conclusions are based in what i read in github.
Anyway, thanks both of you for your remarks.
I will read this gobject library more carefully, in order to understand it. I am searching for proves in order to justify my theory that the sync problems occur because you depend on a database that resides in a flat file and does not follow the client-server model. I will come later on, if I manage to discover some proves for my theory.
Last edited:
Update : Dash Ninja Governance page :
Each proposal now links to the new detail page.
New : Dash Ninja Governance Proposal detail page :
As with the old budget detail page, get detailled information about the proposal, including individual votes of the masternodes.
Update : Dash Ninja Masternode Detail page (v3.0.0) :
Now shows the extended status of your masternode (exact code as seen on each Dash Ninja monitoring node).
Each proposal now links to the new detail page.
New : Dash Ninja Governance Proposal detail page :
As with the old budget detail page, get detailled information about the proposal, including individual votes of the masternodes.
Update : Dash Ninja Masternode Detail page (v3.0.0) :
Now shows the extended status of your masternode (exact code as seen on each Dash Ninja monitoring node).
The country is retrieved using geoip database from the IP of your masternode.
So if it was not set by your hosting provider, it will be unknown.
In my case, dashninja geoip database not going good, I have check IP and is visible as US but I checked and have IP from Shanghai