Troubleshooting Slow PCS 7 Trend Archive Display on OS Servers

PCS 7 OS Server trend archive display performance is governed by the interaction between WinCC Tag Logging segments, the Process Historian (PH) mirror, OS Server/Client topology, and the runtime database layout on disk. When an operator opens a trend picture requesting multiple months of process values, the WinCC runtime must locate, scan, and decompress every segment whose timestamp range intersects the requested interval. Mismatched segment time/size budgets, fragmented archive files, redundant OS pairs that have lost synchronization, antivirus interference, and misconfigured Process Historian mirroring routinely produce 30-second to 10-minute read delays on systems that should respond in 1-3 seconds. This reference covers the architectural causes, the diagnostic path, and the field-proven configuration changes that restore sub-second trend call-up on PCS 7 V6.1 SP1 through V9.1 deployments.

1. PCS 7 OS Server Archive Architecture Overview

The OS Server in a SIMATIC PCS 7 plant runs WinCC Runtime as its process data backend. Two complementary archive trees carry the historical record, both managed by the WinCC Archive Manager service:

• Tag Logging Fast - acquires and archives high-speed process values at sub-second to a few seconds. Typical use: closed-loop control tags, fast machine states, vibration, current, position, valve commands.
• Tag Logging Slow - acquires and archives slower values, typically minute-level. Typical use: temperatures, levels, flow totals, batch parameters, lab values, energy counters.

Each archive is partitioned into a sequence of segments. A segment is a bounded chunk of the on-disk runtime database that WinCC creates when either of two limits is reached first:

• Time period of a single segment (e.g., 1 day, 8 hours, 1 hour)
• Maximum size of a single segment (e.g., 100 MB, 1 GB)

The total archive extent is bounded by two more limits:

• Time period of all segments (e.g., 1 week for fast, 1 year for slow)
• Maximum size of all segments (e.g., 50 GB, 200 GB)

When a query comes in for the trend picture, the WinCC Archive Connector walks every segment whose time range overlaps the requested window, loads the compressed value blocks, decimates them to the on-screen pixel resolution, and hands the result to the HMI picture. The cost of that walk is roughly proportional to:

• Number of segments scanned (depth of archive times curves per picture times concurrent clients)
• Average compressed size of each segment opened
• Number of segments held open by the runtime cache during a single query
• Disk seek time on the OS Server archive drive and its NTFS layout
• CPU cost of decompression plus decimation to display resolution

The default PCS 7 project ships with 100 MB per segment, which is a workable value for small plants but is severely under-sized for any archive with more than ~1,000 tags at sub-second cycles. This default is the single most common source of the slow-trend symptom.

2. Problem Symptoms and Field Observations

The failure mode is consistent across PCS 7 V6.1 SP1, V8.0, V8.1, V8.2, and V9.0 deployments and matches the symptoms reported in the field case:

1. Operator opens a trend picture in WinCC Runtime. The dialog window appears, but the trend curve does not render for 30 seconds to 10 minutes.
2. CPU on the OS Server spikes to a single core at 100% during the wait. Disk activity light on the archive drive is solid for the full duration.
3. Performing Tag Logging Reset via WinCC Explorer (which deletes every segment and recreates the empty archive) immediately restores sub-second display performance.
4. Re-attaching any historical segment (manually or via automatic restore from backup) returns the trend call-up to the slow state.
5. Single-curve, single-day queries remain fast even with the slow state present, which rules out pure network or client issues.
6. Multiple-curve queries and queries spanning more than one week become unusable.
7. On redundant OS Server pairs (Master/Standby), the symptom often appears on one pair while the other responds normally - a strong indicator that the archive drive or local segment layout on the slow pair is the culprit, not the shared project.
8. The speed reset only restores trend display; alarm logs, message archives, and audit trails continue to perform normally because they live in different archive trees.

The single most diagnostic fact in this list is item 3: a Tag Logging Reset returns the system to normal instantly. This proves the runtime, the project, the SQL connection, the network, and the client are all healthy. The slowdown is strictly a property of the data on disk, which makes it a tractable problem.

3. Root Cause Analysis: Why Trend Archive Reads Slow

Seven independent root causes - any combination of which can be in play - explain the symptom. Always check in order from cheapest to most invasive.

3.1 Mismatched segment-time vs. segment-size budgets

