Why Token Based Polling: Reduced Overhead
July 16, 2015 /
0 comments / in
Measurement
/ by Jacob Allred
In my last post I talked about why TOKEN-based polling is the new best way to get your EFM data into CygNet Measurement; it’s now time to start backing up that claim. Let’s start with a simple one…
How does CygNet Measurement help me to reduce the polling overhead of my devices?
Reducing polling overhead: Understanding the difference between DATE-based and INDEX-based devices.
Most users are accustomed to asking devices for data using dates, whether they are relative dates (T-7 to T-1), or absolute dates (1/1/2020 to 1/5/2020). This works just fine for some devices, but not so well for others. The devices that respond well to this type of request are those that simply store their history by time. We’ll refer to these types of devices as “DATE-based” devices. If you look at how a historical record is stored in one of these devices, you would find that each hour of history has its own date/time stamp per record (“1/1/2020 15:00” for example).
Other devices may have extra work to do, as they don’t store history using this method. These types of devices store their history via index number in the RTU’s memory. We’ll refer to these types of devices as “INDEX-based” devices. This means the records aren’t stamped “1/1/2020 15:00” like the DATE-based devices; instead they are stamped “247” or some other number between 0 and 840.
Some common examples of DATE-based devices would be:
- Totalflow (pre- DB2 Enhanced protocol)
- Weatherford KS
Reducing polling overhead: DATE-based requests against INDEX-based devices.
Now that we understand the difference…
When attempting to retrieve history from INDEX-based devices using dates, there can be varying degrees of overhead. In all cases, the polling engine must translate the begin date/time of the request to an index. To achieve this, a message must be sent to the device to ask what its current index is. After the index is received, the polling engine must then figure out how many indexes back the begin date/time is. Once that determination has been made, a request, by index, can be sent to the device. This generally works, but can become complicated when split records are present, as more and more subsequent requests must be made to capture all the history that the users had requested. There are other devices in the wild that have a lot more work to do to respond to DATE-based requests which require re-organizing the internal memory in order to process each message for history. This becomes more difficult as the range of data being requested increases.
Some common examples of INDEX-based devices would be:
How does CygNet Measurement remove this inefficiency?
CygNet Measurement is now capable of utilizing the indexes of these devices within the system. There is no longer a need to pass date parameters into your request, you simply ask for new data and the system figures out what it needs to request. This functionality works just fine for both the DATE-based devices and the INDEX-based devices. There is nothing for the users to configure or mess with, the drivers understand how to communicate with any of the supported remote devices and will automatically handle the request parameters.
It’s really that easy.
Share this entry
