Opera 10.51 kills NTP time synchronization

Opera 10.51 kills NTP time synchronization

When using Opera 10 with NTP time synchronization, frequent resets of system time occur under Windows XP. These “step adjustments” can happen every 15 … 20 min with values in the order of 1 s, always negative (time is repeated, database operators will love that). I have seen values up to 445 s.

This seems to be due to the new Java VM component that speeds up the system clock (!). This behavior has been known from Sun Java, for an overview google for “ForceTimeHighResolution”. For the Sun Java VM there is a switch, XX:+ForceTimeHighResolution, that works or not depending on the version.

The obvious workaround would be to disable Opera’s Java and enable the use of Sun Java. How is that done?

Further information:
AMD Athlon, x86 mode, 2 GB RAM
Motherboard Asus M2N68-VM
Windows XP SP3 fully patched
NTP daemon ntpd 4.2.4p8, NTP Time Server Monitor 1.04
both from Meinberg (www.meinberg.de)

– The problem occurs also with the built-in XP NTP software, with both pre-10 Opera and Firefox, when used with Sun Java without the switch.
– Firefox with ntpd and with Sun Java including the switch shows no time resets, but it is not really perfect as I have seen time variations of 35 ms. Typical would be 2.5 ms.

Pictures:
NTP and Opera10.jpg shows the erratic flow of time; the blue segments are time resets that originate far beyond the bottom border (granularity of logging is 5 min).



NTP before desynch3a.jpg is the situation just before the reset, the “offset” values are what is corrected when stepping the time. The reference clocks are pretty unanimous that the PC had run off into the future.

BTW, it's reported bug # DSK-293670.

Prior to 10.50 Opera interfaced to Java with JNI. From 10.50 Opera uses the NPAPI Java plugin2. One cannot choose between the two modes. So basically it is the switch that doesn't work with Opera 10.50?

Hi Olak,

I learned about the switch for Sun Java only days ago, so I cannot say if it worked before Opera 10.5x. I will append a postscriptum to my bug report below, but my (one) positive experience with Firefox + Java with switch may have come by an coincidence.

I am a bit irritated, you wrote: "Prior to 10.50 Opera interfaced to Java with JNI. From 10.50 Opera uses the NPAPI Java plugin2." I always thought that Opera had built their own Java engine. But I have noticed that on one hand, the plugin search path contains "E:\Programme\Java\jre6\bin\new_plugin", on the other hand there is an Opera file plugin-ignore.ini that adds to several NP*.DLL files the comment "Java plugin, conflicts with Java VM started by Opera". The mime data types are handled from the new_plugin directory. I do not see anything where something like the former JRE is bound in.

Is your statement: "One cannot choose between the two modes" engraved in stone?

Thanks for your prompt answer, anyway.
Ronald




Postscriptum [was attached to the bug report]

Here are some more scenarios what could happen when the clock frequency increases:

– The polling rate of the reference clocks is so large that the NTP clock discipline is able to undo the time shift before it is detected. This may require special parameters in ntpd.conf, like “tinker allan 750”. May be possible if NTP runs undisturbed for some time before Opera is started.

Well, you should not tinker with the parameters of the NTP time discipline. The above value yields increased oscillations, some overshoot and a very slow approximation to zero line.

This observation could render my observation on the combination Firefox plus Sun Java with the “ XX:+ForceTimeHighResolution” switch moot. Thus it is unclear if this switch actually helps Sun Java, of if the equivalent for the Opera Java VM would help Opera. Sorry.

– After desynchronizing, ntpd claims “no servers reachable” (in Windows event log) and is hung.

– After desynchronizing, ntpd shows efforts to connect to time sources, but never synchronizes and is effectively hung.

Note that if hung, ntpd does not update the log files anymore.

Opera has never used its own Java engine, but the interface has changed. The files in plugin-ignore.ini all relate to the previous generation Java plug-in that doesn't work properly with Opera. The old JNI solution also used Sun's JRE.

As for choosing, we have no plans to support both. But this issue, does it only happen when running an applet? Opera doesn't start Java unless an applet is to be run.

Hello Olak,

well, I tried running Opera with no tab open (I did not check if any Java applet was running), and the detrimentous effect on time happened. But then I have no idea what gets started when Opera starts.

You helped me understand why Sun is calling the directory referenced in the plugins path new_plugins. Could it be that their "new" stuff just does not heed the "-XX:+ForceTimeHighResolution" switch? Is the "Java control panel" in Windows, where I thought parameters for the Java Runtime Environment could be set, still applicable, or is it ignored by the "new interface"?

I looked up at Sun: the switch still exists, the control panel should still be in control (even for selecting "next-generation" Java).

So either this has not really to do with Java, and Opera is able to speed the clock on its own. Or it does something Java-like when initializing, just a tiny placeholder process?

And if Firefox 3 uses the "new interface", why does it behave more-or-less well with respect to timekeeping?

Regards, Ronald.

We'll investigate.

Hi Olak,

I am beginning to believe that you have been right all the time -- while I could reproduce the problem with the browser "empty", I checked threads and file handles with Sysinternal's Process Explorer. Ähem, Opera executables and the usual MS networking files and similar threads and no Java. Sorry, I really could have done that before.

Now I have a new observation (well, I suspected this but now saw it). At the end of this test, offset rammed down to about -40 ms, I would have expected a slow return to the zero line. Instead there was quite a fluctuation, and 23' 14" later there came desynchronization and step correction. Something that stays in memory after the parent process ended? Eeek. Or is it only the NTP daemon that got thoroughly whacked.

Somehow like poking with a stick in the mist.
Ronald

This "late effect" is due to NTP: it employs a shift register as a delay line to realize an "exponential filtering" of the time offset samples. I could not find our details, as ntp.org currently has mislaid the documentation and NTP v. 4 never was codified into an RFC. However, if you assume 8 stages and sampling rates from 1 per 64 or 128 or 256 s, delays from the beginning of the time acceleration to the desynchronization of 15 to 30 min seem to be plausible.

This plays the ball back to the Opera program itself. What does it do to the system time?

Workaround: NTPD has an undocumented parameter, -M, "set multimrdia timer to highest resolution". So the NTP Service should be called by

E:\Windows\system32\NTP\bin\ntpd.exe -M -c "E:\Windows\system32\NTP\etc\ntp.conf"

or whatever paths you use.

ClockRes v2.0 - View the system clock resolution
Copyright (C) 2009 Mark Russinovich
SysInternals - www.sysinternals.com
Maximum timer interval: 15.625 ms
Minimum timer interval: 1.000 ms
Current timer interval: 0.977 ms

This works only if NTPD is running, of course. You may have to tinker with the "allan" parameter in the NTP configuration though. Currently I have "allan 300" for a 6 Mb/s DSL line, higher values have been counter-productive.

I am billing this as a workaround as there is no need for Opera to interfere with system time, period.

Ronald

Here's the quick (although first) reply from Opera:

<quote>

Opera does increase the resolution of the multimedia timer using timeBeginPeriod() and timeEndPeriod(), specifically the timer used with the timeGetTime() system call, during periods of high timer activity. When activity settles down, the resolution is set back to the system default. This is done for performance reasons and is not likely to change.
These are officially support API methods, so if a sub component of the OS is misbehaving due to this, it's most likely a problem with that component and/or the BIOS of the system. Hope this clears things up.

Best regards,
Petter Nilsen, Senior Software Engineer

</quote>