WinLC RTX in VMware: Fix 3.6x PLC Slowdown and Clock Drift

1. Problem Statement: WinLC RTX Clock Drift and Cyclic Slowdown

When SIMATIC WinAC RTX (WinLC RTX) is virtualized inside a VMware Workstation guest, engineers typically observe two correlated symptoms that look identical across host/guest combinations:

• The Windows guest clock drifts to approximately 25% of real time (1:4 ratio), even though the host system clock is correct.
• The PLC OB1 scan time increases by a factor of 3.0–4.0x, producing cycle-time histogram outliers and missed interrupts in the OB82 diagnostic buffer.
• The WinLC RTX console reports a degraded cycle time, while application logic remains functionally correct.

These symptoms are reproducible on Windows 7 hosts running Windows XP SP3 guests and on Windows 10 / Windows 11 hosts running Windows 10 64-bit guests. The slow-down is not caused by STEP 7 application logic; it is the direct consequence of the real-time HAL clock being starved inside the VM and the RTSS scheduler losing its hard-real-time guarantee.

This article documents a complete engineering procedure to identify, isolate, and correct the root cause on WinAC RTX 2009 SP3 through WinAC RTX 2010 SP2 HF7 (using IntervalZero RTX 2014). The same principles apply to the more recent SIMATIC WinAC RTX 2020 environment running on Siemens validated hypervisor images. The full WinAC RTX product family is documented on the Siemens Industry Online Support product page for SIMATIC WinAC RTX.

2. Root Cause Analysis: Why SoftPLC Slows Down in a VM

SIMATIC WinLC RTX is a software PLC whose deterministic behavior depends on the IntervalZero RTX real-time subsystem. RTX transforms Windows into a hard-real-time extension by:

• Adding an RTSS (Real-Time Subsystem) ring at HAL level, with a separate scheduler running at IRQL 31.
• Providing a high-resolution 1 kHz / 10 kHz HAL timer derived directly from the Time-Stamp Counter (TSC) or APIC.
• Reserving one logical processor core for the RTSS scheduler (the "RT-shared" core).
• Granting RTSS processes higher IRQL than any Windows process, DPC, or ISR.

VMware Workstation, by design, emulates a generic PC platform. The HAL timer source is translated to the VMware virtual HPET / virtual TSC, and the hypervisor schedules the guest vCPUs cooperatively with the host. Three mechanisms degrade the real-time clock inside the guest:

The single most important diagnostic metric is the RTX HAL timer resolution. On bare metal a properly configured RTX 2009 reports a 500 µs tick resolution with sub-microsecond jitter; inside an untuned VM it routinely reports 10000–15000 µs (15 ms), which directly explains the 1:4 clock drift.

3. RTX HAL Timer Configuration: The Primary Fix

The RTX HAL timer is controlled by the configuration dialog that lives in the RTX Control Panel. The standard resolution path is:

Programs → IntervalZero RTX (version) → RTX Properties → System tab → Settings button

The values that matter are listed in the table below. Default values assume bare-metal Windows; values under VM-Compatible are the starting point for VMware Workstation and ESXi guests.

Procedure to apply the change:

1. Stop the RTX subsystem: net stop rtkss from an elevated command prompt, or via RTX Control Panel → Stop RTSS.
2. Open RTX Properties and navigate to the System tab.
3. Click Settings and locate HAL timer period.
4. Change from the default 500 µs to 1000 µs for VM environments. For ESXi with hardware-assisted virtualization pass-through, 500 µs is recoverable.
5. Enable Clock Skew Compensation and set guard band to 1000 µs.
6. Click Apply and restart RTSS: net start rtkss.
7. Reboot the guest for the HAL binding to take effect.

After this change, the Windows guest clock should return to within 1–2% of real time, and the WinLC OB1 cycle should improve by 50–70%. The procedure is also documented in the RTX Runtime help file installed with WinAC RTX (see Start → Programs → IntervalZero RTX → Help).

4. VMware Processor and Core Allocation

The second-most-effective change is correct vCPU allocation. The guidance below applies to VMware Workstation 15, 16, and 17. The behaviour of Workstation 17 with WinAC RTX was confirmed on Windows 10 21H2 hosts and Windows 11 22H2 hosts; see the VMware Workstation Pro documentation index for the per-version release notes.

The hardware configuration is in: VM Settings → Hardware → Processors.

Additionally, in the VMware .vmx file, the following parameters materially improve the RTX HAL timer stability:

