The time it takes to travel between 2 linux machines !!

Hi,

I am trying to print the time it takes for a message to flow from one machine to another machine. Both the Machines are Linux Fedora Core 6 and have been configured for the same time zone. Is this "time zone configuration" enough to ensure me a correct amount of time it takes for a message to travel from one machine to another machine interms of microseconds ?

Will the hardware / any other resources have any impact ? What could be the best solution ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru
Loading thread data ...

No.

The best solution would be to think about your problem before you jump to conclusions.

Second best would be to program machine B to send the message right back to A as soon as it's received, then have machine A send the message and measure the time for it to return. Barring the delay in machine B (which is probably insignificant, and which you could measure with some thinking and effort) you'll have 2x the machine -> machine transit time.

--
Tim Wescott
Wescott Design Services
 Click to see the full signature
Reply to
Tim Wescott

Try using the "ping" command.

Reply to
Tom

I am actually processing the messages on either side of the linux machines and performing some classification & updation.

Karthik

Reply to
karthikbalaguru

1 - If you are trying to get the time for the messages to flow, use ping.

2 - If you want to measure the time to process the messages, use timers and capture the time before and after you start processing.

3 - If you want to measure the real-world time for both together, can you send the packet back after processing, process it again, take the time and divide by two so you can use the same timer for both start and stop times.

4 - If you really need to synchronize the timers on both machines, configure them to use ntp, but expecting them to be in synch within a microsecond seems optimistic, although I'm no expert there.

5 - On the other hand, if you're dealing with transit times between computers, milliseconds may be close enough, and ntp may be good enough for that.

Good luck with it, Karthik.

- Tim.

Reply to
tbroberg

If your code has direct register access to the parallel ports on both machines, simply set one of the I/O pins high when your message arrives. Now connect a two-channel oscilloscope to the I/O pins on both machines and measure the time difference.

Assuming you can write directly to the port and you're not going through any kind of intermediate driver, this method will be accurate to within a few ISA clock cycles.

This of course assumes that both machines are in the same room. Otherwise do the mesurement using a timer on the local machine: setup the receiver to echo the message back to the sender and then divide the time by two.

Reply to
Tom

Yes. I am trying to perform by synchronizing the timers on both the machines as stated in point number '4' . NTP looks like a good option. I did try enabling the NTP in Fedora Core. But, I did not find NTP option in Redhat .Later, i got the NTPD installed and the below link was helpful in configuring NTP in RH.

formatting link

Further, it is really answering to my next query w.r.t resolution -

- The time resolution is better than one nanosecond and frequency resolution better than one nanosecond per second.

- The 64-bit timestamps used by NTP consist of a 32-bit seconds part and a 32-bit fractional second part, giving NTP a time scale of 232 seconds (136 years) and a theoretical resolution of 2-32 seconds (0.233 nanoseconds).

Interesting. But, are there any known issues with using NTP ?

Thx in advans, Karthik Balaguru

Reply to
karthikbalaguru

Don't fall into the trap of assuming an equivalence between resolution and accurracy.

NTP is used widely enough that you can assume any major problems with it have been resolved. Checking NetBSD's package vulnerability database reveals only one minor (and fixed) security issue. I also remember hearing about an issue with certain Windows implementations causing excessive network collisions - each machine was set to resynchronise every 20 minutes, on the 20 minutes, although I am not sure how much truth there was in the story.

--
Andrew Smallshaw
andrews@sdf.lonestar.org
Reply to
Andrew Smallshaw

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.