• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Version 12.2 release

Status
Not open for further replies.
I think 8 is as low as it will go even if you put it to 1 you still get about 8 connections from what i saw in testnet. But if you consider what you are doing here is limiting your number of peers. Thus fewer peers to communicate data with which will delay sure maybe only slight but your nodes information / broadcast through the network will take a bit longer.
 
The more connections you allow the higher the load (you can/will sync to more peers simultaneously). Can't recommend a specific number, it depends on your machine specs. I know that my machine feels a bit toasty with 64 connections, but hey, why just sit there doing nothing if I pay the same $$ anyway, regardless of the load :)
 
The overhead of concurrent connections is not a new problem. Efficiently handling large numbers of concurrent connections is the never-ending quest of transaction and web servers alike.

Guess what MNs are...

Back before DASH got expensive, I ran 24 MNs on a 32-thread server with 64GB or RAM. Each VM was allowed 4GB RAM and 2 threads. Nothing but SSD. Paging consolidation kept actual, physical RAM usage below 40%, and CPU usage rarely bumped above 2.4% under normal operations, with each node allowed 256 MAX connections...

256 * 24 = 2.4% CPU

So, yeah, there's that...
 
Last edited:
Done all the updates and restarted my MN.
My wallet is stuck at syncin "3 days ago".
I know the MN is enabled, for it is hosted and has been confirmed and I can monitor that on the host page.
But my wallet does not finish syncing.

What am I missing?
 
I've got a problem I've been noticing for multiple generations of dash-qt.

Crash during mixing. Sometimes it takes a few hours to crash. Sometimes it'll take a few days. Sometimes it just bombs on it's own, sometimes you see the client, and it bombs the instant you click on a button or menu.

It's been this way from 12.0 and the same problem occurs in 12.2.1

The only commonality I find is actually the lack of a commonality.

I have two very underpowered machines.

1) old Intel Atom netbook with 1GB of RAM
2) old AMD C-50 netbook with 2GB of RAM

The client NEVER crashes on these two machines. I use them for mixing specifically because they never crash.

My more powerful machines are all equipped with drastically more RAM. Crashes occur at least daily on any of the more powerful machines.

Dual core Celeron w/ 8GB RAM is the "least unstable" of the machines that crash. The only commonality is that machines with large amounts of RAM crash a lot. Seems counter-intuitive, but this is empirical observation across over a dozen completely unrelated hardware combinations.

This seems to be a chronic problem. I even noticed in 12.2 forward, that the client seems to remember the "DS enabled" status, and re-starting the client after a crash does not require me to enable DS as is did in 12.0 and 12.1 after a crash.

Could the crashes be caused by memory handling in large volumes, given that the machines with limited RAM never crash?

Give your MN 16GB of RAM and watch what happens... We've been focused on minimum MN requirements. Nobody noticed that, yes, MNs turn into crash-a-holics if you give them a bunch of RAM, too.
 
Last edited:
McPeth said:
Done all the updates and restarted my MN.
My wallet is stuck at syncin "3 days ago".
I know the MN is enabled, for it is hosted and has been confirmed and I can monitor that on the host page.
But my wallet does not finish syncing.

What am I missing?
Click to expand...
- try "getchaintips 3" in debug console to see if there are any invalid branches
- check debug.log for "invalid header" or "invalid block" messages
 
Here is an invalid.

"height": 769066,
"hash": "00000000000000219eb0ff02c8ac196eeaceee1ce7453d228a1af77e129b607f",
"difficulty": 38353722.43502148,
"chainwork": "00000000000000000000000000000000000000000000005971283f0510761f8a",
"branchlen": 1,
"status": "invalid"

Log is packed with "invalid header"(s)
 
McPeth said:
Here is an invalid.

"height": 769066,
"hash": "00000000000000219eb0ff02c8ac196eeaceee1ce7453d228a1af77e129b607f",
"difficulty": 38353722.43502148,
"chainwork": "00000000000000000000000000000000000000000000005971283f0510761f8a",
"branchlen": 1,
"status": "invalid"

Log is packed with "invalid header"(s)
Click to expand...
Ok, now run following commands in console, one by one:
mnsync reset
reconsiderblock 00000000000000219eb0ff02c8ac196eeaceee1ce7453d228a1af77e129b607f
clearbanned
 
I noticed a bunch of masternodes that report 0.12.2.0 or 0.12.2.1 version in p2p messages yet they are running on 70206 protocol according to masternode list. Make sure you see 70208 and not 70206 next to your node in "masternode list protocol" (or in "masternode list full"). If you upgraded remote node to 12.2 and issued start command from local wallet but still see 70206 then you previous attempt was NOT successful and you node will NOT be paid. To fix this you MUST send start command with correct protocol number i.e. from 12.2 wallet or via latest version of DMT if you use Trezor.
 
