How to measure one-way latency?

Viewed 736

I wanna measure the time the troughput takes from my client to my server. Currently i can only measure the full trip (from client to server and back to client) i can do this by measuring the time before we send a packet and measuring it after we receive it back from the server. Technically speaking, if i were to devide the full trip time i would get an avarage of each one-way throughput.

But what if some throughput actually took longer to arrive like this:

enter image description here

In the image i created the throughput from client to server is 30 ms and from server to client 90 ms. If the data would have such arrival rates then measuring the full round trip and dividing it by 2 would not give an accurate one-way arrival time. How can i accurately measure one-way arrival times?

2 Answers

How can i accurately measure one-way arrival times

TL;DR - YOU CAN'T

This is actually a very deep philosophical question that is unanswered at the very core of physics (the rock bottom "metal" of the universe). Physics does not unequivocally know the one-way speed of light, only the two-way speed. No experiment we have so far devised can answer that question. See The One-Way Speed of Light.

Although the average speed over a two-way path can be measured, the one-way speed in one direction or the other is undefined (and not simply unknown), unless one can define what is "the same time" in two different locations. To measure the time that the light has taken to travel from one place to another it is necessary to know the start and finish times as measured on the same time scale. This requires either two synchronized clocks, one at the start and one at the finish, or some means of sending a signal instantaneously from the start to the finish. No instantaneous means of transmitting information is known. Thus the measured value of the average one-way speed is dependent on the method used to synchronize the start and finish clocks. This is a matter of convention.

You can get arbitrarily close for non-relativistic situations by synchronizing clocks, but how do you know the clocks stay synchronized? For your case you'd have to agree to synchronize on the same time signal, but propagation delays can introduce tens to hundreds of milliseconds of delay and jitter.

So if you want to pin down one-way times to an accuracy less than clock jitter you're out of luck. Here's the output from ntpq peer on one of my Linux systems.

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*unifi.versadns. 71.66.197.233    2 u  289 1024  377    2.298   -0.897   0.747
+eterna.binary.n 68.97.68.79      2 u  615 1024  377   42.258   -3.640   0.430
+homemail.org    139.78.97.128    2 u  160 1024  377   45.257   -0.209   0.391
-time.skylineser 130.207.244.240  2 u  418 1024  103   24.829    2.066   1.376

You might be able to pin down one-way time to within 5ms if both systems use the same master clock for synchronization and have had enough time for delay and jitter to stabilize.

OWAMP - owping you need to have client and server running, use NTP or chrony to Synchronize time. There are expensive hardware to sync time between machines as well.

Related