This is a very common problem and will get worse over time.
We need NIS to automatically wait for synchronization before start harvesting
Sorry, Iāve got another problem now: Several hours after activating delegated harvesting I have the button āStart delegating harvestingā available. If I press it (or start NIS with shouldAutoHarvestOnBoot = true) I just get the error āFAILURE_HARVESTING_INELIGIBLEā.
How to fix this one?
Seems like your account doesnāt have enough vested xem in it. Either you need to wait a bit or buy more xem.
How many blocks does it take until theyāre vested? Since Iāve got a fair amount > 3m it can only be a matter of time. I activated delegated harvesting about 6.5hrs ago.
Edit: just found this
Every 1440 blocks 1/10th of the unvested balance is moved to the vested part.
The client shows: vested balance: 0.00
So I need to wait another day to start the supernode. I guess it would be good to mention this at the howto.
Edit 2: Extra question:
Do I need to have a vested balance of 3m+ or just a balance of 3m+?
3M balance is enough
Yes iām positively sure Iām editing the right file.
Iām passing the rounds now though, so seems that the settings are ok for the tests. Only the metaData seems wrong.
@meyns: your servant and nis are showing the same public key now so everything is ok:
NIS: http://78.47.156.250:7890/node/info
Servant: http://78.47.156.250:7880/nr/metaData
What else has to be done before this program goes live? Any eta?
And last but not least: are there other places to discuss about supernodes? I just found this thread, which seems to be more a how-to-setup guide than a discussion.
The Supernodes program is currently undergoing alpha testing and is looking for volunteer nodes to participate. During this phase of testing, rewards will not be distributed. Once the Supernode network is working and all parameters configured properly a date for the official start will be announced.
There is no eta yet but we are pretty near.
What would you like to discuss?
I need to wait about how my new supernode operates for some time to open a discussion if needed.
I was just curios whether there are discussions ongoing or not, because the configuration of the parameters is explicitly mentioned in OT.
Some guys suggested to lower the system and balance requirements.
As further steps we could discuss options to let lightwallets automatically choose the best performing node and reward those choosen nodes by either highten their importance or give extra points for the reward program.
The point is: the less home āsuperā nodes the better for user experience. They have low upload rates, very dynamic bandwidth usage and very low availability warranty (SLA) compared to nodes located in data centers. If NEM also wants to serve enterprise, it also needs enterprise infrastructure. Thatās why imho no home hosted node should ever be considered as supernode.
we are discussing that topic internally.
i think the mobile app will do that but lightwallet not.
that is not planned. Importance cannot be changed externally and i am not sure it is a good thing to give extra credits to highly used nodes since that kind of supports centralization.
We got not many home nodes since they usually donāt have the needed bandwidth.
What we are discussing is some incentive (extra rewards) for nodes running in certain areas since the supernodes map shows we got very many nodes in germany but few in some other places.
@BloodyRookie
Iām querying my own node using the NIS API calls, similarly to what the servant is doing locally on the node I assume.
Iām experiencing slow performance in some API calls when the node is in Synchronizing status.
This happens for example with the GET call on http://node:7890/account/transfers/outgoing.
I have the impression similar slow performance when the node is synchronizing causes the servant to report a bad result for the Chain part and/or Responsiveness of the test.
If thatās the case, the cause of the failing test is the NIS API perfomance, not the characteristics of the node itself.
In my opinion, the performance of those API calls, when synchronizing, should be resolved.
The request should be handled asynchronously. The servant has no way to tell in what state NIS is. If the sync status really was influencing the result, how come that some nodes donāt experience problems?
I am not saying that there isnāt something strange going on, but it is hard to pin down.
@BloodyRookie: Any chance we could get a simple API on the node rewards website?
Just a URL that returns a json object with IP/hostname of the nodes that were legible for the last payout would do. This would be useful to get a list of reliable nodes to use.
Some calls give sometimes a timeout. Even in asynchronous mode. There is something strange going on. And I know it is hard to pin down. Thatās why I investigated and am trying to help.
I use an API call to know in what state NIS is: http://bob.nem.ninja/docs/#status-request: code 6 is synchronized, code 5 (documented as booted) means Synchronizing I assume. I donāt understand why the servant should not be able to know this.
All Iām saying is I noticed some correlation between timeouts on API calls and this NIS state 5. And youāre right, itās not always the case. As I said, just trying to help hĆ©.
P.S. Alice4 http://supernodes.nem.io/archive/3/555 f.e. also missed the chain part in round 31368
and Alice5 http://supernodes.nem.io/archive/4/555 missed the responsiveness test in round 31359
and ā¦ the list goes on
@owner of NEM-Supernode-3:
The public key used for the enroll message is the same as the one for the deactivated node āHi Iām NEM-Supernodeā.
Does that mean you want to change the nodeās data to the new data (alias and ip) and have it activated?
I donāt it has anything to do with the state. I see nodes failing the computing power tests occationally too although they normally pass the test. Since NIS is not involved in that test the state of NIS is not relevant.
I am investigating if the garbage collector might be the problem (if there is a full garbage collection going on, it will stop the java application for that action). If it turns out that the garbage collection is not the problem there are two things i can think of that can influence the vps behavior:
- Due to low memory the vps might be forced to use (slow) swap memory during the test.
- The server hosting the vps is under heavy load und thus the vps slow. Remember, a vps is not a dedicated server, other vps instances can influence the behavior of your vps temporarily.
For two days now, my node (107) is failing every test. I restarted NIS, NCC and servant. Community Client is working fine. Any Idea?
Looks like neither port 7890 nor 7880 is open (or nis/servant not running):
NIS: http://nem.noip.me:7890/node/info
Servant: http://nem.noip.me:7880/nr/metaData
Please ensure that the ports are indeed open.
Yes, the Ports are forwarded to my machine. IĀ“m playing around with the router settings now, but I didĀ“t change anything when it failed to connect.