Do I need to remote restart again?
On another note - Now that is synced I don´t see the daily payment from a mining contract I have. No pays since the 11th, the day I upgraded to 12.2.
 
UdjinM6 said:
I noticed a bunch of masternodes that report 0.12.2.0 or 0.12.2.1 version in p2p messages yet they are running on 70206 protocol according to masternode list. Make sure you see 70208 and not 70206 next to your node in "masternode list protocol" (or in "masternode list full"). If you upgraded remote node to 12.2 and issued start command from local wallet but still see 70206 then you previous attempt was NOT successful and you node will NOT be paid. To fix this you MUST send start command with correct protocol number i.e. from 12.2 wallet or via latest version of DMT if you use Trezor.
Click to expand...
I saw it, too, but I was just going to wait for them to start complaining...

@chaeplin is dashmnb in compliance?

DMT doesn't have tor support... At least not that I can find.
 
DASH mining looks like its going to die soon. :(
Please help the miners! Is a reduction in the difficulty time re-adjust possible to something a little slower ?
Also how about a little more reward for mining and less to the Master nodes- I know Master node owners would not be happy but master node profit will die anyway if no one mines because power costs overtake profits. If any of these changes are possible please consider- at this rate no one will be mining DASH in a few weeks
 
Bitwinter said:
DASH mining looks like its going to die soon. :(
Please help the miners! Is a reduction in the difficulty time re-adjust possible to something a little slower ?
Also how about a little more reward for mining and less to the Master nodes- I know Master node owners would not be happy but master node profit will die anyway if no one mines because power costs overtake profits. If any of these changes are possible please consider- at this rate no one will be mining DASH in a few weeks
Click to expand...
https://www.dash.org/forum/posts/146834/
 
Note to mining pools:
As more and more MNs upgrade to 12.2 (80%+ already), winners list on 12.1 becomes less and less consistent. You can check this by running "dash-cli masternode winners 500", note old blocks with "Unknown" winner. This means that by keeping mining on 12.1 your pool will produce invalid (orphan) blocks more and more often. To continue mining valid blocks please update to 12.2.1 ASAP.
 
demo said:
And you can clearly see in the below chart how the market reacted, after the 12.2 update.
Maybe the stupid Masternodes should write for punishment the above sentence not only 100 times, but 1000 times, in order to finally understand it.

View attachment 5205


And especially for @Macrochip (who rated the above truth as troll) he should write it 10000 times.
Click to expand...

Let me also calculate the Return of Investment, in this case study where the Dash masternode owners invested wisely.
Dash's price was about $200 , and after 12.2 was released it reached $400
Which means a profit $200 per dash, aka 200*7.691.998=1.500.000.000$
How much do you pay these guys for making Dash community get a profit of 1,5 billion dollars?
Do you think is enough?
Invest in developers. Invest in developers. Invest in developers.
Do it now, you stupid masternodes!
 
Last edited:
demo said:
Let me also calculate the Return of Investment, in this case study where the Dash masternode owners invested wisely.
Dash's price was about $200 , and after 12.2 was released it reached $400
Which means a profit $200 per dash, aka 200*7.691.998=1.500.000.000$
How much do you pay these guys for making Dash community get a profit of 1,5 billion dollars?
Do you think is enough?
Invest in developers. Invest in developers. Invest in developers.
Do it now, you stupid masternodes!
Click to expand...
The core team is expanding constantly.
Treasury budget is 6651.85 Dash per month. So, at 400 USD per Dash, that is 2,660,740 USD.
In the US a software dev makes like 5500 USD a month. Based on that, we could employ about 484 people.
Is that what you are saying we need?
 
Acedian said:
The core team is expanding constantly.
Treasury budget is 6651.85 Dash per month. So, at 400 USD per Dash, that is 2,660,740 USD.
In the US a software dev makes like 5500 USD a month. Based on that, we could employ about 484 people.
Is that what you are saying we need?
Click to expand...
I am against salaries. Because those who receive salaries, they are slaves. You should pay developers from the budget. You should pay them whenever they finish a promised job, or whenever they propose something smart (a smart white paper for example).

Of course when I say budget, I mean an alternative budget system and not the current stupidity. Dont pay salaries to the developers, let the developers compete each other (with the help of an alternative budget system that will allow to vote the numbers, of course).

Obviously you should also let the testers compete each other, fortunately this is already done with the help of @jimbursch and his bugbounty project. With a slight change of course, the bug discovered should reduce the compensation of the developer who is responsible for it. You should also create a testers hall of fame.
 
Last edited:
Status
Not open for further replies.
Back
Top