[Nut-upsdev] [PATCH] disable nonblocking mode on serial port

[Arjen de Korte]

Citeren Jim Paris <jim at jtan.com>:

>> Because the whole purpose of using NUT is that you must have a reliable
>> connection to the UPS. There is no point in monitoring a UPS if you don't
>> have low (essentially zero) latency.
> I don't follow.  I don't expect 100% reliability (there's a reason NUT
> has a "connection lost" message) and I still see a point in monitoring
> my UPS even if the status updates have a 250ms latency.

It's not a latency of 250ms per polling sequence that I'm worried  
about, it's the possible delay involved for each character that we  
write.

If I understand you correctly, all writes to the USB to RS-232  
converter are failing right now. That would mean that we shouldn't  
only expect additional delays when sending the first character of a  
command, but also for subsequent characters. Since we have some fairly  
verbose protocols in the mix of supported devices, this will  
inevitably lead to timeout problems if the required grace period for a  
select() call is more than a couple of milliseconds.

According to the comments in the header, the Cypress M8 kernel module  
contains the same write buffering as the PL2303. I still feel that  
this is an essential part of a USB to RS-232 converter. If it fails to  
provide that, it is broken. Neither as one expects EAGAIN after  
writing to /dev/null, nor should we when writing to a UART (knowing  
that the transmit buffer is empty).

Last but not least, there is still the problem that *any* USB to  
RS-232 converter introduces the problem that we no longer are in  
control of the delays between characters. Because of the latency of  
the USB bus, even if characters are sent with delays, this delay may  
be lost on the RS-232 side of the converter. This may not be a problem  
for your UPS, but certainly doesn't make this a solution for the  
general case.

Testing any changes in protocol timing are incredibly difficult, if  
possible at all. The NUT developers have access to only a limited  
amount of devices to test with, so any changes require very careful  
examination for possible side effects. Even a small delay added, may  
make all the difference.

Best regards, Arjen

PS  By the way, we have a select_write() call in common/common.c  
already. Especially in the trunk, this takes only one line of code in  
drivers/serial.c (line #299).
-- 
Please keep list traffic on the list