Nut upsdev - Nov 2007 - [nut-commits] svn commit r1156 - in trunk: . drivers

On Nov 25, 2007 11:50 AM, Arjen de Korte
<adkorte-guest at alioth.debian.org> wrote:
> Limit detection of UPS to minimum required number of successful attempts.
Flush input- and output buffers before sending any command.
Can you explain the reasoning behind these changes please?

The detection phase didn't stop after the minimum number of required
replies to check for models that reply twice in a row and then proceed
to returning garbage.

Also, the check_ups function was there because the running a query
isn't exactly the same as verifying the communications. It is mostly
the same now, but keeping the two things separated is better.

-- 
Carlos Rodrigues

>> Limit detection of UPS to minimum required number of successful
>> attempts. Flush input- and output buffers before sending any command.
>
> Can you explain the reasoning behind these changes please?
>
> The detection phase didn't stop after the minimum number of required
> replies to check for models that reply twice in a row and then proceed
> to returning garbage.
Sure. As it used to be, the detection phase would try to get a status from
the UPS five times. If it got three replies (or more), it would consider
this a positive identification. After that, it would try to read a status
once more and if that failed, it would abort. This was suboptimal for two
reasons:

1) It is unreasonable to allow 2 out of 5 tries to fail in the detection
phase, but terminate unconditionally if the sixth try failed.

2) If the first three attempts to read the Q1 status are successful, the
outcome of the detection is already known, so reading two more is not
going to change the outcome anymore.

If a device was detected previously, it will be detected in the same (or
less) attempts now. This hasn't changed. For devices that return a correct
answer every time (many do) this means that the number of Q1 queries is
cut in half.
> Also, the check_ups function was there because the running a query
> isn't exactly the same as verifying the communications.
It was in the trunk. By changing it in the way I did, we can re-use the
result from the third successful read later on and prevent situation #1
altogether. It also makes sure we don't waste more time in the detection
phase than absolutely needed.

The addition of the buffer flushing was a bad idea after all and has been
removed already.
> It is mostly the same now, but keeping the two things separated is better.
I beg to differ here for reason #1. Also, duplication (almost) the same
code is not a good idea in any driver.

Best regards, Arjen
-- 
Eindhoven - The Netherlands
Key fingerprint - 66 4E 03 2C 9D B5 CB 9B  7A FE 7E C1 EE 88 BC 57