Hi Daniel,
- increase MAXAGE in upsd.conf
- increase DEADTIME in upsmon.conf
- possibly increase the UPS polling interval (pollinterval in ups.conf)
which is set to 2 seconds currently, to lower the communication load on the
UPS.
the exact values depends on what you see in your log.
ie, if your UPS is marked stale for 20 seconds, putting 25 for MAXAGE and
DEADTIME should be fine.
-- Arnaud
2008/7/22 Daniel O'Connor <doconnor at gsoft.com.au>:
> Hi,
> I have the above UPS connected to a FreeBSD 6.2 box and it shows 'data
> stale' very frequently (every few minutes).
>
> I have tried the usual trick of setting maxage, poll interval, etc etc
> but to no avail.
>
> When I wind up logging I see (on mge-shut)
>
> entering shut_get_report(id: 0d, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 16, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 17, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 2f, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 20, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 07, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 0a, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 07, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 04, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 12, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 04, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 12, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 13, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 39, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 37, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 38, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 04, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 12, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 13, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 3e, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 3c, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 3d, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 06, len: 1800)
> shut_wait_ack(): ACK received
> entering shut_get_report(id: 06, len: 1800)
> shut_wait_ack(): ACK received
> entering upsdrv_updateinfo()
> entering shut_get_report(id: 0f, len: 1800)
>
> And upsd..
> write: [destfd=7] [len=15] [ERR DATA-STALE]
> sstate_dead: driver for UPS [ups1] says data is stale
>
> Broadcast Message from radar at negrocreek.dnsalias.net
> (no tty) at 7:57 UTC...
>
> Communications with UPS ups1 at localhost lost
>
> sstate_dead: driver for UPS [ups1] says data is stale
> UPS [ups1] data is no longer stale
> acl_check: localhost: match 1
> ACL [localhost] matches, action=1
> write: [destfd=7] [len=30] [VAR ups1 ups.status "OL CHRG"]
>
> Broadcast Message from radar at negrocreek.dnsalias.net
> (no tty) at 7:57 UTC...
>
> Communications with UPS ups1 at localhost established
>
> acl_check: localhost: match 1
> ACL [localhost] matches, action=1
>
> It seems to decide very quickly that things are stuffed :(
>
> I just built a fresh NUT 2.2.2 (from 2.2.0) but got the same problem.
>
> Anyone have any suggestions?
>
> It does not seem related to the known issue in the mge-shut man page but
> rather that the UPS does not respond properly (or the OS is dropping
> data but I don't see any errors about it).
>
> One other possibility is that noise is being seen on the serial line
> (this system drives a high power VHF radar) - I have asked someone
> onsite to check the cabling but it would be nice if NUT could be
> adjusted to be more tolerant.
>
> Thanks.
>
> --
> Daniel O'Connor software and network engineer
> for Genesis Software - http://www.gsoft.com.au
> "The nice thing about standards is that there
> are so many of them to choose from."
> -- Andrew Tanenbaum
> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
>
> _______________________________________________
> Nut-upsuser mailing list
> Nut-upsuser at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080722/5df34e2d/attachment.htm