Introduce state entry timestamping and use it to fix apcupsd-ups
#2010
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ls#2007, networkupstools#797 fallout] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…pstools#797 fallout] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…meval() Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…eteness Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…te_get_timestamp() and st_tree_node_compare_timestamp() to track age of state entries Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…pstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…oleted readings AFTER refreshing data from apcupsd daemon [networkupstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…FTER refreshing data from apcupsd daemon [networkupstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
… a new value Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Benchmarking by eyeball is always dubious at best. But given that the values going into the state info trees are converted to C strings, I have a feeling that the timings for int-to-double conversion of the timestamps will be dwarfed by the conversion to strings (at least on modern platforms). I definitely don't claim to be an expert on the state trees, so I wouldn't trust myself to notice whether there are subtle bugs being introduced. |
… of got_monoclock in upsnotify() [networkupstools#1777 follow-up] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…etworkupstools#1777 follow-up] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…rkupstools#2007, networkupstools#1777] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…2010] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…stools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…ollow-up] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…x expression [networkupstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
…etworkupstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
… we are deleting an entry because it is too old [networkupstools#2007] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com>
|
Checked locally, does not regress with an Eaton UPS (not impacted directly like |
|
Also checked in original issue #2007 to actually fix the problem the user came with :) |
alexwbaule
pushed a commit
to alexwbaule/nut
that referenced
this pull request
Oct 4, 2023
…2010] Signed-off-by: Jim Klimov <jimklimov+nut@gmail.com> Signed-off-by: Alex W Baulé <alexwbaule@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
CC @aquette @clepple : This is a fairly noticeable change to the deep internals, state info trees are at the core of everything in NUT. Would welcome another set of eyeballs that I got this conceptually right :)
Should I be concerned about computational overheads to keep reading and comparing time values? Should this behavior become a toggle (e.g. for programs that know they intend to use this feature at all)?
In context of issue #2007 there is a need to somehow avoid the current behavior with deletion of nearly all info about the device and then re-querying
apcupsdto populate the dstate again. With this change we hopefully (un-tested so far) have a way to determine if any entries were not updated in the last read, and so should be cleaned away AFTER talking to the device (apcupsd server in this case).While this is a first use for such tech, I can see it proliferating into other drivers to support "Data stale" decisions (e.g. attempt to re-initialize the hardware connection), etc.
Closes: #2007
Fixes: #797 fallout