Latency Jitter in PMU Data Flow Through openPDC and openHistorian

GPA Products openHistorian
1

I have a PMU simulator feeding data into openPDC, which in turn publishes the data to openHistorian. A Python client then queries openHistorian every second to retrieve the most recent 2 seconds of PMU data (i.e., from t = now − 2 s to t = now). The overall data flow is:

PMU Simulator → openPDC → openHistorian → Python Client

Each time the Python script runs, it calculates the difference between the current system time (now) and the timestamp of the latest data point returned by openHistorian. Here is the part that confuses me. This difference varies significantly from one iteration to the next. Based on my observations, the “freshness” of the latest available data ranges anywhere from ~134 ms to ~1.443 s.

Given that the PMU simulator is streaming at a fixed rate of 30 frames/second (i.e., one frame every 33.33 ms), I would expect the database always to contain data that is at most a few tens of milliseconds old. So why is the variation so large? What causes some frames to appear in openHistorian with only ~134 ms of delay, while others are delayed by more than 1.4 seconds?

2

It’s difficult to speculate without more information. Can you try looking at the latency statistics in openPDC and openHistorian? These are computed in a similar way to how your Python Client computes “freshness”. This should help you pinpoint or rule out any potential issues with the real-time data stream.

3

Now is the issue (Check Spaceballs for specifics) Where is your PMU simulator getting its Time of Day, where is Python Script getting Time of Day? With Real PMUs getting accurate Time of Day from GPS it is common to see what you are seeing because the Time of Day on the computer drifts quite a bit