monitor_control.virtual_rdtsc = "TRUE"
monitor_control.restrict_backdoor = "TRUE"
monitor_control.disable_directexec = "TRUE"
host.TSC.noForceSync = "TRUE"

These settings force the vCPU to use the host hardware TSC instead of the emulated TSC, which is the single largest single-cycle jitter improvement you can make in a Workstation guest. For VMware Workstation 17 specifically, ensure that:

• Virtualize Intel VT-x / AMD-V is set to Automatic (not Disabled).
• Virtualize CPU performance counters is enabled.
• The host has VT-d or AMD-Vi enabled in firmware and the host OS does not have Hyper-V, WSL2, or Credential Guard holding the VT-x lock.

5. Guest OS Tuning for the SoftPLC Environment

Regardless of VMware version, the guest must be configured to minimize the gap between the RTX tick and the wall clock. Apply the following settings inside the Windows XP SP3 (or Windows 7 32-bit) guest:

1. Disable all power management: Control Panel → Power Options → Always On; set Turn off hard disks: Never and System standby: Never.
2. Disable the screen saver and hybrid sleep.
3. Disable Windows Update automatic restart.
4. Set Visual Effects to Best Performance.
5. Disable Superfetch / SysMain and the Windows Search indexer.
6. In System Properties → Advanced → Performance Settings → Advanced, set Processor scheduling: Background services.
7. Disable the following services and set startup type to Disabled: WSearch, SysMain, WSearchIdxP, DiagTrack, wuauserv.

For Windows 10 / 11 guests running on WinAC RTX 2010 SP2 HF7 or later, additional steps are required:

• Disable Core Isolation / Memory Integrity in Windows Security → Device Security (conflicts with RTX driver signing on some platforms).
• Set the RTX service rtkss.exe to High priority in Task Manager → Details → Set priority.
• Exclude C:\Program Files (x86)\SIEMENS and C:\Program Files\IntervalZero from Defender real-time scanning.
• Disable the Connected User Experiences and Telemetry service.

6. Resolving rtx does not support this system platform

The error rtx does not support this system platform is generated by the RTX driver loader when the host reports an unsupported platform descriptor. Inside VMware this is almost always caused by one of three conditions:

1. A single-core / single-vCPU configuration (RTX requires at least two logical processors to dedicate a core to the RTSS).
2. A clock source that RTX cannot enumerate (the emulated HPET does not always present a valid LAPIC register set on older Workstation versions).
3. A mismatch between OSMajorVersion / OSMinorVersion in the guest's System Information and the RTX build's compatibility matrix — most often triggered on Windows 10 1909+ where RTX 2009 was never validated.

Corrective procedure:

1. Power off the VM.
2. VM Settings → Hardware → Processors: set Number of processors = 2, Number of cores per processor = 2 (4 vCPUs total).
3. Add to .vmx: cpuid.1.ecx = "0---------------". This masks the hypervisor-present bit (bit 31 of ECX) that some RTX builds reject as evidence of an unsupported platform.
4. Power on the VM and verify System Information → System Model now reads a generic VMware Virtual Platform (or a generic System Product Name on Workstation 17).
5. Reinstall the RTX subsystem from the original WinAC RTX installation media (e.g. DVD1\Products\RTX) with the VM offline.

If the error persists after this procedure, the host CPU likely lacks the required virtualization extensions. Verify in the host BIOS that VT-x (Intel) or AMD-V (AMD) is enabled and not blocked by Hyper-V, WSL2, or Credential Guard on the host OS. The same condition can be confirmed by running systeminfo in the host command prompt and checking that Hyper-V Requirements → Virtualization Enabled In Firmware: Yes.

7. Memory, Disk I/O, and Virtual Hardware Considerations

