[Nut-upsdev] [nut-commits] svn commit r1846 - in trunk: . clients common drivers include man server
aquette.dev at gmail.com
Wed May 27 12:01:16 UTC 2009
2009/5/26 Arjen de Korte <nut+devel at de-korte.org <nut%2Bdevel at de-korte.org>>
> Citeren Daniel O'Connor <doconnor at gsoft.com.au>:
> <shrugs> seems silly to go to extra effort to generate relative time
>> stamps (save when you start, gettod & subtract for each log) when you
>> can trivially generate absolute ones which allow you to reference any
>> other event on your system be it another NUT daemon or not.
>> What advantage do relative timestamps have?
> It is much easier to see how much time is spend and therefor, find the
> place where timeouts occur (which causes the vast majority of problems). We
> humans have a much harder time to calculate the difference between nine
> figure numerals, than for two to three figures, so therefor I prefer
> relative time.
> Most problems where timestamps are useful will happen in the first few
> seconds after starting (trust me on that, being involved in NUT for so
> long). For anything that happens only occasionally, we'll have to rely on
> upslog() anyway, since we can't expect people to run programs in debug mode
> all the time. The amount of data to weed through would be overwhelming also.
I'm fine with your approach, at least for the time being since it brings
what is first needed: a better insight of what going on with drivers. most
of the components interaction debugging can be done through the trace.
if we need more, we now know the path to timestamps.
Linux / Unix Expert R&D - Eaton - http://www.eaton.com/mgeops
Network UPS Tools (NUT) Project Leader - http://www.networkupstools.org/
Debian Developer - http://www.debian.org
Free Software Developer - http://arnaud.quette.free.fr/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Nut-upsdev