NEM Supernode Rewards Program


#2698

Meaning what?


#2699

If NIS restarted, Round 4034 was PASS.
But Round 4035 was FAIL.


#2700

You might want to wait a bit longer to see if it helped or not.


#2701

I am on vacation for a week, maybe have access to the forum, not sure. Most like will be available on telegram.


#2702

Thanks for your reply.
Please enjoy your vacation.


#2703

Hi BR, sorry for interupt your vacation.

The node name nem’strunk2 has the same trouble since version 0.6.96.
The only responseness sometimes fails.

https://supernodes.nem.io/archive/482/4050

What do you think about the reasons of this issue?


#2704

Too much FAILS of Responsiveness after updating to 0.6.96
I don’t know what’s going on.
https://supernodes.nem.io/history/search/XEMCAT


#2705

i doubt it has something to do with 0.6.96. The responsiveness only concurrently retrieves the chain height 10 times. Seems like the connection to Japan is not very stable.


#2706

Same provider as Shohei_Kamon is using and same problem. Did you change the provider recently or was it already running with that provider for a long time?


#2707

Thank you for your reply.

After changing to 0.6.96, FAIL by The responsiveness began to occur frequently. I changed to a superior plan and increased the memory allocation of nis and servant. But the situation is not change.


#2708

Can you run top (i mean the task manager) and make a screenshot of the output?


#2709

please check this.


#2710

This is a report by a NEMber. not me.

He looked at the SN where Responsiveness frequently fails.

sulfur(Australia) itechly-1(China) XEMCAT(Japan/DIX Co) liang4(Japan/DIX Co) acmilan(Japan/Sakura Internet) nem’strunk2(Japan/DIX Co) KJ0022018(China)…

then He checked REWARDS HISTORY.

https://supernodes.nem.io/history

He pointed out that failing SNs have commonality that auditing is concentrated at the same time. for example, 10/14 21:26:58~10/14 21:40:03


#2711

Hmm…that look fine to me, NIS should have enough RAM.
Looking at the node rewards master logs, i get the feeling that the connection from the US (where the master is located) to Asia and Australia has serious glitches. At least for certain providers. Also it seems that the situation got worse in october.
Since 0.6.96 was released in August, i doubt it has anything to do with it. Not sure what i can do :confused:


#2713

There seems to be no problem SN using the same provider.
Do I have to change providers?


#2714

Hmm…i am not sure what the solution is. Alice5 + 7 are nodes in japan that use vultr as provider. They don’t seem to have problems.


#2715

It’s sad.
My SN has become a volunteer …:sob:


#2716

“change ip 173.249.34.67 to 51.75.23.101” message sent for “khellendros”

Thanks!


#2717

Hi, @BloodyRookie!
I have two master nodes on neighboring IPs. Periodically, they begin to synchronize with each other. At this time, the chain/height on this MNs does not change. Accordingly, during this period they do not receive any rewards. Is there any way to solve this problem?


#2718

They should not only sync with themselves. Aren’t they also syncing with the pre-trusted nodes (e.g. Alice nodes)?
If not, can you supply the log for such a self-sync period?