High Resolution Time Stamp Facility
A library of functions that can be used to measure activities of less than one second's duration using highly accurate time stamps that can be converted to dates and times of day.
Date Posted: April 19, 2002
|
|
 |
|
|
|
The time-of-day clock is only read once, when the first application using IBM High Resolution Time Stamp Facility loads the ibmts.dll. Thereafter, we adjust this base time by adding a duration whenever we are avoiding wrap conditions. So, the only time we will "resynchronize" with the time-of-day clock is when all applications using IBM High Resolution Time Stamp Facility have been shut down and a new application causes the ibmts.dll to be loaded. The advantage is that IBM High Resolution Time Stamp Facility won't generate negative durations or large durations because the time-of-day clock has been adjusted. Stated differently, IBM High Resolution Time Stamp Facility will report consistent time stamps throughout the period of time when at least one application is using it; this allows for time-based correlation of events/activities.
| | |
|
The wrap condition occurs when the performance timers reach their maximum value and are reset to 0. In the case of timeGetTime (for Win9x systems or WinNT/2000 systems running on hardware on which the multimedia timers aren't supported), this is a long time (more than 59 days). However, when using the multimedia timers, the QueryPerformanceFrequency returns the number of ticks per second that the hardware timer is using. In some cases, this yields a relatively long period of time before a wrap (on my system, it was about 29 days). We did encounter systems, however, that would wrap in just under eight hours. So, we take the value returned from QueryPerformanceFrequency and divide the maximum value of ticks we could get from QueryPerformanceCounter by this number to get the number of seconds before a wrap can occur. Then, to ensure we have a reasonable period of time in which to catch the wrap condition, we divide this by two. Any request for a time stamp occurring in the latter half of this wrap period will initiate the wrap-handling code, which will shift our base values forward in time to avoid a wrap.
| | |
|
Yes. If an application is started that expects to use the IBM High Resolution Time Stamp Facility (IBMTS) library, but never makes a call (and no other applications that have accessed the IBMTS library make calls) to the IBMTS library within the second half of the wrap period, then we won't know that the bases should be shifted forward in time. The goal of IBMTS is not to measure events that occur many hours or days apart (you can use time() or lower resolution APIs for these measurements). However, as long as someone does make a call to IBMTS once every half-wrap period, it will handle wrap conditions and yield meaningful, accurate results. In our work, we have employed IBMTS in a Layered Service Provider (LSP), which will make a call every time a Winsock API is called by some application. Furthermore, we have an agent that is interested in interpreting the events being generated by the LSP, and it has a timer thread used to perform both housekeeping and timeouts on inactive sockets, etc. Since this timer thread runs every second, we are guaranteed the IBMTS library will handle wrap conditions. The shortest wrap period we've seen is 7.9 hours, so, when used on these systems, we'd need to ensure at least one call to IBMTS is made every 3.95 hours.
If you anticipate using IBMTS sparingly and want to ensure that something is exercising the API periodically to handle wrap conditions, please install the ibmtssvc service included in the ibmts\service directory. This service will spend most of its time sleeping, but it will periodically awake to call IBMTS and ensure that the wrap management logic is performed.
An example of a situation in which you might consider using this service would be if IBMTS were used to provide high resolution time stamps in tracing or logging facilities that are typically not turned on. If the customer elects to enable the logging facilities for a while, then stops them, and, days later, re-starts them, and if the ibmts.dll has remained loaded by the application for this entire period, then the ibmtssvc.exe service would have handled wrap conditions while the logging application was dormant.
| | |
|
We found that it was useful to correlate measurements made in Java applications with measurements made in C/C++ applications. The latter can use the Win32 getProcessID() and getThreadID() methods to glean the process and thread where they are running. However, the Java APIs don't return the same information, so we added these APIs to enable correlation. For example, consider a Java application using the URL class to retrieve information. If you've "instrumented" the Java application using IBMTSLINK, and you've also "instrumented" the Winsock layer, you can determine which Winsock calls are being performed by which thread in your Java application using the Process and Thread ID information.
| |
|
|
|
|
| |