If time period of a single segment = 1 day but max size of a single segment = 100 MB, then for high-density archives the size limit will trigger rollover long before 24 hours elapse. WinCC rolls the segment early, creating more total segments for the same retention window. With many more segments on disk, query-time scan overhead grows linearly and can dominate the wait time.

3.2 Fragmentation of compressed value blocks

Each PCS 7 segment stores values in compressed blocks keyed by tag. Over months of operation, deletes triggered by retention rollover leave empty holes in the segment files. The runtime must still scan those holes when resolving a query. Native NTFS fragmentation of the underlying archive folder compounds the seek cost. Six months of operation with the default 100 MB cap and aggressive retention will routinely produce 50%+ NTFS fragmentation on the archive volume.

3.3 Excessive tag count or acquisition cycle

Acquisition cycles of 100 ms or 1 s on thousands of tags produce massive segment density. Even with 2-minute archiving cycle (which is common for slow archives), the compressed blocks per segment grow quickly, and the decompress-and-decimate CPU cost during a long-window query can exceed several seconds per curve. The cost multiplies by the number of curves on the picture.

3.4 OS Server pair desynchronization

On a Master/Standby redundant pair, if the Standby has fallen behind on archive replication, the WinCC client fallback path will issue repeated retries to the lagging partner, multiplying the wait time. The OS Server Event Log will surface Archive synchronization error or Archive replication failed entries if this is active. Replication lag can also be silent if the Archive Synchronization service has stopped.

3.5 Process Historian (PH) routing confusion

When a PH Server is present, operators may expect long-range queries to be served from PH instead of OS. By default, OS Runtime always answers from its own archives for any value whose timestamp falls inside the OS archive retention window. PH is only consulted by WinCC Information Server, by PH Reporting, or by external BI tools via OPC UA HDA. This misconception creates performance expectations that the field implementation cannot meet.

3.6 Antivirus interference (silent)

Windows Defender or any installed antivirus product scanning the ArchiveManager folder in real time will lock segment files during write, blocking WinCC's open-for-append and producing both slow writes and slow reads. This is the most common silent cause after segment-size mismatch. AV exclusions must include both the folder and the CCArchiveManager.exe process.

3.7 Clock skew between OS pair

If the Master and Standby OS Servers drift more than a few seconds apart, PCS 7 refuses to merge their archive segments. The Standby keeps a divergent copy and replication falls behind. NTP drift beyond 5 seconds is sufficient to break the merge and degrade query performance on the lagging partner.

4. Segment Sizing Math: Reconciling Time Period vs. Disk Quota

Before changing any setting, validate the segment budget mathematically. The two segment parameters and the two archive-wide parameters must be self-consistent, and the per-segment size cap must accommodate the actual compressed data density of your archive.

Define:

• n_tags = number of tags configured in the archive
• archive_cycle = archiving cycle in seconds (e.g., 120 s for 2 minutes, 1 s for fast)
• segment_time = configured segment time period (e.g., 86,400 s for 1 day)
• segment_size_max = configured max single segment size (e.g., 100 MB)

Values written per day per tag:

values_per_day = 86400 / archive_cycle

Compressed bytes per day for the archive (assume ~20 bytes per archived value, including timestamp and status, after WinCC runtime compression):

bytes_per_day = n_tags * values_per_day * 20

Number of segments generated per day (capped at 1 if size budget is not exceeded):

segments_per_day = max(1, ceil(bytes_per_day / segment_size_max))

For the field case of n_tags = 500, archive_cycle = 120 s, segment_size_max = 100 MB:

values_per_day = 86400 / 120 = 720
bytes_per_day = 500 * 720 * 20 = 7,200,000 bytes = ~6.87 MB/day

This is well under 100 MB, so segment_time drives rollover: exactly 1 segment per day as configured. Good.

But for n_tags = 500 with archive_cycle = 1 s (which is common for fast archives):

values_per_day = 86400 / 1 = 86,400
bytes_per_day = 500 * 86400 * 20 = 864,000,000 bytes = ~824 MB/day

At 824 MB/day the 100 MB segment_size_max forces 9 segments per day rather than the 1 intended by segment_time = 1 day. That is a 9x overhead in segment count, and the total segments in a 1-week archive is now 63 instead of 7. Multiply across redundant servers, multiple OS pairs, and a year of slow archives, and the segment scan count grows into the thousands.

