Użytkownik "Andrzej W." napisał w wiadomości
W dniu 2014-11-12 o 23:14, J.F. pisze:
>> 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 ..
>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.

No to policzmy. Zalozmy ze
10 T1
112 T2
114 T3
16 T4

d=4, t=100 OK.

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

10 T1
113 T2
115 T3
16 T4

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.

do góry

W dniu 2014-11-13 o 13:35, Atlantis pisze:
> W dniu 2014-11-13 11:45, Andrzej W. pisze:
>
>> W odpowiedzi od serwera w polu "Originate Timestamp" powinieneś mieć to
>> co wysłałeś w "Transmit Timestamp".
>> Można by też lekceważyć wszystkie odpowiedzi z LI=3.
>> A jak chcesz być poprawny to powinieneś też sprawdzać czy pole Stratum
>> nie jest równe zero i podejmować odpowiednią akcję.
>
> Hmm... Czy w takim razie ta mocno uproszczona funkcja wysyłÍająca
> request może być odpowiedzialna za zachowanie mojego programu? A może
> jednak coś jest nie tak z funkcją odbiorczą? Może autor popełnił błąd i
> zaprogramował odczytywanie pól z niewłaściwym timestampem?
> Jaka pomyłka mogłaby skutkować czasem opóźnionym o kilka-kilkanaście
> sekund po aktualizacji, no chyba, że serwer "zaleje się" requestami?
>


Masz możliwość debugowania?
A może choć jesteś w stanie wysłać coś na port szeregowy?
Zobacz co przychodzi w odpowiedzi z serwera i tyle. Bez żadnej obróbki,
wyślij po prostu te cztery bajty i zobacz co tam jest.

--
AWa.

do góry

W dniu 2014-11-13 14:00, Andrzej W. pisze:

> Masz możliwość debugowania?
> A może choć jesteś w stanie wysłać coś na port szeregowy?

Niestety w tej chwili nie mam takiej możliwości. W projekcie nie
wyprowadziłem UART-a na goldpiny, ponieważ podstawową część programu
miałem już przetestowaną na płytce uruchomieniowej. Wtedy nie myślałem
nawet o dodawaniu do tego projektu dodatkowych funkcji, jak RTC i klient
NTP.

W każdym razie przyjrzałem się bliżej stosowi. Wygląda na to, że
początek pakietu danych odpowiada elementowi 0x2A bufora. Wychodzi więc
na to, że odczytywane w kodzie komórki 0x52..0x55 faktycznie odpowiadają
bajtom 40..43 pakietu UDP. Więc faktycznie jest to część sekundowa
transmit timestamp. Operacja składania ich w jedną zmienną uint32_t
także nie wzbudza moich zastrzeżeń. Tak więc opóźnienie z którym teraz
się zmagam raczej nie pochodzi z tej części programu...

Pewnie nieco rozbuduję procedurę odbiorczą. Przede wszystkim warto
byłoby sprawdzać, czy pakiet faktycznie został przysłany przez nasz
serwer NTP. Poza tym chyba wprowadzę obsługę originate timestamp.

Tylko czy któraś z tych kwestii może powodować takie opóźnienie przy
synchronizacji? Jakoś też nie mogę tutaj doszukać się możliwego
mechanizmu...

do góry

Znalazłem przyczynę. Okazało się, że w pętli głównej zabrakło jednej z
kilku instrukcji warunkowych, które sprawdzają efekt działania funkcji
czytającej dane z ENC28J60 oraz parsujących nagłówki. Skutek tego był
taki, że w pewnych okolicznościach program wykonywał część programu,
której wykonać nie powinien - z bufora były czytane stare dane i po raz
kolejny uruchamiała się funkcja analizująca pakiet NTP. Timestamp sprzed
kilku-kilkunastu sekund powracał jak echo...

do góry