[Nut-upsuser] MGE Pulsar EX1500 RT comms problem

Tue Jul 22 12:21:16 UTC 2008

On Tue, 22 Jul 2008, Arnaud Quette wrote:
> 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.

MAXAGE is 30
DEADTIME is 30

I've tried increasing them both to 60s and it seems to substantially 
reduce the frequency of occurrence but it does still happen (rarely 
enough to be usable though).

> -- 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

-- 
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part.
Url : http://lists.alioth.debian.org/pipermail/nut-upsuser/attachments/20080722/f5e96319/attachment.pgp 