Per the notes from ticket CS0030970 we are submitting the following enhancement request to have the clocks synchronized between the dedicated envs and the on-prem systems.
In order to accomplish this we need to be able to point our dedicated ENV at our own NTP server.
| Idea priority | Medium |
By clicking the "Post Comment" or "Submit Idea" button, you are agreeing to the IBM Ideas Portal Terms of Use.
Do not place IBM confidential, company confidential, or personal information into any field.
Thanks. This falls into the support/engineering engagement that Denis mentioned above.
I'll leave this specific request (to use your NTP) in the "Will not implement" status until there's compelling reason to revisit it.
Thank you both for your feedback, however:
We are trying to track the transaction from an on-prem API Connect DataPower into Bluemix Dedicated and the time stamps from APIC analytics are earlier than time stamps in the goRouter logs in the platform. We can discuss more details in a private forum if needed, but without this capability we can't effectively track latency between different hops in the request chain.
Atomic clocks are the reference for all systems relying on NTP. All our data centers use antennas or stratum zero sync sources. The local servers then become sync'ed with a highly available local stratum 1 reference, ensuring minimal drift from the atomic clock reference. When using NTP to synchronize machines, the best practice is to be as near as possible to the reference source to minimize the drift induced by network latency. This is best achieved by configuring the NTP settings to use local stratum 1 servers. Due to the very nature of NTP, synchronizing over WANs will invariably lead to greater time drift on systems between your premise machines and the ones running in the Cloud.
In order to keep all the systems you use at the same time, IBM recommends ensuring the local on-prem source be as close as possible to stratum zero, and keep the ones in the cloud sync'ed to the local reference. That will guarantee you constantly remain with a minimum drift between on-prem systems and the IBM ones.
If we have a specific incident to investigate, my team can definitely be engaged through the regular channels.
See https://en.wikipedia.org/wiki/Network_Time_Protocol for background.
From past discussions on this topic, I believe pointing a dedicated environment back to KP's ntp server going over VPN/Direct Link tunnels makes the situation worse and not better.
Can you please share some data that can help us understand where in your current logs (or other artifacts) you're seeing a difference in timestamps and what problem this is causing to you?