2

Here is the issue: SLES 10 SP1 guest is running on HyperV. I need accurate timekeeping on this box, so I have applied these kernel parameters (which were proven to work on other identical SLES 10 SP1 guest) to boot loader configuration:

clock=acpi_pm divider=10

And of course, NTP service is on, time synchronization between hypervisor and guest is off.

After that, time is kept precisely, but I ran into dramatic increase of CPU consumption by the system. As soon as I remove clock=acpi_pm parameter, time drift is back but CPU consumption is normal.

I do need correct time on this box. And I have another box where this value of clock parameter works without any issues.

Does anyone have an idea of how to keep time correct while not impacting CPU that much?

Thank you all.

anenvyguest
  • 21
  • 1

2 Answers2

3

VMware recommends a slightly different set of parameters for SLES 10 SP1:

clock=pmtmr
hpet=disable

I normally run only Windows guests under Hyper-V, so I am not sure whether this is equally relevant to your environment. It is certainly worth a try.

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
  • Thanks! I believe I saw this link and actually tried this parameter. For some reason it didn't work. Tomorrow I'll give another try. – anenvyguest Sep 29 '11 at 17:50
3

Simple: DO NOT VIRTUALIZE.

Virtualization per definition has time skew. High precision software does not work well with virtualization. I have a similar system here (telling me every hour it synced by 36ms) getting a constant 100 packet per second or so data stream to keep it in sync.

Simply did not work under virtualization. Virtualiaztion Hyper-Visors are NOT real time capable at this moment.

Skyhawk
  • 14,149
  • 3
  • 52
  • 95
TomTom
  • 50,857
  • 7
  • 52
  • 134
  • Very good point. An utimate decision may depend on whether "accurate timekeeping" is needed in human terms or in scientific terms. If time needs to be accurate within a second, that's attainable in a properly configured VM (although I'm not sure about Hyper-V). If milliseconds count, going to bare metal would be a good way to conserve hair. – Skyhawk Sep 29 '11 at 15:57
  • Yes. Actually I found that out due to my financial data feed ;) THanks to Nanex client. A second is not good enoug hthere there. Hyper-V was moving back and forth 1-2 seconds - totally ok for most things, but when you need hard timing, sorry, there is no hyper visor optimizd for that. THey ALL skew the clock. – TomTom Sep 29 '11 at 16:30
  • Thanks! The virtualization overhead is not a problem in my case. And in regard to time accuracy - I don't need precision of milliseconds; seconds or even few minutes (say, less than 10) will suffice. However, for me it's vital to have time difference within predictable range from actual time. – anenvyguest Sep 29 '11 at 17:52
  • Which you can not. Point is that time is determined by interrrupts, and there is no guarantee a cleint operating system gets a tim slice within a specific time after interrupt. So the time ALWAYS skews to the back. Always, quite significantly, too. That simple. You need a stable time - DO NOT VIRTUALIZE. – TomTom Sep 29 '11 at 19:02
  • Little late update: Server 2016 on Hyper-V 2016 is accurate to half a millisecond when set up properly. Financial Regulations to the rescue - they demand it. – TomTom Aug 21 '17 at 13:57