bcdedit /set useplatformclock true >>> don't do this cmd edit yet!

[Bandy]

Some players are editing their registry to solve system clock-related performance and crash issues, see thread: https://steamcommunity.com/app/275850/discussions/0/1643171537291925442/

However, if you go to the source on this (or one of the sources), the cmd edit may resolve the issue for client, BUT the problem likely resides at the HG/NMS game server itself, so many game clients affected.

See the discussion at bottom in link below, a purported MS engineer replied and explained better than the blog owner:
https://www.tweakhound.com/2014/01/30/timer-tweaks-benchmarked/

>>>
You may recall that traditionally Windows OSs function on the assumption / use of a Single Clock Domain for a given server, however with the ability of servers to be physically “scaled” (connected together) to create a larger “multinode” server (IE – 2, 3, 4, 5, 6, 7 or 8 node), we have a problem where each server has it’s own local “clock”. This creates a “multi-clock” domain which in and of itself is not bad, however, the “clocks” are Not synchronized across all nodes (unless Hardware clock synchronization is implemented which is very difficult/involved to implement) therefore there can be clock skew / drift between nodes & processors (other than Node 0) which can lead to thread scheduling and timing issues which at minimum can lead to performance problems in addition to other strange & bizarre behavior (poor network & disk performance, hang conditions, etc. etc. etc.).

The problem is encountered within a multi-clock domain beginning in 2008 R2 when the TSC was re-introduced as the default Clock (as mentioned above) Vs the use of the HPET (or Power Management (ACPI / PMclock)) Clock that prior OS versions used. The TSC is very fast and reliable but in using the TSC as the default Source Clock, the OS assumes a Single clock source. Depending upon which node the RDTSC thread executes, clock synchronization may / can become skewed resulting in thread scheduling problems and issues such as is mentioned above.

This said, to alleviate this potential problem on some older servers and certain multi-node scalable server platforms, “bcdedit /set useplatformclock true” should be implemented to circumvent these potential problems. Note: Even if the default system (platform) clock is HPET, ACPI / PMclock, etc, Windows must be explicitly told to use the Platform Clock else TSC will be used.

I wrote the following Knowledge Base (Retain Tip) article back in 2011 as a result of problems encountered when TSC was re-introduced in 2008 R2. Please note that these issues are not limited to IBM but can impact any vendor, system / server on which a multi-clock domain environment exists

...

From a Desktop / Gaming standpoint, there should be no need to use the useplatformclock tweak within a Desktop / Laptop / Workstation environment unless there are known problems with the system using the TSC that could not be resolved within the vendor’s BIOS/UEFI code (which should be a known and documented issue within the vendor’s support forums, etc.).

In general, TSC is much faster for the OS and Apps to utilize than the other methods which should provide better overall performance by avoiding additional latencies due to additional overhead of the other clock counter methods.

This said, it is possible that depending upon the era of the HW platform (desktop, laptop, workstation, etc) that there may be some stability issues of some systems running Windows (due to HW / FW and OS (TSC) implementations) being within a transitional period of time where a system may have better stability when using a system’s default (or configured platform clock within BIOS/UEFI) which is not the TSC (HPET, ACPI/PM_Timer) so stability is also a performance consideration.

In short, the TSC provides the lowest overhead which can and does translate to lower overhead / latency generally resulting in better performance and therefore the use of the TSC for Windows and later should remain as the default clock source unless known issues or problems are encountered.

[MonopolyMan]

As someone that runs Windows in a VM (thus all my games), using the TSC as a clocksource was something I was intentionally doing for improved latency. It's a shame that this seems to be the only solution right now, but I suppose its better than nothing.