0

I'm trying to gather data of time that a HTTP request take to travel from 1 node to another in a network, here's a simple network topology that I'm working on: I'm using Raspberry Pi 4 model B

     PC ---- RaspPi(1) ---- RaspPi(2) ---- RaspPi(n) ---- ...

Each of these nodes have their own application that can work with HTTP, the idea to gather data is: Suppose I have a HTTP request that has RaspPi(n) as its destination, now once the request traverse through each node, I logged out the TIMESTAMP when it reaches the node, from then I can calculate DeltaT, which is the time it takes for my request to travel between 2 consecutive nodes.

I have tried to use:

Date now = Calendar.getInstance();
TimeStamp ts = new TimeStamp(now.getTime());

And

System.currentTimeMillis()

to get the TIMESTAMP, the problem is, data that I gathered have negative DeltaT, which for example: TIMESTAMP at RaspPi(2) is before TIMESTAMP at RaspPi(1). I've done some searching around and found that the 2 methods I used above are not monotonic (Source 1 and Source 2). So the other method I'm thinking is to use System.nanoTime() but this doesn't seem to work on different JVMs, which is all of my network nodes.

I don't know if there is a better approach to gather these data, or some work around that I can do to fix those methods I used.

Please let me know if I haven't make myself clear. Thanks for reading.

Vishnu CS
  • 748
  • 1
  • 10
  • 24
Nguyen Nam
  • 23
  • 4

1 Answers1

0

For getting the wall-clock time use System.currentTimeInMillis.

System.nanoTime can be pretty much arbitrary and should be used for measuring durations of an operation on the same node/machine. You will get arbitrary results if you try to use it to measure the time difference between two different computers.

In some cases, System.curentTimeInMillis may go backward but I guess you're more likely to observe issues caused by system clocks on those machines being not perfectly synchronized - this is in general challenging and also depends on what time intervals you generally expect to measure (microseconds, milliseconds?).

Check out NTP protocol and how to keep clocks synchronized and take the results you get with a grain of salt. Here's some good info about this topic: https://codeburst.io/why-shouldnt-you-trust-system-clocks-72a82a41df93 - an interesting piece:

According to google, there is a 6ms drift in a clock which is synchronised every 30s

An interesting paper relevant to the topic: Clock Synchronization for One-Way Delay Measurement: A Survey

Juraj Martinka
  • 3,991
  • 2
  • 23
  • 25