4.1 Reconciling the user's field configuration

The reported field configuration was:

Self-consistency check:

Fast:  1 week / 1 day per segment =   7 expected segments
       50 GB / 100 MB per segment = 500 allowed segments
       -> Disk budget allows 500 but time only requires 7. Disk budget is not the limiter.

Slow:  1 year / 1 day per segment = 365 expected segments
       50 GB / 100 MB per segment = 500 allowed segments
       -> Disk budget allows 500 but time only requires 365. Disk budget is not the limiter.

The time parameter is the binding constraint in both archives. Therefore the issue is not that the disk budget is over-allocated; it is that the per-segment size cap is too small relative to actual archive density, producing more segments than the time budget predicted. The fix is to raise max size of a single segment so that one segment holds a full day's data even under peak load.

4.2 Decision matrix for segment sizing

5. Archive Database Fragmentation Diagnosis

NTFS-level fragmentation on the archive drive is the second-most-common root cause. Check it before touching WinCC configuration.

5.1 NTFS defragmentation

1. Open Computer Management -> Disk Defragmenter on the OS Server.
2. Analyze the volume hosting the WinCC archive folder (default C:\Program Files (x86)\Siemens\Automation\WinCC\ArchiveManager or a dedicated drive).
3. If fragmentation exceeds 10%, schedule a full defragmentation during a maintenance window. WinCC Runtime should be stopped first.
4. For routine health, exclude the archive folder from real-time antivirus scanning - Windows Defender or any installed AV product must have the archive directory added to its process and file exclusion list.

5.2 WinCC runtime tracing

For deeper insight into which segments are slow on which query, enable WinCC runtime tracing:

1. Open the Windows Registry Editor and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SIEMENS\WINCC\ArchiveManager.
2. Create or modify the TraceLevel DWORD value to 3 (verbose) for diagnosis, then return it to 1 (errors only) after the issue is resolved.
3. Restart the WinCC Runtime service to apply.

Trace output is written to <ArchiveManager folder>\Trace\. Look for repeated entries indicating segment open and close events and decompress latency on the trend query timestamps. Each entry timestamps the segment ID and the elapsed decompression time in milliseconds; a value above 100 ms per segment explains a slow query when many segments are touched.

5.3 Antivirus exclusions

On every OS Server and every OS Client:

Folder exclusion : C:\Program Files (x86)\Siemens\Automation\WinCC\ArchiveManager
Folder exclusion : C:\Program Files (x86)\Siemens\Automation\WinCC\Temp
Process exclusion: CCArchiveManager.exe
Process exclusion: CCProjectMgr.exe

For non-default install paths, substitute your WinCC install root. On Windows Defender, exclusions can be deployed centrally via Group Policy or Intune; on third-party AV use the equivalent centralized rule push.

6. Step-by-Step Diagnostic Procedure

Use this checklist to localize the slow-trend root cause before making any change. Record every measurement in the plant's PCS 7 administration log.

6.1 Baseline measurement

1. From an OS Client, open a single curve trend picture for the past 1 hour. Record the time to first pixel.
2. Open the same picture for the past 1 day. Record.
3. Open for the past 1 week. Record.
4. Open for the past 1 month. Record.
5. Open for the maximum archive range. Record.
6. Repeat on the redundant OS Server pair, then on the third pair if present.

If only one OS pair is slow, the issue is local to that pair's archive drive or its runtime cache. If both pairs are slow at the same query depth, the issue is shared: project configuration, PH, or client-side.

6.2 Tag Logging configuration inspection

1. On the OS Server, open WinCC Explorer.
2. Right-click Tag Logging -> Properties.
3. For each archive (Fast and Slow), open Configuration. Note: time period of all segments, max size of all segments, time period of single segment, max size of single segment.
4. Cross-check using the formulas in Section 4. Identify the binding constraint.
5. Open Tag Logging -> Archives tab and count the configured tags in each archive.
6. Sample five tags and record their Archive Cycle setting to confirm the dominant cycle.

6.3 Segment count check

