[Nut-upsdev] Riello UPs implementation for NUT software

Arnaud Quette aquette.dev at gmail.com
Wed May 9 12:24:46 UTC 2012


(forwarding msg because of attachment too big... so compressed)

@Ivan: as told previously, please subscribe to the mailing prior to
sending any further mail.
Also, whenever you send attachment, please compress these to fit in
below the 40Kb limit...

Now that Riello has jumped officially on the mailing list, you should
probably get an answer from them quickly...

-- Arnaud

---------- Message transféré ----------
From: Ivan Kuznetsov <kia at solvo.ru>
To: nut-upsdev at lists.alioth.debian.org
Cc:
Date: Sat, 05 May 2012 17:27:28 +0400
Subject: Re: Riello UPs implementation for NUT software
Hello

1. snmp-ups driver from nut 2.6.3 takes very long time to startup. The
init script shows the service as failed at startup, but the driver is
still starting. After a time upsd successfully connects to the driver
and works normally

As I can see the driver polls a number of SNMP variables the
snmp-adapter does not respond for. E.g.
1.3.6.1.2.1.33.1.6.3.8 (upsAlarmOutputOverload)
1.3.6.1.2.1.33.1.7.1.0 (upsTestId)
1.3.6.1.2.1.33.1.7.3.0 (upsTestResultsSummary)
Each of this poll results in 6 sec timeout, so the complete driver
startup takes 60-65 sec, more than standard timeout (45 sec) for
upsdrvctl

2. Each UPS poll cycle takes ~12 sec to complete. Slow SNMP-adapter?
It seems that it become much slower when there are more than one PC
polls them

Log of `snmp-ups -a mdt40 -u nut -DD` is attached. I turn off the UPS
input at about 300s of logging and turn it on at ~390s


24.04.2012 17:55, Ivan Kuznetsov пишет:

    Hello

    We have an Riello MDT40 UPS at our data room. We currently monitoring
    the UPS via Netman 102 plus Web/SNMP card using RFC1628 mibs. UPS status
    is mostly reported correctly but there are some issues with values
    reported. E.g. output power is not in Watts, input power is constantly
    0, battery charge current varies upto unreal values. Alsow we find that
    sometimes the card becomes unresponsible, probably hangs. We need to
    reset the card to return access to it

    Some time ago we have update card firmware to v1.15 and some of mistakes
    went avay. May be we can cooperate to make card firmware better?

    Of cource we can do some tests with both NUT and hardware we have

    Regards, Ivan Kuznetsov
    System Administrator of SOLVO ltd
    http://www.solvo.ru


Regards,
Ivan Kuznetsov
System Administrator
SOLVO ltd
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mdt40.log.bz2
Type: application/x-bzip2
Size: 13434 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/nut-upsdev/attachments/20120509/5b29aad4/attachment.bin>


More information about the Nut-upsdev mailing list