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 /Kjell _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
