eHealth VM system resides on a ESX host, poller hangs, when errors "Decrementing high performance clock samples detected" seen in system.log
eHealth 6.1, 6.2 and 6.3.0.x versions
Windows VM System on a VMware ESX/ESXi HOST
When a system has processors that have timestamp counters which are not all synchronized, the host operating system may move a virtual machine between two processors on which the timestamp counters are out of sync. This can cause the virtual machine clock to perform unpredictably. The clock may run too quickly or too slowly, or may even stop at times.
By default, eHealth poller bases ping latency calculations on a high-resolution Windows system clock. Above situation will cause the ping send and receive time stamps to appear to go backwards (by only a few dozen nano-seconds). When this situation is detected, the ping code drops back to use the standard clock. The bug arose because the receive time stamp used the High Performance clock while the send time stamp used the standard clock. This could result in an enormous negative delta error which resulted in time out values to never be reached, and eventually leading to poller hung.
Add the environment variable NH_USE_LOW_RES_CLOCK, set its value to "YES", and then restart system.
This will base ping latency calculations on a a low-resolution Windows system clock, on a millisecond level.
For instructions of how to set environment variable, please refer to How to Set or Change eHealth Environment Variables-NT
For more detailed information of Timekeeping with VMware environment, please refer to http://www.vmware.com/pdf/vmware_timekeeping.pdf
This issue is already fixed on eHealth 6.3.1.x or above versions