A frequently overlooked cause of slowdown is virtual disk I/O contention. RTX processes that perform high-frequency logging (e.g. trace buffers, OPC DA servers, or WinLC's WlcDB.dat block file) will block on disk I/O inside the VM, producing cyclic slowdowns that look like clock drift to the application layer.

Recommendations:

• Allocate all guest RAM as reserved (not dynamic) in .vmx: MemTrimRate = "0" and sched.mem.maxpin = "100".
• Pre-allocate the virtual disk: Hard Disk → Advanced → Allocate all disk space now.
• Use the Independent - Non-persistent disk mode for FAT test cells where image rollback is desired.
• Place the VM swap file on a separate physical spindle or NVMe from the host swap.
• Disable memory compression for Windows 10/11 guests.
• For Windows 10 64-bit guests, run the VMware paravirtualized SCSI adapter (PVSCSI) instead of the default LSI Logic SAS — RTX logs show a 15–25% reduction in worst-case OB1 cycle time on disk-bound workloads.

For the WinLC RTX data block (DB) file, typically C:\Program Files (x86)\Siemens\Automation\WinLC\bin\WlcDB.dat, ensure the host's antivirus is configured to skip real-time scanning of the entire \Siemens and \IntervalZero directory trees. Antivirus-induced file-locking is a frequent cause of intermittent WinLC stop/continue events in virtualized environments.

8. Bare-Metal vs. Virtual Performance Comparison

Field-measured comparison on an Intel Core i7-10700K host (8C/16T, 32 GB RAM, Windows 10 21H2) with WinAC RTX 2010 SP2 HF7 and IntervalZero RTX 2014, OB1 setpoint = 10 ms:

The conclusion is unambiguous: a properly tuned virtual machine is acceptable for engineering, FAT, and operator-training use, but production control should remain on physical hardware or a hypervisor with explicit real-time extensions (e.g. Siemens SIMATIC IPC, Kontron KBox, or IntervalZero RTX-on-ESXi configurations validated by Siemens). The same conclusion is reached in the Siemens Application Note "SIMATIC WinAC RTX on VMware ESXi", which can be requested via Siemens Industry Online Support entry ID 53842833.

9. Verification: Measuring Real-Time Behavior

To confirm that the fix has been applied successfully, use the following checks in order. Do not skip step 4 — it is the only one that exercises the worst-case interrupt path.

1. Open RTX Properties → Performance tab. The Clock Skew field should be < 0.5% (target value: 0.0% ± 0.1%).
2. Run winldiag.exe (shipped with WinAC RTX in \Siemens\Automation\WinLC\tools) and verify the Max ISR latency is < 5 µs and Average ISR latency is < 1 µs.
3. In STEP 7 / TIA Portal, set OB1 to 10 ms and enable the cycle-time histogram in the WinLC diagnostic buffer. Target: average within ± 0.5 ms of setpoint, max < 12 ms.
4. Run a 24-hour soak with a process-value logging OB (e.g. OB35 at 100 ms, OB40 on a hardware interrupt) and confirm no missed interrupts in the OB82 diagnostic buffer.
5. Open the Windows guest Task Manager → Performance → CPU: utilization of the rtkss.exe process should remain below 30% on the dedicated core, and DPCs / Interrupts / System Interrupts combined should not exceed 5% on that core.

If the cycle time histogram shows a long-tail distribution (e.g. one cycle out of 1000 takes 50 ms), the virtual HPET is being preempted by the host. In VMware Workstation this is reduced by:

• Closing any other VMs that are running on the same host.
• Disabling host-side Windows Search, OneDrive sync, and Windows Defender real-time scan.
• Binding the WinLC vCPU to a host core with no other vCPUs scheduled, using the sched.cpu.affinity option in .vmx and the corresponding RTX affinity mask.

10. Production Recommendations and Alternatives

For any environment where WinLC RTX is expected to control real machinery, or where a safety function depends on it, the following guidance applies and supersedes any local field-engineering preference:

• Run WinLC RTX on a Siemens SIMATIC IPC (e.g. IPC227G, IPC427E, IPC647E, or IPC BX-39A) with the certified Siemens image, not in a generic VM. The IPC variants carry the SIMATIC WinAC RTX pre-installed and validated.
• If virtualization is mandatory (e.g. consolidating multiple soft-PLCs on a single industrial server), use VMware ESXi with the validated RTX-on-ESXi profile and request Siemens' Application Note: WinAC RTX on ESXi via Siemens Industry Online Support.
• For OT/IT convergence, prefer IPCs with hypervisor support (e.g. SIMATIC IPC with Hypervisor Extension, e.g. IPC PX-39A).
• Never deploy a VM-hosted WinLC RTX as the primary controller for a SIL-rated safety function. Use a separate fail-safe PLC (S7-1500F, ET 200SP F-CPU, or SIMATIC F-CPU in the WinLC RTX-1500F variant) for the safety path.

Field-engineering note: engineers who insist on running WinLC RTX in a Workstation VM for development convenience should always keep a known-good image of a physical PLC for the moment a real machine must be wired in. The "Ferrari on a ship" analogy is technically accurate — a real-time extension on a non-real-time OS inside a non-real-time hypervisor can be made to function, but it is never as deterministic as the real machine. Treat any VM-resident WinLC RTX result with appropriate engineering caution, especially when qualifying cycle-time-critical I/O.

FAQ