Skip to content
English
  • There are no suggestions because the search field is empty.

Late Data Handeling

Late data is data that arrives at the Historian with a timestamp earlier than the most recently stored point — out of chronological order.

Overview

Late data is data that arrives at the Historian with a timestamp earlier than the most recently stored point — out of chronological order. This happens regularly in industrial deployments: a field device has a clock that drifts, a Collector goes offline and buffers data locally, or a store-and-forward replay delivers a backlog of measurements after a network outage.

Timebase accepts and stores late data automatically. The Late Data Tolerance setting gives you control over how far back the Historian will accept late data, and lets you discard small clock-skew duplicates without losing genuine backfill data.

How late data works

Storage and the .late file

When a data point arrives with a timestamp that falls inside a completed hourly block, the Historian cannot write it directly into that block — the block may already be in use by a reader. Instead, the Historian buffers the late point in a temporary .late file alongside the corresponding .data block. During the next maintenance cycle (approximately every minute), the Historian merges all pending .late files back into their .data blocks and deletes the .late files. After merging, the data is available for queries.

You can monitor late data arrival using the Dataset.Writes.Late system tag, which reports the rate of late data ingestion in points per second.

Late Data Tolerance

The Late Data Tolerance setting defines a clock-skew window in milliseconds. Its purpose is to distinguish genuine late data (a backfill) from clock-skew noise (a device whose clock is slightly off and repeatedly sends timestamps a few milliseconds in the past).

Scenario Behaviour
Data arrives with a timestamp within the tolerance window of the most recent stored point Treated as clock-skew or a duplicate. Discarded.
Data arrives with a timestamp beyond the tolerance window (further back in time) Treated as genuine late data. Accepted and stored via the .late buffer.

Example: With Late Data Tolerance set to 100 ms, a point arriving 50 ms before the most recent stored timestamp is discarded as clock noise. A point arriving 5 seconds before the most recent stored timestamp is accepted as a genuine backfill point.

How to configure

In the Historian browser (Dataset Editor)

  1. Navigate to the Historian at http://<historian>:4511.
  2. Open the Datasets view.
  3. Click the edit icon for the dataset you want to configure.
  4. Find the Late Data (ms) field and enter the tolerance in milliseconds.
  5. Save the changes.

The Datasets grid also displays the current Late Data Tolerance for each dataset in the Late Data (ms) column.

Via the REST API

Set ldt (Late Data Tolerance in milliseconds) when creating or updating a dataset:

POST /api/datasets/{datasetId}
Content-Type: application/json

{
"ldt": 100
}

The same field is returned in GET /api/datasets and GET /api/datasets/{datasetId} responses.

Choosing a value

Value When to use
0 (default) All out-of-order data is accepted. Use when data sources have accurate clocks and you want all backfill data stored.
100 (100 ms) A reasonable starting point for sources with minor clock jitter. Discards duplicates within 100 ms without filtering genuine backfills.
Higher values Use for sources with known significant clock drift. Set to the maximum expected clock error for that data source.

Troubleshooting

Symptom Likely cause What to do
Dataset.Writes.Late is non-zero during normal operation with no known outage A data source has a clock that drifts behind and is sending timestamps slightly in the past Check which Collector is sending late data and which data source it is connected to. Set the Late Data Tolerance to slightly above the observed clock drift to discard those duplicates. If the drift is significant, fix the clock on the data source device
Late data is being discarded when it should be accepted — backfill data is missing Late Data Tolerance is set too high and is filtering out genuine late data alongside clock-skew noise Reduce the Late Data Tolerance or set it to 0 to accept all late data. The backfill will be replayed the next time the Collector reconnects
.late files remain on disk for an extended period The Historian maintenance cycle has not merged them yet (runs approximately every minute), or the merge was interrupted by an unexpected shutdown Allow the Historian to run — merges happen automatically. If .late files persist for more than a few minutes with no new data arriving, check the Historian log files for merge errors. The Maintenance.Failure system tag becoming active at the same time confirms a maintenance cycle error
After a store-and-forward replay, the Historian shows Dataset.Writes.Late elevated for a long time A large volume of backfill data is being replayed. This is normal and expected No action required. The elevated rate will return to zero once the backfill is complete. Do not stop the Collector during replay as this may cause data loss from the buffer