Meaning what?
If NIS restarted, Round 4034 was PASS.
But Round 4035 was FAIL.
You might want to wait a bit longer to see if it helped or not.
I am on vacation for a week, maybe have access to the forum, not sure. Most like will be available on telegram.
Thanks for your reply.
Please enjoy your vacation.
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?
1 Like
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
1 Like
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.
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?
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.
Can you run top (i mean the task manager) and make a screenshot of the output?
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
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 
There seems to be no problem SN using the same provider.
Do I have to change providers?
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.
It’s sad.
My SN has become a volunteer …
“change ip 173.249.34.67 to 51.75.23.101” message sent for “khellendros”
Thanks!
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?
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?