Carlos Rodrigues wrote: > If the driver fails to get any data in the current polling cycle, it > declares the data as stale until the next cycle. It tried to read the > data, it got nothing, ergo the current data is stale.
That's a bit too harsh. Even serial communication is sometimes plagued by communication errors (although probably not as often as the USB devices seem to be for this class of UPS). Declaring the data stale on the first failure is not a good idea, since this will trigger a lot of actions in the server (and clients too) for no good reason at all. If the communication is re-established within the next couple of polling cycles, we don't want to hear about any problems. > I don't agree > the driver should systematically retry reading the status within a > polling cycle. You're absolutely right, it shouldn't! Instead, after a failure, it should return from upsdrv_updateinfo() immediately and wait for the next time it enters there. If after three tries, it still gets no data, it's time to declare the data stale (but only then). By doing so you prevent a lot of 'nuisance' tripping of the 'data stale' mechanism, while still detecting reasonably fast that the UPS is gone. In pseudo C code this looks as follows: upsdrv_updateinfo() { int ret; static int retry = 0; ret = status_poll(); if (ret == failed) { ser_comm_fail("Oops! Poll failed!"); if (retry < MAX_RETRIES) { retry++; } else { dstate_datastale(); } return; } ser_comm_ok(); retry = 0; /* parse the status */ dstate_dataok(); /* this should come last! */ } Note that this will mean that for the first couple of communication errors, upsdrv_updateinfo() won't call dstate_datastale() nor dstate_dataok(). That's OK. Only changes in the state will be sent to the server, so as long as you don't intend to change the state, this is not needed (it used to be, but that requirement has long gone). > However, if communication failures are a systematic problem over USB, > the USB layer should deal with it appropriately. I don't think it can, unless it would repeat previous replies when communication errors occur, until three consecutive failures. That's a really bad idea. Best regards, Arjen _______________________________________________ Nut-upsuser mailing list Nut-upsuser@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/nut-upsuser