1. On the OS Server, navigate to the archive folder (typically ...\ArchiveManager\TagLoggingFast and ...\ArchiveManager\TagLoggingSlow).
2. Count the number of segment files. The exact extension varies by PCS 7 version; in V8.x they appear as paired database files, in V9.x as compressed .dat segment blobs.
3. Compare against the expected count from the time budget. If actual count exceeds expected by more than 2x, segment rollover is firing too often.
4. Note the oldest segment file's modification time and confirm it matches the configured archive retention.

6.4 OS pair synchronization check

1. Open Redundancy Control on the OS Server (Start -> SIMATIC -> WinCC -> Redundancy).
2. Verify both partners report Master and Standby consistently with no Error state.
3. In WinCC Explorer, open Redundancy -> Event Log for the past 24 hours. Look for Archive synchronization error or Archive replication failed entries.
4. Confirm both servers' system clocks are within 1 second via NTP - large clock skew breaks archive replication.
5. Confirm the CCArchiveManager and Redundancy Windows services are both Running on the Standby partner.

6.5 PH routing check

1. If a Process Historian is deployed, open the PH Console (Start -> SIMATIC -> PH -> PH Console).
2. Verify the OS Server is registered and shows Connected with current timestamps.
3. Verify the PH database is receiving the same tags via its own Storage Settings - by default PH stores at a coarser compression cycle (typically 1 minute minimum, 15 minute average).
4. Verify PH redundancy if a redundant PH pair is present: both PH partners should show Online and the same tag count.

6.6 Perfmon counter capture

During any slow query, capture the following Performance Monitor counters on the OS Server for offline analysis:

\LogicalDisk(*)\Avg. Disk sec/Read          (target: < 5 ms sustained, < 20 ms peak)
\LogicalDisk(*)\Avg. Disk sec/Write         (target: < 5 ms sustained)
\LogicalDisk(*)\Disk Reads/sec               (sanity: high during scan)
\LogicalDisk(*)\Avg. Disk Queue Length       (target: < 2 sustained)
\Processor(*)\% Processor Time              (target: < 80% sustained)
\Memory\Available MBytes                    (target: > 4 GB free)
\Process(CCArchiveManager)\Working Set       (sanity: should match archive cache config)
\Process(CCArchiveManager)\% Processor Time  (locates the bottleneck)

Save as a Perfmon data collector set on a 5-second sample interval. Trigger the slow query, capture 5 minutes, stop, and review.

7. Resolving the Slow Trend Archive: Configuration Changes

7.1 Right-size segment parameters

Target one full day's worth of compressed data per segment for the typical archive density. Use the formula from Section 4 to compute the required max size of a single segment:

segment_size_target = ceil(bytes_per_day * 1.25 / 1 MiB) MiB

The 1.25 multiplier adds 25% headroom for spikes. For the field case of 500 tags at 1 s cycle, that target is roughly 1,030 MB; round up to 1,100 MB or 1,200 MB per segment.

Apply in WinCC Explorer:

1. Right-click Tag Logging -> Properties.
2. Select the archive (Fast or Slow).
3. Open Configuration.
4. Set Time period of a single segment = 1 day (or your chosen rollover unit).
5. Set Max size of a single segment = the computed target (in MB or GB).
6. Click Apply. Note: existing segments are not retroactively merged; the new setting applies to segments created after the next rollover.

7.2 Reset Tag Logging safely

If the existing segments are already fragmented beyond recovery, reset and rebuild. The reset is destructive - back up first.

1. Stop WinCC Runtime on the OS Server.
2. Back up the entire ArchiveManager folder to a safe location. A scheduled robocopy task into a dated folder before each reset is a good discipline.
3. Open WinCC Explorer -> Tag Logging -> right-click archive -> Reset. Confirm.
4. Restart WinCC Runtime. New segments will be created with the corrected size cap.
5. Optionally, manually restore the most recent N days of historical segments from backup into the new archive folder if your process requires continuous history.

7.3 Defragment and exclude from antivirus

Already covered in Sections 5.1 and 5.3. Carry this out while Runtime is stopped, before the next restart that creates fresh segments.

7.4 Reduce tag acquisition and archive cycles

If the project permits, raise archive cycle for non-critical tags from 1 s to 2 s or 5 s. In PCS 7 this is done in the CFC/SFC chart's block I/O or in the WinCC tag properties:

1. Open WinCC Explorer -> Tag Management.
2. Locate the tag, open Properties.
3. Adjust Archive Cycle on the Logging tab.
4. Repeat as needed; group tags via tag groups where possible to apply changes in bulk.

