Tag Archives: FAQ
Yes!! Only if you are an Informatica customer who has access to our latest Support videos.
Informatica Global Customer Support is delighted to announce the launch of its Support TV with access to over a hundred videos in HD quality. These self-help videos will help you learn more about the products and troubleshoot issues easily, effectively .
We are always looking for new ways to enable customers to better help themselves and the launch of Support TV is a big step in that endeavor.
Watch, Learn, Resolve. This is our motto. (more…)
Since our messaging products offer ultra-low-latency delivery of messages, we’re often asked how to precisely measure latency in a messaging system. In particular, the question often starts with clock synchronization since that is a tool useful in making latency measurements.
Latency measurements made using a pair of clocks can never be any more accurate than the synchronization error between the clocks. Our customers tend to be interested in measuring latencies under 50 microseconds. A synchronization error of +/- 12 microseconds adds an uncertainty of 48% in such measurements since the offset between the clocks could be up to 24 µs. Most customers would say that thats far too much uncertainty.
The trouble is that synchronizing the system clocks of two servers to within even a few microsecond of each other is very difficult. I don’t know of any way to do it without special-purpose hardware that I’ve discussed before. I’ve built my own inexpensive clock synchronization hardware, but I wouldn’t recommend it for data center use (see video).
There are two ways to make microsecond-resolution latency measurements without fancy hardware. Both rely on the assumption that even if system clocks are not synchronized to within a few microseconds, they’re running at very close to the right speed. That is, clocks might not agree on what time it is now even if they do agree on how long a second is. There is more information on the possible errors in this assumption contained in a companion post. In a nutshell, it’s a very safe assumption for latency measurements of a few hundred microseconds like we’re talking about here.
One way to make precise latency measurements without clock synchronization is to limit them to relative rather than absolute measurements. We see a class of applications that aren’t so much interested in exactly how long it took for a message to arrive. They mostly want to know which messages are stale and which are fresh. That is, they want to know if a given message was delayed relative to others. They might trade aggressively in response to fresh prices while trading more conservatively in response to stale prices.
A simple technique for this is to send a time stamp with every message. The receiver compares the source’s time stamp with its own and notes the difference. The difference in clocks has many components including the clock offset, the minimum transit time between source and receiver, and whatever variable delays have affected this message. The receiver keeps a brief history of differences noting the minimum and average. The depth of history can be controlled by a count of messages as well as the passing of time. By subtracting the minimum difference from the difference for the current message, the receiver gets a non-negative number that’s a precise indicator of the delay experienced by the current message relative to other recent messages. We recommend this approach instead of attempting precise clock synchronization when applications only need relative latency measurements.
Another way to make precise latency measurements without synchronized clocks is to make round-trip measurements rather than one-way measurements. The local clock is read and inserted into the payload of a message. The message is sent to a receiver that echos it back. The time stamp from the echoed message is subtracted from the current clock reading to find the round trip time. Dividing this by two gives a very good approximation of the one-way latency if the two messages sent and received cover similar paths.
We recommend round-trip latency measurements because of their simplicity and because they do not require any clock synchronization at all, let alone precise clock synchronization. 29West provides example code with its products that uses this round-trip latency measurement technique.