Keeping Your Clocks Accurate

Electronic clocks control critical functions in many applications. However, clocks are often designed for low cost rather than for keeping accurate time.

Even fairly accurate computer clocks will vary due to manufacturing defects, changes in temperature, electric and magnetic interference, the age of the quartz crystal, or even system load. Even the smallest errors in keeping time can significantly add up over a long period of time. Consider two clocks that are synchronized at the beginning of the year, but one consistently takes an extra 0.04 milliseconds to increment itself by a second. By the end of a year, the two clocks will differ in time by more than 20 minutes. If a clock is off by just 10 parts per million, it will gain or lose almost a second a day.

Synchronization to GPS

The GPS system synchronizes to 24 satellites each with three or four onboard atomic clocks. The US Naval Observatory monitors the satellites clocks and sends control signals to minimize the differences between their atomic clocks and a master atomic clock for accuracy and traceable to national and international standards (known as UTC).

For time synchronizing a clock, the GPS signal is received and distributed by a master clock, time server, or primary reference source to a device, system, or network so the local clocks are synchronized to UTC. Typical accuracies range from better than 500 nanoseconds to 1 millisecond anywhere on earth.

The GPS clock synchronization eliminates the need for manual clock setting (an error-prone process). The benefits of  GPS synchronization are numerous and include: legally validated time stamps, regulatory compliance, secure networking, and operational efficiency.  At the same time you can synchronize all your devices such as

  • Computer clocks (servers and workstations)
  • Network devices (routers, switches, firewalls)
  • Telecommunications networks (PBXs, MUXs, SONET networks, wireless systems)
  • Critical devices and networks (9-1-1 centers, command and control operations, military test ranges, radar systems, time displays)
  • Physical security systems (video, building access controls, networks)
  • IT security systems (cryptography, authentication, encryption)
  • Facility wall clocks

Are Your Application Response Times Lying?

What if the if the response time metrics you relied on only presented part of the performance picture? Analysis tools that claim to provide response time often fail to include application transactions in the calculation of the metrics. In this article, we’ll highlight the two primary ways for calculating response time, the benefits and limitations of each, and why you need both for a complete picture of analysis.

Most monitoring devices track and calculate response time based on traffic occurring at Layer 4 of the OSI model. In this view, the device is typically tracking the three-way handshake between the client and server as an indication that the application conversation will begin. Here, application response time is defined as the total round-trip time it takes for SYN, SYN-ACK, and ACK to be delivered and received.

 

response-a

While the Layer 4 approach provides response times for any application with a known TCP port, it fails to account for whether fulfillment of the application took place as expected by the user. For a more precise representation of application delivery, network analysis solutions need to view Layers 5-7 of the OSI model and have an in-depth knowledge of the specific application. Analysis devices looking at the upper layers are able to monitor for the specific application fulfillment or “Get” requests. [Note: The name of the request varies by application. For example, in SQL this is known as the “Select” request.] Response time calculations then take this request into account.

response-b

 

Understanding when an application’s fulfillment request was received provides a complete view of application delivery and a portrayal of response time in line with actual user experience. For troubleshooting, fulfillment requests (example: Gets) and submissions (example: Posts) can be tracked separately to understand the specific point where application delivery might be failing.

Layers 5-7 intellige1nce provides more detailed information for calculating and investigating response time metrics, but there are also advantages with Layer 4 response time calculations. This matrix presents the benefits and limitations of each:

response-c

Based upon the matrix, the take-away is simple: network teams require monitoring solutions that provide both Layer 4 and Layers 5-7 monitoring and intelligence for a complete picture of application delivery and health.