A common field-proven rule: archive at the fastest cycle that production actually requires. Sub-second archive cycles should be reserved for safety-relevant or motion-control tags only.

7.5 OS pair reconciliation

For redundant pairs whose replication has drifted:

1. Synchronize clocks via NTP; force an NTP sync on both servers (w32tm /resync /force).
2. Verify the Archive Synchronization service is running on the Standby partner.
3. From the Master, force a full archive re-sync via WinCC Explorer -> Redundancy -> Force Archive Sync.
4. Confirm replication completes within the configured window (default 30 minutes for a 24-hour archive).

8. Process Historian Integration and Query Routing

Process Historian (PH) is the long-term archive of record in PCS 7 V8.0 and later. Its role in slow trend display is frequently misunderstood and that misunderstanding itself causes slow trends when expectations are mis-set.

8.1 What PH serves

PH stores compressed historical data received from each OS Server. It is the data source for:

• WinCC Information Server reports
• Process Historian Reporting
• Long-term compliance storage beyond OS retention
• External BI tools via OPC UA HDA or the PH REST API

PH is not queried by WinCC Runtime trend pictures. The OS Runtime always answers from its own Tag Logging archives for any time inside its retention window. Information Server and PH Reporting are separate applications that consume PH data directly.

8.2 Implication for slow trends

If OS Runtime must serve the entire query from OS local archives, then OS local archive sizing is the single most important parameter for trend performance. PH does not relieve the OS of this load. Plants that expect long-range queries to be served by PH must use Information Server instead of the OS Runtime trend control.

8.3 Recommended PH sizing for OS offload

For plants where compliance retention exceeds OS capability, size PH storage so that historical queries spanning more than OS retention are answered by Information Server or PH Reporting instead of by OS Runtime:

8.4 PH redundancy

If a redundant PH pair is deployed (Master/Standby), confirm via the PH Console that both partners show Online and that PH replication lag is below 60 seconds. PH lag does not directly slow OS Runtime trends, but it delays any operator who switches to Information Server for long-range queries.

Reference: Siemens Industry Online Support - PCS 7 documentation portal.

9. OS Server, Client, and Redundancy Tuning

9.1 OS Server hardware

The OS Server archive drive should be on a dedicated physical or logical disk separate from the WinCC project and the OS images. For PCS 7 V8.x and V9.x, Siemens recommends:

• RAID 1 or RAID 10 for the archive volume (RAID 5 is acceptable but slower for the random read pattern of archive scans).
• Spindle count at least 4 for archive volume, or SSD/NVMe equivalent with at least 100,000 IOPS sustained.
• Disk I/O latency under 5 ms sustained on the archive volume.
• 64 GB RAM minimum for an OS Server with 50,000 tags; 128 GB for 100,000+ tags.

9.2 OS Server memory and archive cache

WinCC Runtime caches recently-opened segments in process memory. Default cache size is auto-tuned but can be inspected via the CCArchiveManager diagnostic page in WinCC Explorer. For archives exceeding 100 GB on disk, raise the cache ceiling via the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\SIEMENS\WINCC\ArchiveManager\MaxCacheMB to 8,192 (8 GB). Restart the runtime service to apply.

9.3 OS Client tuning

Clients often get blamed for slow trends when the actual OS Server response is fast. Verify on the client:

1. Anti-virus exclusions include the WinCC Runtime cache and temp folders.
2. Power plan is set to High Performance in Windows Power Options.
3. Trend picture Update cycle is at least 1 s; sub-second updates force pixel-buffer recompute each tick and can mask server-side slowness.
4. Trend picture Time Range Factor is set to 1x day by default; raise to 1x week or 1x month only when needed.
5. Client memory at least 16 GB; below 8 GB the picture cache will disk-swap during long queries.

9.4 Redundant OS pair

On the redundant pair, ensure:

1. Both servers have identical Tag Logging configuration files. Drift between Master and Standby will cause the runtime to fall back to the lagging partner's slower path.
2. The Archive Synchronization service is running and shows Synchronized in the Redundancy Control applet.
3. Network bandwidth between the pair is at least 1 Gbps sustained. Archive replication will saturate a 100 Mbps link during peak changes.
4. Time synchronization via NTP keeps both within 1 second of each other. PCS 7 will refuse archive replication if the skew exceeds a few seconds.
5. Both partners use the same WinCC/PCS 7 service pack and hotfix level. Mismatched binaries break the segment merge.

