Różny czas pomimo synchronizacji z NTP

wiedziala,

Przecież mu się czas już źle liczy lokalnie z timera a co dopiero z ntp.

A propos NTP - czy ktos analizowal jak to dziala i rozumie ?

Bo nie rozumiem jak on sobie radzi z laczami niesymetrycznymi, gdy np pakiet w jedna strone idzie 0.1s, a w druga 2.1s ..

Mimo tych 4 znacznikow czasu 0 - na moj gust to nie ma mozliwosci wykrycia o ile pakiety sa niesymetryczne.

J.

W dniu 2014-11-12 o 23:14, J.F. pisze:

Ja używam w swojej xmedze SMTP, jest banalnie prosty. Używam bez korekcji czasu przelotu i to mi działa bo mam własny serwer NTP na jeden hop, a ponieważ atmelowe RTC i tak jest w stanie tylko liczyć sekundy więc arytmetykę na liczbach 64o bitowych uznałem za zbędną.

Z tego co jest w RFC4330: Timestamp Name ID When Generated ------------------------------------------------------------ Originate Timestamp T1 time request sent by client Receive Timestamp T2 time request received by server Transmit Timestamp T3 time reply sent by server Destination Timestamp T4 time reply received by client

The roundtrip delay d and system clock offset t are defined as:

d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.

Jak dla mnie wzór na t tak pięknie się skraca, że nie ma znaczenia czy opóźnienie jest symetryczne czy nie. Można by to wyprowadzić zakładając, że d=d1+d2 ale przed pierwszą kawą nie chce mi się... :-)

Użytkownik "Andrzej W." napisał w wiadomości W dniu 2014-11-12 o 23:14, J.F. pisze:

No to policzmy. Zalozmy ze

d=4, t=100 OK.

a teraz zalozmy ze pakiet w jedna strone leci 3s, a wraca 1s. Bedzie wiec

d=4, t=101 Offset inny niz za pierwszym razem.

Ale ... zaczynam podejrzewac ze to sam Einstein mi gwarantuje niemoznosc poprawnego wyniku. W koncu moge synchronizowac czas miedzy dwiema rakietami lecącymi w te samą strone z tymi samymi predkosciami. Róznica czasów przelotu zalezy od predkosci, a predkosc od obserwatora. Zas niezaleznie od predkosci obserwatora wynik musi wyjsc ten sam :-)

J.