The GRIDlink polls the VTN once a minute and parses the payload into a DR Signal. If the security handshake is successful and the VTN returns a payload that meets Open ADR schema standards within the expected time a successful connection is logged.

Like all Internet connections quality of service is dependant on the Local Area Network, the Internet Service Provider (the backhaul) and the VTN Server load. Anyone which streams a movie on their laptop has seen where the connection isn’t always consistent. If the movie begins to pixelate, you don’t blame the laptop.

Every GRIDlink data logs and time stamps communications performance. For connectivity we log 6 parameters:

  1. QOS (quality of service) is a 10 minute running average of the number of successful signals received out of the 10 requests. If the all of the last 10 polls were successful, a score of 10 would result. If  one poll was unsuccessful then the QOS would be 9 and so on. The GRIDlink would have to miss at least 5 parses in a row before it would be accurate to say the device is Off Line otherwise a number less than 10 is usually attributed to intermittant network issues
  2. Number of missed sequential polls looks at failed parses in the context of how likely it is that the GRIDlink will successfully execute an Event. QOS doesn’t completely answer this question. If the network is particularly troublesome and the maximum time between successful parses is 15 minutes and the DR program has a 24 hour Notification Period then it would not affect the Event. This is because GRIDlink stores the Event Start time and the Event Duration so only needs to successfully parse just once prior to the Event to execute. If the program is Fast DR with 10 minute Notification then there is a possibility of missing the Event should this happen precisely at the time of the Event. All depends on how frequently this happens which is the reason to log this data.
  3. Period in seconds between successful polls should be 60 seconds. This is another indicator of a healthy connection. If the period is greater than 60 seconds this may indicate retries if the VTN is not reponding in the expected time.
  4. GRIDlink Client Fault monitors that the Open ADR Software and other Linux processes are running properly. Should anything internally prevent the GRIDlink from polling the VTN an Alarm with be created.
  5. Reboots are datalogged. Frequent rebooting is an indication of insufficient power to the GRIDlink. Naturally the GRIDlink will lose its connection to the VTN while rebooting.
  6. GRIDview Off Line Events monitors the connection between the GRIDlink and the GRIDview cloud server. The connection is far more robust than the VTN. If there is a low QOS with the VTN at the same time the GRIDlink is Off Line with GRIDview then this is most likely due to a network problem or a power outage.