9.5 WinCC/PCS 7 Journal Configuration

The Journal Configuration tool (Start -> SIMATIC -> WinCC -> Tools -> Journal Configuration) records every event on the OS Server. Use it to localize the slow query:

1. Open Journal Configuration and select the OS Server in question.
2. Filter by Archive and Trend operations for the time of the slow query.
3. Look for entries showing the requested time range, segment list opened, and decompress duration.
4. Compare to the same operation on the redundant partner. The partner showing the longer decompress duration is the local culprit.

Reference: SIMATIC PCS 7 V9.0 OS Configuration manual.

10. Performance Verification After Service

After applying the configuration changes, repeat the baseline measurements from Section 6.1:

1. Re-measure the 1 hour, 1 day, 1 week, 1 month, and maximum-range queries.
2. Target: sub-3-second response for any single-curve query inside OS retention, regardless of range.
3. For multi-curve queries, target sub-5-second response for 10 or fewer curves, sub-15-second for 50 or fewer.
4. Capture Performance Monitor counters on the OS Server during the test (see Section 6.6).
5. If any counter exceeds thresholds (disk read latency > 20 ms, CPU > 80% sustained, available memory < 4 GB), escalate to hardware refresh.
6. Verify the segment count in the archive folder matches the expected count from the time budget within plus or minus two segments.
7. Confirm AV exclusions are active on every OS Server and OS Client (defender exclusionlist verified via PowerShell: Get-MpPreference | Select-Object -ExpandProperty ExclusionPath).

Document the new segment parameters, the measured response times, and the date. Store the document in the plant's PCS 7 administration folder so the next engineer sees the working baseline. Tag the document as PCS 7 OS Server Trend Archive Performance Baseline and link it from the CMMS work order.

11. Field-Proven Caveats and Common Pitfalls

The following items are observed repeatedly during PCS 7 commissioning and retrofits:

1. Default segment size of 100 MB is too small for any archive with more than about 1,000 tags at sub-second cycles. Always recompute using Section 4 formula before commissioning.
2. Anti-virus on the archive drive is the silent killer. Windows Defender's real-time scan locks segment files during write, which both kills write performance and triggers runtime errors. Exclude the entire ArchiveManager tree on every OS Server and Client.
3. Multiple OS Clients sharing one trend with very long time ranges will collectively slow each other - the runtime cache holds segments open for the longest-active client. Use shared cache servers or Information Server for read-heavy long-range queries.
4. WinCC Runtime version drift between OS Servers in a redundant pair causes archive replication to refuse to merge, silently degrading one partner over time. Patch both servers with the same WinCC/PCS 7 update.
5. Clock skew beyond 5 seconds breaks archive replication. Always run NTP and verify in Redundancy Control.
6. Tag Logging Reset is destructive. It deletes every segment. Always back up the ArchiveManager folder before reset; better yet, script the backup in SIMATIC PCS 7 Maintenance Station or a Windows scheduled task.
7. Process Historian cannot rescue a misconfigured OS archive. PH and OS Runtime serve disjoint clients; PH does not answer runtime trend pictures. Operator expectations must be set accordingly, or Information Server deployed for long-range queries.
8. Segment rollover at midnight can coincide with batch reports and shift reports, amplifying load. Stagger segment boundaries by changing segment_time to begin at 06:00 instead of midnight via a scheduled restart of the Archive Manager.
9. Trend picture with too many curves (more than 20) on a long range compounds per-curve decompress cost. Split the picture into multiple smaller pictures or use a tabbed layout.
10. Windows page file on the archive drive slows archive I/O. Always move the page file to a dedicated OS volume, never on the archive drive.
11. Sleep and hibernate on the OS Client breaks the trend picture cache and forces a full reload on wake. Disable both via Group Policy for OS Client computers.
12. Backup software scanning the archive folder during peak hours locks segments. Schedule backups for low-traffic windows and configure the backup tool to use Volume Shadow Copy.

Apply the segment sizing math first, defragment second, reset only as a last resort. Most slow-trend calls clear within one day of segment rollover under the corrected settings, with no operator-visible interruption.

12. Frequently Asked Questions