Time runs slower than real time in Linux VM on Windows 10 host

[FranzS]

Dear Community,

my problem is that I've setuped a new VM for Ubuntu Xenial Xerus (16.04, this issue did not happen with the previous Ubuntu 15.10
The Problem is that the Time inside the VM is running much slower (i assume it's just 10% of the real time).
I've added some syncs to fix the issue as workarround but did not succeeded fix it finally.
I'm running Virtual Box 5.0.20 and installed the Guestadditions.
Attached you'll find my log of Virtualbox, the Vbox File and an excerpt of the syslog.

Thanks for taking a look
/Franz

[socratis]

Duplicate posts are not allowed according to the forum rules.

[mpack]

ISTM this is likely to be a problem with the Ubuntu kernel, i.e. a Linux guests issue. Hence I've deleted the duplicate topic in "Windows Hosts".

@Franzs, I think you should raise your problem on the Ubuntu forums.

[socratis]

I've added some syncs to fix the issue as workaround but did not succeeded fix it finally.

Can you be a little bit more specific? What exactly did you try? From the VBox.log, I see that you've set the following time synchronization related variables. Are these the "workarounds" that you're talking about?

• timesync-interval=1000, default is 10000
• timesync-min-adjust=100, same as the default
• timesync-set-on-restore=1, same as the default
• timesync-set-threshold=1000, default is 1200000

Now, from the log I found these two little gems:

00:00:15.908342 TM: Switching TSC mode from 'Dynamic' to 'RealTscOffset'
...
00:01:58.815357 TM: Switching TSC mode from 'RealTscOffset' to 'Dynamic'

which I don't remember seeing that often. In fact, a quick Google search doesn't show too many results (around 25 in total). One of the results was from the source code (https://www.virtualbox.org/svn/vbox/trunk/src/VBox/VMM/VMMR3/TM.cpp) which has a lengthy explanation about time in VBox, which is way over my head. I''m just putting it here for reference.

I would reset the above tokens and follow mpack's advice.

[FranzS]

Hi socratis & mpack,

first of all sorry for the double post, but as you might have seen I've first posted in the Windows Host section and after finding out that there is a Linux Guest I've posted there (because i thought about it might be a guest issue). Sorry for that. I've forgot to delete the previous post.

According the "Workaround".
Yes, to do the temporary fix I've added

timesync-interval=1000, default is 10000
timesync-min-adjust=100, same as the default
timesync-set-on-restore=1, same as the default
timesync-set-threshold=1000, default is 1200000

Otherwise the drift would get to high. As I've did it without this parameter and I've watched the time in parallel the drift got greater than 3 Minutes and that made me a little nervous.

What socratis, do you mean with

I would reset the above tokens

I shall remove the timesync parameters?

Thanks a lot for the analysis with the TM: Switching TSC mode from X to Y

Another strange thing (and that's probably why i've posted it in Windows Hosts also) is that this issue just happens in one of my two PC's. (One is running Windows 7 as a Notebook and the other one is running Windows 10 as a Notebook).

I've created the VM in my powerful Win7 Notebook and moved it to the less Powerfull Windows 10 Notebook. Is there something to consider?
In addition please find attached the Logfile of the Win7 Host Machine where the issue is not happening.

And one last question due too that this issue is completely new to me. is "time drift" the right phenomenon to describe the Problem? (Time runs much slower than in real) Or is there a different terminus which would fit better?

Created a Thread "16.04: Strange Time Drift in VirtualBox (15.10 Server ok, 16.04 Server -> drifts)" in Ubuntu forums. I hope the supplied Information's are enough

Thanks a lot for doing the analysis and have a great Weekend!

[FranzS]

I've found this:
https://www.virtualbox.org/ticket/15179

If i compare my old VM and my new I'Ve found out that the difference is that the old once did not use paravirt
So it seems to me that paravirtualization could be an issue for my time drift.
Could this be the case?

Could someone explain me where I can see which clock the VirtualBox is measuring?

I would suspect that the root cause is the apparently rather big measurement error for the CPU frequency. VirtualBox measured the clock to be 2.412904761GHz for a CPU rated at 2.40GHz. This is a probable error (don't know the exact clock frequency, it's unlikely to be exactly 2.4GHz) of 0.5%, which will slow down the time perceived by the guest.

FranzS

[socratis]

Your CPU is rated at 2.4 GHz and from your VBox.log:

00:00:03.593407 TM: cTSCTicksPerSecond=2 394 272 373 (0x8eb5b275) enmTSCMode=3 (Dynamic)

or 0.00239222031068 error.

Comparing it with my CPUs rated at 2.3 GHz and from any of mine VBox.log:

00:00:02.123327 TM: cTSCTicksPerSecond=2 299 999 986 (0x891736f2) enmTSCMode=3 (Dynamic)

or 0.00000000608696 error. Much closer. That could explain the drift in your system...

[Perryg]

I have been testing this on a clean install of Ubuntu 16.04 server with default settings and no guest additions. So far the guest has been running for 2 hours and the time matches the host exactly with no drift in either direction. +-0 in fact. I am interested in knowing what the host is doing during the time the drift occurs. Given this is a p8600 ( core 2 duo ) it may be that the host is consuming something that is slowing the guests response time. It may be the CPU freq as well but mine shows 3 299 996 916 for a 3.30GHz processor

Code: Select all

TM: GIP - u64CpuHz=3 299 996 916 (0xc4b1f4f4)  SUPGetCpuHzFromGip => 3 299 996 916
TM: cTSCTicksPerSecond=3 299 996 916 (0xc4b1f4f4) enmTSCMode=3 (Dynamic)

[socratis]

Well, your error is 0.00000093454633. My guess would be mis-identification of the CPU's actual frequency. Here are the errors based on the theoretical and the measured frequencies:

Mine  :       6 * 10-9
Perry :     934 * 10-9
OP's  : 2392220 * 10-9 =  2,3 * 10-3

That's a difference of almost 6 orders of magnitude between my system and the OP's system. I believe that this is way deeper than a workaround and, FranzS, I would suggest that you submit your information at the bug https://www.virtualbox.org/ticket/15179 so that the developers can get a better feeling on what's going on.

[FranzS]

Okay, the Machine showing the correct Time behavior running the same VM has

Code: Select all

00:00:01.387843 TM: cTSCTicksPerSecond=2 594 001 616 (0x9a9d52d0) enmTSCMode=3 (Dynamic)

Rated as 2.6 GHZ

Means:

2.600000000
2.594001616
Errror = 0.005998384

Means:

Code: Select all

socratis:      6 * 10-9
Perry :      934 * 10-9
OP's :   2392220 * 10-9 =  2,3 * 10-3  (Not Working)
Working: 5998384 * 10-9 (Working) 

I did an additional test running it for 2 hours with uninstalled guest additions and KVM enabled.
Inital drift was 4 Seconds, coming back after 2 hours it was still 4 Seconds.

The Problematic Machine has a behavior like after 5 Minutes i have about 2 Minutes drift (Much more extreme)

If i come back to the problematic Machine I'll try to disable ParaVirtualization and keep you posted.

[FranzS]

So,

as promised a short review after trying something new.
After setting Paravirtualization to "none" the Time drift is "gone" (like a poem).

But nevertheless I've found some other strange things:

This error occours if i run the VM in the "problematic VM Host"

Code: Select all

May 17 19:10:26 fortuna kernel: [    0.000000] NR_IRQS:16640 nr_irqs:256 16
May 17 19:10:26 fortuna kernel: [    0.000000] Console: colour VGA+ 80x25
May 17 19:10:26 fortuna kernel: [    0.000000] console [tty0] enabled
May 17 19:10:26 fortuna kernel: [    0.000000] tsc: Fast TSC calibration failed
May 17 19:10:26 fortuna kernel: [    0.000000] tsc: Unable to calibrate against PIT
May 17 19:10:26 fortuna kernel: [    0.000000] tsc: using PMTIMER reference calibration

It looks like this in the Working VM:

Code: Select all

May  9 09:50:30 fortuna kernel: [    0.000000] console [tty0] enabled
May  9 09:50:30 fortuna kernel: [    0.000000] tsc: Detected 2594.000 MHz processor
May  9 09:50:30 fortuna kernel: [    0.062760] Calibrating delay loop (skipped) preset value.. 5188.00 BogoMIPS (lpj=10376000)
May  9 09:50:30 fortuna kernel: [    0.063445] pid_max: default: 32768 minimum: 301