eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaRóżny czas pomimo synchronizacji z NTP
Ilość wypowiedzi w tym wątku: 54

  • 41. Data: 2014-11-13 00:12:04
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    W dniu 2014-11-13 00:02, Grzegorz Niemirowski pisze:

    > Takie fluktuacje nie powinny mieć miejsca, częstotliwość nie może pływać
    > z odchyleniem 10%. Może coś nie tak z sygnałem zegarowym? Używasz

    Dziesięć procent? Nie mówimy o dziesięciu procentach.
    Częstotliwość zegara w moim urządzeniu wynosi 12 500 000 Hz.
    Częstotliwościomierz pokazuje tylko siedem cyfr, fluktuowały dwie
    ostatnie. Mówimy o zmianach rzędu kilkuset Hz przy częstotliwości 12,5
    MHz. Przy czym jak mówiłem - podejrzewam, że to wina miernika.


    > wewnętrznego generatora RC czy kwarca? Wymieniałeś kwarc? Swoją drogą
    > dobrze poszukać kwarcu, który będzie miał częstotliwość dającą się
    > odpowiednio podzielić. Dlatego w handlu są kwarce o częstotliwościach w
    > rodzaju 3,6864 MHz.

    Używam sygnału zegarowego udostępnianego przez kontroler Ethernetu
    ENC28J60. On sam jest taktowany kwarcem 25 MHz, na wyjściu zegarowym
    udostępniając 12,5 MHz.


    > Może trzeba by skopiować projekt i w tej kopii powoli wywalać kolejne
    > rzeczy aż zostanie sam timer? Bo może coś przeszkadza, jakieś inne
    > przerwanie.

    Nie ma żadnych innych przerwań. Projekt wykorzystuje jeszcze Timer1, ale
    w trybie licznika zewnętrznych impulsów, a wiec nie zgłasza on przerwań.
    Program nie wykorzystuje nawet UART-a...


  • 42. Data: 2014-11-13 00:19:24
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: "Grzegorz Niemirowski" <g...@p...onet.pl>

    Atlantis <m...@w...pl> napisał(a):
    > Dziesięć procent? Nie mówimy o dziesięciu procentach.
    > Częstotliwość zegara w moim urządzeniu wynosi 12 500 000 Hz.
    > Częstotliwościomierz pokazuje tylko siedem cyfr, fluktuowały dwie
    > ostatnie. Mówimy o zmianach rzędu kilkuset Hz przy częstotliwości 12,5
    > MHz. Przy czym jak mówiłem - podejrzewam, że to wina miernika.

    Miałem na myśli pomiar machania pinem. Przez fluktuację rozumiem zmieniający
    się odczyt. Chodzi o jakieś miganie niezwiązane z tym konkretnym pomiarem?

    --
    Grzegorz Niemirowski
    http://www.grzegorz.net/
    OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
    Uptime: 44 days, 5 hours, 24 minutes and 46 seconds


  • 43. Data: 2014-11-13 01:12:44
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Marek <f...@f...com>

    On Wed, 12 Nov 2014 23:57:27 +0100, Atlantis <m...@w...pl>
    wrote:
    > Tylko taka niedokładność nie spowoduje 80 sekund opóźnienia po
    godzinie
    > i 10 minutach pracy...

    Dokładnie 80 czy 86.4?

    --
    Marek


  • 44. Data: 2014-11-13 07:15:21
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: "Andrzej W." <a...@w...pl>

    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 ..
    >
    > Mimo tych 4 znacznikow czasu 0 - na moj gust to nie ma mozliwosci
    > wykrycia o ile pakiety sa niesymetryczne.
    >
    > J.
    >

    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ę... :-)

    --
    AWa.


  • 45. Data: 2014-11-13 08:55:58
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    W dniu 2014-11-13 01:12, Marek pisze:

    > Dokładnie 80 czy 86.4?

    Z tego co pamiętam, to było 81. Przy czym mierzone ze stoperem jako
    punktem odniesienia, wiec nie jestem w stanie zagwarantować dokładności
    na poziomie tej ostatniej sekundy. ;)


  • 46. Data: 2014-11-13 09:45:16
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    Poeksperymentowałem trochę i udało mi się skalibrować ten timer.
    Teraz w rejestr OCR0A wpisana jest wartość 238. Zegar spieszy o jakąś
    sekundę na każde 10 minut. Nie jest może to idealną sytuacją, ale w
    każdym razie jest to najlepsze rozwiązanie, jakie udało mi się znaleźć
    do tej pory.
    Dziwi mnie tylko ta rozbieżność w stosunku do obliczeń z kalkulatora...

    Wychodzi jednak na to, że z synchronizacją NTP też coś jest nie tak. Tuż
    po uruchomieniu układu mam czas różniący się o kilka sekund od
    rzeczywistego. Uzyskanie dokładnego pokrycia wymaga przeprowadzenia
    kilku-kilkunastu ręcznie wymuszonych synchronizacje, jedna po drugiej.
    Po takiej operacji czas dryfuje już normalnie. Nie jestem jednak pewien,
    czy kolejne (pojedyncze, automatyczne) synchronizacje znów go nie
    zafałszują.

    Jakiś pomysł co do możliwej przyczyny takiego stanu rzeczy? Czyżby
    funkcje obsługi NTP w bibliotece tuxgraphics posiadały jakiś błąd?


  • 47. Data: 2014-11-13 10:03:23
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    Hmm... Coś jeszcze jest na rzeczy z tą synchronizacją.
    Pojedyncza, automatyczna synchronizacja (wywołana po 10 minutach dla
    skompensowania tego sekundowego błędu) wprowadziła 14 sekundowe opóźnienie.

    Czy kod funkcji wysyłającej request wygląda w porządku?

    void client_ntp_request(uint8_t *buf,uint8_t *ntpip,uint8_t
    srcport,uint8_t *dstmac)
    {
    uint8_t i=0;
    uint16_t ck;
    if (!enc28j60linkup())return;
    //
    while(i<6){
    buf[ETH_DST_MAC +i]=dstmac[i]; // gw mac in local lan or
    host mac
    buf[ETH_SRC_MAC +i]=macaddr[i];
    i++;
    }
    buf[ETH_TYPE_H_P] = ETHTYPE_IP_H_V;
    buf[ETH_TYPE_L_P] = ETHTYPE_IP_L_V;
    fill_buf_p(&buf[IP_P],9,iphdr);
    buf[IP_ID_L_P]=ipid; ipid++;
    buf[IP_TOTLEN_L_P]=0x4c;
    buf[IP_PROTO_P]=IP_PROTO_UDP_V;
    i=0;
    while(i<4){
    buf[IP_DST_P+i]=ntpip[i];
    buf[IP_SRC_P+i]=ipaddr[i];
    i++;
    }
    fill_ip_hdr_checksum(buf);
    buf[UDP_DST_PORT_H_P]=0;
    buf[UDP_DST_PORT_L_P]=0x7b; // ntp=123
    buf[UDP_SRC_PORT_H_P]=10;
    buf[UDP_SRC_PORT_L_P]=srcport; // lower 8 bit of src port
    buf[UDP_LEN_H_P]=0;
    buf[UDP_LEN_L_P]=56; // fixed len
    // zero the checksum
    buf[UDP_CHECKSUM_H_P]=0;
    buf[UDP_CHECKSUM_L_P]=0;
    // copy the data:
    i=0;
    // most fields are zero, here we zero everything and fill later
    while(i<48){
    buf[UDP_DATA_P+i]=0;
    i++;
    }
    fill_buf_p(&buf[UDP_DATA_P],10,ntpreqhdr);
    //
    ck=checksum(&buf[IP_SRC_P], 16 + 48,1);
    buf[UDP_CHECKSUM_H_P]=ck>>8;
    buf[UDP_CHECKSUM_L_P]=ck& 0xff;
    enc28j60PacketSend(90,buf);
    }

    Zastanawia mnie zmienna ntpreqhdr. Jaką funkcję ona pełni?
    Bo jej deklaracja wygląda następująco:

    const char ntpreqhdr[] PROGMEM ={0xe3,0,4,0xfa,0,1,0,0,0,1};

    Ktoś z Was wspominał, że request powinien zawierać informację o czasie.
    Tutaj nigdzie nie jestem o nią proszony...


  • 48. Data: 2014-11-13 10:07:09
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    W dniu 2014-11-13 09:26, Marek pisze:

    > Jak widac niewielka zmiana wartości OC (turaj 249 lub 250) powoduje
    > znaczne wachanie opóźnienia czasu.

    Teraz wartość OC wynosi 238, a zegar spieszy się o jakąś sekundę na
    każde dziesięć minut. Jest to najlepszy wynik, jaki udało mi się uzyskać
    do tej pory. Różni się jednak wyraźnie od tego, co pokazywał kalkulator.

    Nie mam pojęcia co jeszcze mógłbym pomieszać w ustawieniach timera. Tryb
    CTC ustawiony, preskaler prawidłowy, zmiana OC jak widać ma wpływ na
    pracę układu...

    No i jak się okazuje - synchronizacja NTP także wprowadza jakiś błąd. Są
    to dwie niezależne sprawy.


  • 49. Data: 2014-11-13 11:45:21
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: "Andrzej W." <a...@w...pl>

    W dniu 2014-11-13 o 10:03, Atlantis pisze:
    > Bo jej deklaracja wygląda następująco:
    >
    > const char ntpreqhdr[] PROGMEM ={0xe3,0,4,0xfa,0,1,0,0,0,1};

    Naprawdę tak trudno zerknąć do RFC4330?
    Informacja o czasie nadania pakietu jest potrzebna do korekcji czasu
    przelotu pakietów UDP. Jeśli serwer NTP masz blisko a czas liczysz w
    sekundach to nie jest potrzebna taka korekta (w Twoim kodzie jej nie
    liczysz).

    0xE3 - LI=3, VN=4, Mode=3
    LI jest polem serwera, klient go nie ustawia, ale to nie ma wpływu.
    VN - ok
    Mode - ok
    0 - Stratum = 0
    4 - Poll = 4 - to ustawia tylko serwer
    0xFA - Precision = 0xFA - to ustawia tylko serwer

    Jakieś to dla mnie dziwne.
    U mnie pakiet z zapytaniem wygląda tak (wartość, długość):

    /* Client
    -- 0
    LI = 0, 2b
    VN = 4, 3b
    MODE = 3,3b
    -- 1
    Stratum = 0, 8b
    -- 2
    Poll = 0, 8b
    -- 3
    Precision = 0, 8b
    -- 4-7
    Root Delay = 0, 32b
    -- 8-11
    Root Dispersion = 0, 32b
    -- 12-15
    Reference Identifier = 0, 32b
    -- 16-23
    Reference Timestamp = 0, 64b
    -- 24-31
    Originate Timestamp = 0, 64b
    -- 32-39
    Receive Timestamp = 0, 64b
    -- 40-43
    Transmit Timestamp = Seconds, 32b
    -- 44-47
    Transmit Timestamp = Seconds Fraction, 32b
    */

    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ę.


    --
    AWa.


  • 50. Data: 2014-11-13 13:35:47
    Temat: Re: Różny czas pomimo synchronizacji z NTP
    Od: Atlantis <m...@w...pl>

    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?

strony : 1 ... 4 . [ 5 ] . 6


Szukaj w grupach

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: