Hey Kjell, 2009/10/21 Kjell Claesson <[email protected]>: > Hi >> >> indeed. >> more generally, I think that the current 2 seconds polling interval >> was well adapted to dumb units, but not that much to smart ones. >> > This is something that been on my mind also. Some high end ups'es > is giving a lot of data on each poll. > >> I have another incomplete reflexion in mind for a long time, linked to: >> - having 2 poll_interval: 1 for OL and 1 for OB, >> - having per driver poll_interval*s* specification (ie in >> upsdrv_info), and #define DEFAULT_POLL_INTERVAL 10 >> - generalizing and optimizing interrupt / trap / alarm handling (btw, >> I've a draft answer on the netnsm-ups thread) and use extrafd. This >> probably means multithreading... >> > > To share my idea. I have been thinking about two types of polls. > Many ups protocol have a status command and a info command. > Now we poll for info and get everything including status. > > That is a lot of data. > Why not do: > > info poll > delay after info poll. > status poll > status poll > status poll > status poll > Then start over again. > > This make less data to read, and a quick response for OB LB. > The drivers and the polling need to be changed. > > Maybe a bad idea, but you are free to pipe it to /dev/null
not a bad idea at all Kjell. but it needs more work on the drivers, and not only on the common core (ie main.c). I'll definitely be thinking about that. cheers, Arnaud -- 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/ _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
