Uptime Rework

[2ndtlmining]

Problem Statement

Today we make use of the Uptime API to retrieve the data. For example:

That retrieves the Flux OS uptime here:

Now this data displayed above is purely the Flux OS uptime. And what happens pretty frequently updates on Flux OS is pushed out and when Flux oS is updated this uptime gets reset. Eventhough the FLlux OS updates the uptime resets, which is not really a true reflection on the uptime of the node just by an Flux OS update. Like to update this to be a more true reflection of the actual node uptime and not the Flux OS uptime.

Desired outcome

Like to make a couple changes:

• Calculation changes
• API Change
• Tooltips

Calculation changes

Like to fundamentally change the calcs to make use of the "Active since" field. Calculation needs to be (Time now) - (Active Since). Just need to make sure the data is converted correctly. Timestamp from API looks to be Unix. Thus need to apply the Js for it:

Javascript timestamp

API change

Current pickup is:

http://<IP>:<Port>/flux/uptime

For example:

Ideal:

https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=<Wallet>'

example:

The above mentioned API is already used in the apidata.js file so should be able to use it and simplify the APIs at least.

Tool-tip changes

Current tool tip relates to Flux OS data we are extracting today:

As is: "Uptime is the amount of time Flux OS has been up. If Flux OS updates or restarts will reset the timer" New: " Uptime is the amount of time since the Node has been started in Zelcore. If node is Offline or DOS in Zelcore the time will reset"

Technical details

Unix date

[Hiroshi97]

@2ndtlmining Hi, by using new API endpoint, seems like it doesn't return all nodes with data. There are a few nodes that have no response data so their uptime can't be calculated. How should we display the uptime for that non-data nodes?

Node with data:

Node without data:

[2ndtlmining]

Hey @Hiroshi97

Not sure what the wallet address or IP is that you hitting that doesnt have any data but that i suspect will make sense just need to do some spot checks. I suspect no data will exist if the person hasnt started/confirmed their node on the network. Thus we should also not have received results in the past making use of the older api. That is my theory. If you have an example i can have a look, but using this we should only receive responses if the node is up and confirmed.

Hope that helps?

[Hiroshi97]

@2ndtlmining Thanks, the wallet address is: t1K5txxB6GLmWezHeUANzVVGi8KjLmuvFyH

Examples: https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=31.7.195.26:16127 https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=195.206.229.60:16127 https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=195.206.229.59:16127 https://api.runonflux.io/daemon/viewdeterministiczelnodelist?filter=195.206.229.51:16127

[2ndtlmining]

@Hiroshi97 Ok this sort of make sense for me i think.

Long story. Per IP you can have up to 8 nodes by enabling UPnP. So what i tried to have a look at is our current solution vs what we are thinking:

https://fluxnode.app.runonflux.io/#/nodes?wallet=t1K5txxB6GLmWezHeUANzVVGi8KjLmuvFyH

There is 8 IP's or nodes on that one IP: 31.7.195.26

31.7.195.26 (Default, which normally would be on 16126) 31.7.195.26: 161. For example:

31.7.195.26 31.7.195.26:16137 31.7.195.26:16147 31.7.195.26:16157 31.7.195.26:16167 31.7.195.26:16177 31.7.195.26:16187 31.7.195.26:16197

Would always be in that range 16137->16197, plus the default.

Looking at the deterministic call:

The value is in that list, but without that port number. As that looks to be the default port. If i remember back we are adding + 1 which i think will not work in this case.

Not sure if we can use the default IP without the UPnP port? Or even if this makes sense :)

[2ndtlmining]

Not going ahead with this for now