Is it possible to calculate packet transit time without....

[TheExcession]

Is it possible to calculate the packet transit time between a client and server without them having synchronised clocks?


I want to calculate the amount of time it takes for a packet to cross a network in one direction. The packets are UDP, and contain a timestamp indicating the time they were sent.

So consider a Server sends out UDP packets every 100ms, each packet contains a timestamp indicating the server time that it was sent.

Is it possible for a client to determine the latency of the link between itself and the server purel based upon this infomration.

The packets are RTP packets, and there is other stuff in the protocol that encompasses sender and receiver reports, there are also NTP time stamps in the packet too.

So far my maths is only providing relative delay values which are great for calulating jitter, but I'd like to be able to calculate the minimum and maxim latency of the link.

Thoughts?

cheers
Ex

[ThatPhilBrettGuy]

You must know the relative clocks or you'll get nowhere (currently doing that sort of thing at work). With packets doing round trips etc you've obviously got possibilities, but with just a broadcaster you need a reference that both machines can use.

[TheExcession]

Indeed, and here's the crux, I'm not sure you can do it in a uni-directional flow.

Are RTTs are just a case of measuring Client->Server->Client times and dividing by two?

In RTP, there are report packets (RTCP) that contain an NTP timestamp, this can then be mapped to the time stamps in the RTP packets.

But again, unless the Server clock and the Client clock tell exactly the same time then surely it is impossible to accurately calculate the amount of time a packet takes to cross a network?

To me it seems that no matter what information a server were to put into a packet, once it arrives at the client, unless the Client clock is exactly matched to the Server clock there is nothing the Client can calculate.

It's straight forward enough to calculate relative packet delays once you have more then one packet received at the client, you just compare the server timestamps contained within the packet with the receiver time stamps generated every time a packet arrives, compared to the last packet you received

Am I missing something here or is there more that I can do?

cheers
Ex

Edited by TheExcession on Wednesday 18th October 15:28

[dilbert]

You could get a radio clock at each end. If you obtain a timestamp from it when you send and receive, you can work it out that way. It's more accurate, but still flawed. It's just a question of how accurate you want to be. Thats the first question you have to ask yourself. Then you have to work out the best means of achieveing it.

[TheExcession]

dilbert said:

You could get a radio clock at each end. If you obtain a timestamp from it when you send and receive, you can work it out that way. It's more accurate, but still flawed. It's just a question of how accurate you want to be. Thats the first question you have to ask yourself. Then you have to work out the best means of achieveing it.

I think you're right, we are running NTP, and the systems are all lab based, so they're co-located. In theory the machine clocks should be fairly well synchronised. I just wondered if there is any 'other' technology I should be looking into....

Regarding accuracy, the nearest millisecond will do

Edit for typo.

Edited by TheExcession on Wednesday 18th October 15:51

[ThatPhilBrettGuy]

TheExcession said:

Are RTTs are just a case of measuring Client->Server->Client times and dividing by two?

Can be, or if you want to get flash you put a network packet scanner on the far end and measure the packet turn around time in the receiver. Then you'll be thinking about what you're measuring. Packet time from network stack to stack, app layer to app layer?

TheExcession said:

To me it seems that no matter what information a server were to put into a packet, once it arrives at the client, unless the Client clock is exactly matched to the Server clock there is nothing the Client can calculate.

Correct, or the relative clocks anyway.

TheExcession said:

Am I missing something here or is there more that I can do?

Not really no. You have to get the same clock source at each end somehow.

[aldi]

Don't know if NTP is going to be accurate enough, I'm sure I read that the accuracy was in the 10's of ms. range. Isn't there such a thing as power grid synchronised clocks, how accurate are they?

[ThatPhilBrettGuy]

TheExcession said:

...the systems are all lab based, so they're co-located.

If they're on the same network switch, there's another trick I've used in the past. Get a third machine to generate a broadcast packet when the network is very quiet. As each machine receives the packet, start a high res timer. Now send the test packet with the machine A high time value in it...you can work out the rest. Actual time isn't ever needed, just timer ticks.

This does assume a symmetrical network topology from the broadcast to the client machines of course.

[TheExcession]

ThatPhilBrettGuy said:

If they're on the same network switch, there's another trick I've used in the past. Get a third machine to generate a broadcast packet when the network is very quiet. As each machine receives the packet, start a high res timer. Now send the test packet with the machine A high time value in it...you can work out the rest. Actual time isn't ever needed, just timer ticks.

This does assume a symmetrical network topology from the broadcast to the client machines of course.

That's a neat idea, I might look into that. Basically, we are investigating Multicast through an emulated satellite network. There are paths through the network that go between the hosts that are delayed, in that packets enter a satellite ground station simulator and are queued before being put over the air interface. The air interface is emulated and delays the packets for a pretty much (disregarding app scheduling times) period.

Essentially we are looking at the perfomrance of the scheduling algorythms.

Interestingly, each host also has a 'back-door' network connection straight onto a LAN Switch, so you are right, we could broadcast time stamps onto the back LAN to keep every one in time and then look at the transmit/arrival times via the emulated satellite segment.

aldi said:

Don't know if NTP is going to be accurate enough, I'm sure I read that the accuracy was in the 10's of ms. range. Isn't there such a thing as power grid synchronised clocks, how accurate are they?

I think that would be enough for us, when you consider the RTTs via the satellite segment are in the order of 500ms, this should be more than accurate enough.

I'm thinking that NTP between the hosts on the back-lan will be enough to synchronise the clocks to an accuracy sufficient for us to time packets going over the satellite segment.

All good stuff, thanks for your input!

[teamd]

Last place I was at we used a GPS timeserver for syncing the system clocks, we were doing what sounds exactly the same as you including Satsims for simulation of high latency links.

BTW, what do you need to know about IP multicasting?

[guydw]

I would use one of the many network auditing products. Basically you want to create traffic flows between two points, and then measure the latency. You would also want to look at interface stats on network devices to see if packets are being queued, how much etc.