[Nut-upsuser] Using 'dummy.ups' for a real application, not just testing...

[Tom]

Jim:

>  Regarding dummy-ups looping, note that NUT v2.8.0 introduced a
separation of mode to
>`dummy-once` (default for `*.dev` files to be slurped once) and
`dummy-loop` (default for
> others to be re-read, e.g. `*.seq` files or your use-case). Previously it
behaved like a
>`dummy->loop` for all.

Interesting...  I was using the latest doc's, but what I installed was from
the released raspberry pi distro's (v2.7.4).  I did use a .dev file but it
was looping.  I guess this explains it.

One reason I hesitate to do my own build is not that I can't do it, but I
prefer to use the released distro's because that way, the normal update
process keeps me 'current' (well, maybe a step or-two behind).  If I have
my own build, I know I will likely never touch it again and will eventually
fall way behind the current versions.

>I'd say one problem would be relative inefficiency and overheads: you have
one process
> talking to the device to extract data, save it into a file, another
process to regularly
> fopen() and read it and tell `upsd` to update its model data points.
Depending on OS, file
> access may be expensive (flush to write, audit, RBAC and all that) so
avoiding it makes
> sense, especially in a loop. Since you have dealt with the hard part -
talking to a device, it
> should not be easy to plug that into the skeleton driver (or another if
that is a closer
> match to start from) to `dstate_setinfo()` instead of preparing lines to
write into a file :)

Although I completely understand this argument, part of me feels like this
'inefficiency and overhead' is utterly trivial in this case.  We are
talking about 10's of bytes, not even kilobytes, and updates are seconds,
not milliseconds.  Yes, OS 'overheads' apply too, and if this were a
performance limited application then I could better accept the argument.
If I felt that what I was doing would apply to a wider audience, I would be
more inclined to incorporate it in a way that could perhaps contribute to
the community.  My thought is that this is more of a one-of.

-Tom


On Mon, Feb 20, 2023 at 8:14 AM Jim Klimov <jimklimov+nut at gmail.com> wrote:

> >   Do you think there could be some merit in either embellishing
> dummy-ups or deriving a new driver from it that is sanctioned as a
> 'file-based' interface for NUT?
>
> I'd say one problem would be relative inefficiency and overheads: you have
> one process talking to the device to extract data, save it into a file,
> another process to regularly fopen() and read it and tell `upsd` to update
> its model data points. Depending on OS, file access may be expensive (flush
> to write, audit, RBAC and all that) so avoiding it makes sense, especially
> in a loop. Since you have dealt with the hard part - talking to a device,
> it should not be easy to plug that into the skeleton driver (or another if
> that is a closer match to start from) to `dstate_setinfo()` instead of
> preparing lines to write into a file :)
>
> Regarding RAM-based FS, on one hand there is no benefit to storing these
> files persistently, and any persistent storage I/O just takes longer. Flash
> wearing is also a problem, although it may be relaxed due to caching and
> later flushing large writes (e.g. might happen with logs, if not every line
> is forcefully synced to storage). Older flash techs also had more
> write-cycles (by orders of magnitude) than the faster but more fragile
> current devices which throw smarter caching and more redundant transistors
> at the problem. So if your Pi's were writing logs "for years" they might
> just use earlier-generation SD/MMC devices that lacked finesse but were
> sturdier.
>
> Regarding dummy-ups looping, note that NUT v2.8.0 introduced a separation
> of mode to `dummy-once` (default for `*.dev` files to be slurped once) and
> `dummy-loop` (default for all others to be re-read, e.g. `*.seq` files or
> your use-case). Previously it behaved like a `dummy-loop` for all.
>
> The driver sleeps a hard-coded 1 second between looped file reads. Also
> the file contents may include a `TIMER <NUM>` line to add a delay, whether
> before further lines (e.g. when preparing tests - report on-battery, wait
> 10 sec, report on-line again) or as the last line to slow down the loop.
>
> Hope this helps,
> Jim Klimov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/nut-upsuser/attachments/20230220/7afe7b2d/attachment-0001.htm>