[EMAIL PROTECTED] wrote:
There is misunderstanding here. The signals are timestamped at the equipement after they are feed in into it. In order to get accurate timestamps (where by accurate I mean time as the signals where seen/generated in USA not as signals were feed in into equipment in Central Europe) we have to introduce small offset on the clocks on the equipment (they must run 150 milliseconds behind the real time) . It is not possible to timestamp signals in USA as the backhauling equipement is not much more than optical fibre cables. Clocks are synchronized from private ntp server. I am not talking about compensating the network latency in NTP protocol itself. Is it more clear now?
I'm still not quite sure what you are describing. Is there an NTP server in the U.S. to which a GPS clock is attached and NTP clients in Central Europe that use this NTP server? If so, NTP itself takes care of removing any network latency from the timestamps so that, in theory, the time on the NTP server in the U.S. is *exactly* the same as the time on the NTP client in Central Europe. This is determined dynamically, depending on the network conditions existing at the time each poll is taken. It is not a perfect calculation in that if the network has a larger delay in one direction than in the other, there will be an error of 1/2 the delay difference. However, if your link is as tightly specified as you imply, there should be little or no error in this calculation. If you instead mean that there is a GPS clock in the U.S. connected directly in some fashion to an NTP server in Central Europe, then, although I have no idea how or why you would do that, the latency of the connection would be specified in the fudge statement for that refclock. -Tom _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
