# Latency Jitter in PMU Data Flow Through openPDC and openHistorian

**URL:** <http://discussions.gridprotectionalliance.org/t/latency-jitter-in-pmu-data-flow-through-openpdc-and-openhistorian/1462>\
**Category:** openHistorian\
**Created:** [December 12, 2025, 7:27pm UTC](http://discussions.gridprotectionalliance.org/t/latency-jitter-in-pmu-data-flow-through-openpdc-and-openhistorian/1462 "2025-12-12T19:27:12Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![nabin](http://discussions.gridprotectionalliance.org/letter_avatar_proxy/v4/letter/n/d9b06d/32.png) [@nabin](http://discussions.gridprotectionalliance.org/u/nabin)\
**Post date:** [December 12, 2025, 7:27pm UTC](http://discussions.gridprotectionalliance.org/t/latency-jitter-in-pmu-data-flow-through-openpdc-and-openhistorian/1462/1 "2025-12-12T19:27:12Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![StephenCWills](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/stephencwills/32/20_2.png) [@StephenCWills](http://discussions.gridprotectionalliance.org/u/StephenCWills)\
**Post date:** [December 15, 2025, 2:14pm UTC](http://discussions.gridprotectionalliance.org/t/latency-jitter-in-pmu-data-flow-through-openpdc-and-openhistorian/1462/2 "2025-12-15T14:14:55Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![DucatiDan](http://discussions.gridprotectionalliance.org/user_avatar/discussions.gridprotectionalliance.org/ducatidan/32/1603_2.png) [@DucatiDan](http://discussions.gridprotectionalliance.org/u/DucatiDan)\
**Post date:** [December 15, 2025, 9:12pm UTC](http://discussions.gridprotectionalliance.org/t/latency-jitter-in-pmu-data-flow-through-openpdc-and-openhistorian/1462/3 "2025-12-15T21:12:28Z")

</div>

> [@nabin](#):
>
> it calculates the difference between the current system time (_now_)

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