Why PMUs miss data center oscillations—and what continuous waveform recording fixes

A new kind of oscillation source

PMUs were designed to track electromechanical dynamics—inter-area and local modes in roughly the 0.1–2 Hz range. AI training loads produce something different. According to PNNL-39191, the iteration cycles of a training job produce slow oscillations, typically 0.1–1 Hz, while faster fluctuations within the compute phases can extend into the sub-synchronous range of 5–59 Hz. The low end can excite inter-area modes; the high end sits on top of generator shaft torsional modes, which Microsoft, OpenAI, and NVIDIA place at around 7 Hz and up.

The critical difference from a fault is persistence. These are forced oscillations from normal operation: they run for as long as the training job does, they may never be large enough to trip a disturbance trigger, and the torsional risk is fatigue accumulated over long periods, not a single event.

What it looks like: one event, two instruments

In October 2024, ERCOT observed power oscillations from a large crypto-mining load. PMU data at 30 frames per second from the point of interconnection showed an oscillation of about 7.5 Hz and 25 MW peak-to-peak. A digital fault recorder at the same site, sampling at 20 samples per cycle, showed the real oscillation was about 23 Hz and 50 MW. The PMU got both the frequency and the amplitude wrong, and nothing in its own data revealed it.

Where PMUs fall short

1. The guaranteed bandwidth is narrow

IEC/IEEE 60255-118-1 validates PMU accuracy through modulation tests that require total vector error within 3% over a defined range. For P-class, that range runs from 0.1 Hz to the lesser of F_s/10 or 2 Hz; for M-class, to the lesser of F_s/5 or 5 Hz. Above about 20 fps for P-class and 25 fps for M-class, raising the reporting rate does not widen the guaranteed range at all.

That is not the same as saying a faster PMU sees nothing new. PNNL's analysis of the standard's M-class filters found a 10 Hz oscillation attenuated by about 40% at 30 fps, about 10% at 60 fps, and almost not at all at 120 fps. But the improvement is filter-specific and unguaranteed, and attenuation at higher frequencies remains significant.

2. Aliasing reports the wrong frequency

A PMU reporting at F_s can only represent oscillations below F_s/2. Anything above that the anti-aliasing filter does not fully remove folds back to f_alias = |f_true − nF_s|. At 30 fps, a 23 Hz oscillation appears at 7 Hz—exactly the ERCOT pattern. Because n is unknown, the true frequency cannot be recovered from PMU data alone. A 7 Hz reading could be 7, 23, 37, or 53 Hz.

3. Filtering hides amplitude even without aliasing

PNNL tested a commercial PMU in hardware. A 27 Hz oscillation was invisible at 30 fps, as Nyquist predicts. At 60 fps, where 27 Hz is below Nyquist, it was still attenuated by 72% in P-class and nearly 100% in M-class. M-class filters, built to reject out-of-band interference, are the worse choice for this job.

4. Compliance looks better than it is

PNNL applied LIPA's proposed 5–55 Hz criterion—a 1-second FFT of active power, two-bin sum averaged over 10 seconds, threshold 3.5 MW—to a synthetic 20 Hz, 4.8 MW oscillation. Computed from waveform data, it exceeded the threshold and was detected. Computed from phasors estimated with the standard's P-class filter at 120 fps, the magnitude converged below 3.5 MW: a clear violation went undetected. At 1 Hz the two methods agreed exactly. (LIPA's criterion requires waveform data; the PMU version was PNNL's illustration of the risk.)

5. You usually cannot correct for it

In principle, a known filter response could be inverted to restore attenuated amplitudes. In practice most vendors' phasor estimation filters are proprietary, and they differ from the reference algorithm in the standard—so operators generally cannot back out the attenuation analytically.

The limits being written, and whether a PMU can check them

PNNL summarizes the oscillation and variability limits utilities and operators have proposed. The right-hand column is our reading of each against the PMU limitations above.

What continuous waveform recording fixes

Continuous point-on-wave (CPOW) recording keeps the raw sampled voltage and current, so the full spectrum is preserved: sub-synchronous content, interharmonics, and fast transients. Both words matter. Resolution defeats aliasing and filter attenuation. Continuity defeats the trigger problem: traditional DFRs record only when triggered, and load oscillations can persist below any normal disturbance threshold.

SEL's PCIC 2025 paper frames continuous waveform streaming and recording as removing the trigger-setting problem entirely, by producing gapless, triggerless data. Its base stream runs at 14.4 kilosamples per second—240 samples per cycle at 60 Hz—giving about 6 kHz of signal bandwidth, far beyond anything a sub-synchronous oscillation needs. (The paper notes that traveling waves and distortion up to 150 kHz need 1 megasample per second with 1 µs time-stamping and 400 kHz of bandwidth; that is a different job.) One of its field examples is telling: triggered power-quality monitoring on a medium-voltage bus ran for 72 hours without capturing one-cycle switching transients that continuous recording caught.

The same waveform stream can also produce PMU-style phasors and power-quality metrics, so one device can feed both the wide-area phasor system and the oscillation analytics.

What CPOW does not replace

• Data volume is the main obstacle. Waveform recorders sample at hundreds to thousands of samples per second per channel. Dominion Energy's pilot streaming 66 substations at 16 samples per cycle generated about 3.9 TB per day, and moving it took hours even over 1 Gbps links. Most utility networks are not built for that.
• PMUs are the installed base. Time-synchronized phasors from many locations are the backbone of wide-area monitoring; waveform data is not available everywhere.
• Below about 2 Hz, PMUs are excellent. Inter-area mode monitoring, angle and frequency tracking, and ROCOF are what they were built for. CPOW adds cost there, not insight.
• The tooling is younger. C37.118 streaming, phasor data concentrators, and operator tools such as oscillation source location are mature for phasors; there is no equivalent end-to-end ecosystem for continuous waveforms yet. IEEE 2664 (STTP) can interleave waveform snapshots into existing phasor streams, which helps, but it is not the same thing.

Both PNNL and SEL describe point-on-wave monitoring as a complement to PMUs, not a replacement.

Three ways to architect it

PNNL lays out three approaches, each a different trade between visibility and infrastructure:

The hybrid model is where PNNL lands. Waveforms are recorded continuously and analyzed at or near the point of measurement—computing instantaneous or half-cycle power, tracking magnitude in configurable frequency bands, and applying persistence logic—so only oscillation frequency, magnitude, and duration travel to the central platform. PNNL also suggests running the same detection logic inside the data center, at the point of interconnection and on internal feeders, so the facility and the utility see compliance the same way and the operator can act through workload management before an oscillation reaches the grid.

Practical guidance

Testing the controls that are supposed to keep these oscillations inside the limits is its own problem—see our note on hardware-in-the-loop testing of AI load smoothing.