Yeah, that could be useful. But why not just store stuff like this in
RAM? Perfect example is the throughput monitoring statistics on Canopy.
It obviously doesn't persist across reboots. I know you probably don't
have a lot of RAM to work with though.
Let me give you another example pertaining to the SiteMonitor in
particular. If I could have a log of the sync pulse status on a
SyncInjector for the last 15 minutes (or 30 minutes, or an hour).. on a
1 or 2 second interval, I could prove to Cambium that their code is
broken on the 3.6 450 and it is NOT the SyncInjector. I already know
it's not the SyncInjectors, and it's not the SyncPipes either. But I
wouldn't need this stored permanently. In RAM is good enough. I just
can't/don't want to do SNMP polling of the SiteMonitor every second or
two, or five. And 10 seconds is too long, 5 minutes is definitely too long.
But for something such as this, you could send an SNMP trap (I know, I
know) when the 1PPS active value goes to zero, almost instantly. Just sayin.
On 5/18/2015 10:52 PM, Forrest Christian (List Account) wrote:
More applicable to the current design, there's been some requests for
on-device logging of enough data so that certain values would have
historical graphs
