You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In gluon the announced hardware model gives me a good feeling of the underlying capabilities of a node.
This is not easily achievable for supernodes, especially considering the widely used virtualization in form of qemu or vmware.
This path could reveal some core details though,
like architecture, single core speed as well as installed ram.
An example for one of our supernodes might look like this: x86_64 2.60GHz 1.45GB
Imo in combination with nodeinfo.hardware.nproc this becomes quite useful.
The text was updated successfully, but these errors were encountered:
I find an automatic default useful. However, one must consider whether it would really be good to pack the specs in there or whether one would like to solve this differently (if not already included via own fields). This is of course much more complex, but for example in meshviewer there is a list with the grouped device models. Whether one would like to have gateways with different amounts of RAM or slightly different CPU Speeds listed individually I am undecided. I think it would have advantages, but it is also kinda an abuse of the field.
In gluon the announced hardware model gives me a good feeling of the underlying capabilities of a node.
This is not easily achievable for supernodes, especially considering the widely used virtualization in form of qemu or vmware.
This path could reveal some core details though,
like architecture, single core speed as well as installed ram.
An example for one of our supernodes might look like this:
x86_64 2.60GHz 1.45GB
Imo in combination with
nodeinfo.hardware.nproc
this becomes quite useful.The text was updated successfully, but these errors were encountered: