Skip to Main Content
IBM Cloud - Structured Ideas

This portal is to open public enhancement requests against IBM Cloud and its products. To view all of your ideas submitted to IBM, create and manage groups of Ideas, or create an idea explicitly set to be either visible by all (public) or visible only to you and IBM (private), use the IBM Unified Ideas Portal (

Shape the future of IBM!

We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:

Search existing ideas

Start by searching and reviewing ideas and requests to enhance a product or service. Take a look at ideas others have posted, and add a comment, vote, or subscribe to updates on them if they matter to you. If you can't find what you are looking for,

Post your ideas
  1. Post an idea.

  2. Get feedback from the IBM team and other customers to refine your idea.

  3. Follow the idea through the IBM Ideas process.

Specific links you will want to bookmark for future use

Welcome to the IBM Ideas Portal ( - Use this site to find out additional information and details about the IBM Ideas process and statuses.

IBM Unified Ideas Portal ( - Use this site to view all of your ideas, create new ideas for any IBM product, or search for ideas across all of IBM.

IBM Cloud Support Center ( – Use this site for any IBM Cloud defect or support need.

Stack Overflow ( – Use this site for IBM Cloud technical Q&A using the tag "ibm-cloud". - Use this email to suggest enhancements to the Ideas process or request help from IBM for submitting your Ideas.

Status Not under consideration
Created by Guest
Created on May 10, 2018

Synchronize the clocks between our dedicated envs and on-prem systems

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
  • Guest
    May 11, 2018

    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.

  • Guest
    May 11, 2018

    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.

  • Admin
    Denis Ducharme
    May 11, 2018

    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 for background.

  • Guest
    May 10, 2018

    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?