NOWY TEMAT
elektroda NewsGroups Forum Index - Elektronika Polska - Jak zrealizować precyzyjną synchronizację zegara DS3231 z użyciem GSM?
Goto page Previous 1, 2, 3, 4, 5 Next
J.F.
Guest
Guest
Wed Mar 23, 2016 10:19 am
Użytkownik "JDX" napisał w wiadomości grup
dyskusyjnych:56f25c97$0$22836$65785112@news.neostrada.pl...
On 2016-03-23 09:49, J.F. wrote:
Quote:
Użytkownik "Czarek Grądys" napisał w wiadomości grup
[...]
W systemach komputerowych niedopuszczalna jest korekcja przez
cofanie
zegara! Mógłbyś faktycznie późniejszy przelew mieć zaliczony
wcześniej
jakby akurat tak trafiło.
Jakby to bankom jakos przeszkadzalo. Juz sie przyzwyczailem, ze
widze np
odsetki naliczone w sobote, z data w poniedzialek
Myślę, że niestabilny czas jednak przeszkadza:
http://queue.acm.org/detail.cfm?id=2536492.
[...]
W systemach komputerowych niedopuszczalna jest korekcja przez
cofanie
zegara! Mógłbyś faktycznie późniejszy przelew mieć zaliczony
wcześniej
jakby akurat tak trafiło.
Jakby to bankom jakos przeszkadzalo. Juz sie przyzwyczailem, ze
widze np
odsetki naliczone w sobote, z data w poniedzialek
Myślę, że niestabilny czas jednak przeszkadza:
http://queue.acm.org/detail.cfm?id=2536492.
Tak na szybko - w tym artykule nie widze slowa "clock", a "time" tez w
innym kontekscie.
On tu mowi, ze ma byc szybko, wrecz blyskawicznie, a nie, ze maja
klopoty z roznymi czasami.
A banki przyzwyczajone, ze klient placi w czwartek, informacja wplywa
w piatek, zaksieguja to sobie w niedziele :-)
Zadania systemowe sa problemem - np backup uruchomil sie o 1:00:00, a
chwile pozniej przyszla korekta zegara na 0:59:30.
J.
J.F.
Guest
Guest
Wed Mar 23, 2016 10:30 am
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnf4nci.4rr.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:
Quote:
Ponieważ komunikacja odbywa się na bieżąco, to wyliczana jest
korekta
częstotiwości -- więc nawet jeśli urządzenie zostanie odcięte od
sieci,
to wie, że do każdego miliona cyknięc swojego zegara powinno
doliczyc
na przykład pięć. Albo odjąć sześć. Idea protokołu NTP jest prosta
i klarowna,
A potem sie temperatura zmienia i zegar systemowy (procesora, nie
rtc)
plynie, bo o jego dokladnosc nikt jakos ambitnie nie dba :-)
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność
już mniej. Zaglądam czasem z nudów do pliku ntp.drift w swoich
komputerach.
Jago zawartość nie zmienia się często, co oznacza, że raz wyliczony
współczynnik korekcji starcza na długo, lokalny zegar pracuje
stabilnie.
korekta
częstotiwości -- więc nawet jeśli urządzenie zostanie odcięte od
sieci,
to wie, że do każdego miliona cyknięc swojego zegara powinno
doliczyc
na przykład pięć. Albo odjąć sześć. Idea protokołu NTP jest prosta
i klarowna,
A potem sie temperatura zmienia i zegar systemowy (procesora, nie
rtc)
plynie, bo o jego dokladnosc nikt jakos ambitnie nie dba :-)
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność
już mniej. Zaglądam czasem z nudów do pliku ntp.drift w swoich
komputerach.
Jago zawartość nie zmienia się często, co oznacza, że raz wyliczony
współczynnik korekcji starcza na długo, lokalny zegar pracuje
stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie bylo
dobrze.
Nastawy ustawione razy, mogly sie za dwa dni, po kolejnej
synchronizacji, zmienic dosc istotnie.
Oczywiscie to wbrew narzekaniom nie byly duze zmiany, no ale komputer
odciety od sieci mogl sie po tygodniu o pare sekund przestawic.
No i wez pod uwage, ze mu tu o serwerze wlaczonym stale.
A przecietny komputer z windowsem - wlaczamy, bierzemy czas z RTC,
potem system sobie liczy zegarem systemowym, wylaczamy.
Dwa zegary, dwa dryfty, a ten systemowy mocno zmienny, skoro komputer
sie nagrzewa i studzi.
J.
J.F.
Guest
Guest
Wed Mar 23, 2016 10:40 am
Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:56f259e0$0$22820$65785112@news.neostrada.pl...
W dniu 2016-03-22 o 12:33, J.F. pisze:
Quote:
Operatorzy tak chetnie zrezygnowali z naleznej im zlotowki ?
Google zaplacil ? Czy przekonal do dobrowolnego wlaczenia ?
A moze producenci BTS ich olali i nic nie mowiac w kolejnym upgrade
wlaczyli usluge wszystkim ?
Google chyba po prostu zrobiło sobie bazę niezbędnych danych.
Google zaplacil ? Czy przekonal do dobrowolnego wlaczenia ?
A moze producenci BTS ich olali i nic nie mowiac w kolejnym upgrade
wlaczyli usluge wszystkim ?
Google chyba po prostu zrobiło sobie bazę niezbędnych danych.
IMO - z poziomu Javy J2ME to nie mieli dostepu do listy widocznych
BTS, ani do "odleglosci" do nich.
No chyba, ze jakies wytyczne dali i producent telefonu implementujac
Jave mogl udostepnic te dane przez odpowiednia funkcje Javy.
https://en.wikipedia.org/wiki/Location_API_for_Java_ME
Ale jak to dziala - nie wyjasnili.
Nokia jest autorem JSR179, i jednoczesnie dostawca duzej ilosci BTS i
sieci - to moze omineli operatorow ?
Jak kto biegly w tej Javie, to moze znajdzie zrodlo.
Quote:
Od użytkowników możesz pozyskać dane na temat tego, z
czym się łączą w danej chwili, jaka jest siła sygnały itp.
czym się łączą w danej chwili, jaka jest siła sygnały itp.
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc od
BTS, gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
J.
JDX
Guest
Guest
Wed Mar 23, 2016 10:45 am
On 2016-03-23 10:19, J.F. wrote:
[...]
Quote:
Tak na szybko - w tym artykule nie widze slowa "clock", a "time" tez w
innym kontekscie.
On tu mowi, ze ma byc szybko, wrecz blyskawicznie, a nie, ze maja
klopoty z roznymi czasami.
A banki przyzwyczajone, ze klient placi w czwartek, informacja wplywa w
piatek, zaksieguja to sobie w niedziele :-)
Zadania systemowe sa problemem - np backup uruchomil sie o 1:00:00, a
chwile pozniej przyszla korekta zegara na 0:59:30.
Ale te transakcje przecież trzeba w pewnym momencie powiązać z czasem
innym kontekscie.
On tu mowi, ze ma byc szybko, wrecz blyskawicznie, a nie, ze maja
klopoty z roznymi czasami.
A banki przyzwyczajone, ze klient placi w czwartek, informacja wplywa w
piatek, zaksieguja to sobie w niedziele :-)
Zadania systemowe sa problemem - np backup uruchomil sie o 1:00:00, a
chwile pozniej przyszla korekta zegara na 0:59:30.
Ale te transakcje przecież trzeba w pewnym momencie powiązać z czasem
rzeczywistym i mogłoby się okazać, że transakcja która wg zegara
systemowego została wykonana po jakiej innej transakcji na skutek
korekty RTC została wykonana przed tą inną transakcją. A to daje się
przeliczyć na pieniądze.
J.F.
Guest
Guest
Wed Mar 23, 2016 11:05 am
Użytkownik "JDX" napisał w wiadomości grup
dyskusyjnych:56f265b2$0$695$65785112@news.neostrada.pl...
On 2016-03-23 10:19, J.F. wrote:
[...]
Quote:
A banki przyzwyczajone, ze klient placi w czwartek, informacja
wplywa w
piatek, zaksieguja to sobie w niedziele :-)
Zadania systemowe sa problemem - np backup uruchomil sie o 1:00:00,
a
chwile pozniej przyszla korekta zegara na 0:59:30.
Ale te transakcje przecież trzeba w pewnym momencie powiązać z czasem
rzeczywistym i mogłoby się okazać, że transakcja która wg zegara
systemowego została wykonana po jakiej innej transakcji na skutek
korekty RTC została wykonana przed tą inną transakcją. A to daje się
przeliczyć na pieniądze.
wplywa w
piatek, zaksieguja to sobie w niedziele :-)
Zadania systemowe sa problemem - np backup uruchomil sie o 1:00:00,
a
chwile pozniej przyszla korekta zegara na 0:59:30.
Ale te transakcje przecież trzeba w pewnym momencie powiązać z czasem
rzeczywistym i mogłoby się okazać, że transakcja która wg zegara
systemowego została wykonana po jakiej innej transakcji na skutek
korekty RTC została wykonana przed tą inną transakcją. A to daje się
przeliczyć na pieniądze.
Jak pisalem - w bankach jakby nie bylo to problemem.
Ale moze w specyficznych sytuacjach jest.
To moze jednak lepszy jakis wskaznik kolejnosci transakcji niz czas ?
J.
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 11:07 am
Pan J.F. napisał:
Quote:
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie? Czas w DOS/Windows faktycznie w praktyce zależy
wyłącznie od hardware. W porządnych systemach używających ntpd jest
już inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni pochodziła
w sieci, nawet po odcięciu od niej zachowuje się o wiele lepiej
od komputera z Windows. Jeśli oczywiście ma ona system plików z
możliwością nieulotnego zapisu (flash przynajmniej). Dzisiaj taką
maszynką może być wszystko -- od wielkich i drogich serwerów, aż
po tablety, telefony i routery po kilkanaście euro za sztukę. Tylko
Windows się ostał bez tego.
Quote:
Oczywiscie to wbrew narzekaniom nie byly duze zmiany, no ale komputer
odciety od sieci mogl sie po tygodniu o pare sekund przestawic.
odciety od sieci mogl sie po tygodniu o pare sekund przestawic.
Dla mnie są to ogromne zmiany. Zupełnie nieakceptowalne.
Quote:
No i wez pod uwage, ze mu tu o serwerze wlaczonym stale.
A przecietny komputer z windowsem - wlaczamy, bierzemy czas
z RTC, potem system sobie liczy zegarem systemowym, wylaczamy.
Dwa zegary, dwa dryfty, a ten systemowy mocno zmienny, skoro
komputer sie nagrzewa i studzi.
A przecietny komputer z windowsem - wlaczamy, bierzemy czas
z RTC, potem system sobie liczy zegarem systemowym, wylaczamy.
Dwa zegary, dwa dryfty, a ten systemowy mocno zmienny, skoro
komputer sie nagrzewa i studzi.
Teraz chyba już wpadli na to, by po włączeniu jednorazowo
zsynchronizować czas z serwerem. Kiedyś nawet tego nie było.
--
Jarek
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 11:13 am
JDX pisze:
Quote:
Ale te transakcje przecież trzeba w pewnym momencie powiązać z czasem
rzeczywistym i mogłoby się okazać, że transakcja która wg zegara
systemowego została wykonana po jakiej innej transakcji na skutek
korekty RTC została wykonana przed tą inną transakcją. A to daje się
przeliczyć na pieniądze.
rzeczywistym i mogłoby się okazać, że transakcja która wg zegara
systemowego została wykonana po jakiej innej transakcji na skutek
korekty RTC została wykonana przed tą inną transakcją. A to daje się
przeliczyć na pieniądze.
W HFT od synchronizacji zegara ważniejszy jest czas propagacji
w łączu telekomunikacyjnym. Gracze giełdowi oceniają je tak samo,
jak gracze w CS. Chodzi o to, by szybko pobrać informację, podjąć
decyzję i dać odpowiednie zlecenie. Powiązanie z realnym czasem
następuje w komputerach giełdowych. Mnie jest wszystko jedno,
czy milion dolarów zarobiłem w tej, czy w tamtej milisemundzie.
--
Jarek
RoMan Mandziejewicz
Guest
Guest
Wed Mar 23, 2016 12:04 pm
Hello Jarosław,
Wednesday, March 23, 2016, 10:12:01 AM, you wrote:
Quote:
Ponieważ komunikacja odbywa się na bieżąco, to wyliczana jest korekta
częstotiwości -- więc nawet jeśli urządzenie zostanie odcięte od sieci,
to wie, że do każdego miliona cyknięc swojego zegara powinno doliczyc
na przykład pięć. Albo odjąć sześć. Idea protokołu NTP jest prosta i
klarowna, a wszystko dobrze zaimplementowane. Nawet accespoint za pięć
dych to robi. Tylko w Microsofcie wciąż trwa średniowiecze -- tam nie
wyszli poza pomysł "niech się zegar raz na dobę zsynchronizuje".
W systemach komputerowych niedopuszczalna jest korekcja przez cofanie
zegara! Mógłbyś faktycznie późniejszy przelew mieć zaliczony wcześniej
jakby akurat tak trafiło.
Co poradzimy, że w Microsofcie mają na ten temat inne zdanie? W Windows
jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
Przynajmniej tak było, gdy ostatni raz widziałem ten system. A to wcale
nie tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
musi być skokowe cofanie czasu.
częstotiwości -- więc nawet jeśli urządzenie zostanie odcięte od sieci,
to wie, że do każdego miliona cyknięc swojego zegara powinno doliczyc
na przykład pięć. Albo odjąć sześć. Idea protokołu NTP jest prosta i
klarowna, a wszystko dobrze zaimplementowane. Nawet accespoint za pięć
dych to robi. Tylko w Microsofcie wciąż trwa średniowiecze -- tam nie
wyszli poza pomysł "niech się zegar raz na dobę zsynchronizuje".
W systemach komputerowych niedopuszczalna jest korekcja przez cofanie
zegara! Mógłbyś faktycznie późniejszy przelew mieć zaliczony wcześniej
jakby akurat tak trafiło.
Co poradzimy, że w Microsofcie mają na ten temat inne zdanie? W Windows
jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
Przynajmniej tak było, gdy ostatni raz widziałem ten system. A to wcale
nie tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
musi być skokowe cofanie czasu.
Nie wiem, jak w nowszych wersjach, ale jeszcze w XP na pewno dało się
ustawić w rejestrze częstszą synchronizację. Ja mam ustawione co trzy
godziny.
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)
J.F.
Guest
Guest
Wed Mar 23, 2016 12:29 pm
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnf4qmg.5a2.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:
Quote:
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym pliku/patrzylem
na aktualne dane.
Quote:
Czas w DOS/Windows faktycznie w praktyce zależy
wyłącznie od hardware. W porządnych systemach używających ntpd jest
już inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni pochodziła
w sieci, nawet po odcięciu od niej zachowuje się o wiele lepiej
od komputera z Windows.
wyłącznie od hardware. W porządnych systemach używających ntpd jest
już inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni pochodziła
w sieci, nawet po odcięciu od niej zachowuje się o wiele lepiej
od komputera z Windows.
Od komputera z Windows zapewne. Tym niemniej ten wymagany wspolczynnik
korekcji sie zmienial dosc istotnie.
Quote:
Jeśli oczywiście ma ona system plików z
możliwością nieulotnego zapisu (flash przynajmniej).
możliwością nieulotnego zapisu (flash przynajmniej).
Masz na mysli odtworzenie zawartosci ntp.drift i uzycie do nowego
startu komputera ?
No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
komputer zimny i sie dopiero nagrzewa ...
J.
AlexY
Guest
Guest
Wed Mar 23, 2016 12:47 pm
J.F. pisze:
[..]
Quote:
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc od BTS,
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA który
jest bezpośrednio powiązany z odległością od niego.
--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 1:14 pm
Pan J.F. napisał:
Quote:
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym pliku/patrzylem
na aktualne dane.
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
w swoich komputerach. Jago zawartość nie zmienia się często, co
oznacza, że raz wyliczony współczynnik korekcji starcza na długo,
lokalny zegar pracuje stabilnie.
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym pliku/patrzylem
na aktualne dane.
A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu. Więc
ntp używało się w obrębie własnej sieci, żeby przynajmniej w niej
komputery tak samo cykały. A to już wymagało wskazania lokalnego
serwera i opisania tego w konfigach. Domyślna instalacja tego nie
mogła mieć.
Quote:
Czas w DOS/Windows faktycznie w praktyce zależy wyłącznie od
hardware. W porządnych systemach używających ntpd jest już
inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni
pochodziła w sieci, nawet po odcięciu od niej zachowuje się
o wiele lepiej od komputera z Windows.
Od komputera z Windows zapewne. Tym niemniej ten wymagany
wspolczynnik korekcji sie zmienial dosc istotnie.
hardware. W porządnych systemach używających ntpd jest już
inaczej. Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni
pochodziła w sieci, nawet po odcięciu od niej zachowuje się
o wiele lepiej od komputera z Windows.
Od komputera z Windows zapewne. Tym niemniej ten wymagany
wspolczynnik korekcji sie zmienial dosc istotnie.
Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej. Ale kalibracja
tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
urządzeniu.
Quote:
Jeśli oczywiście ma ona system plików z możliwością nieulotnego
zapisu (flash przynajmniej).
Masz na mysli odtworzenie zawartosci ntp.drift i uzycie do nowego
startu komputera ?
zapisu (flash przynajmniej).
Masz na mysli odtworzenie zawartosci ntp.drift i uzycie do nowego
startu komputera ?
Tak, to w praktyce tak właśnie wygląda.
Quote:
No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
komputer zimny i sie dopiero nagrzewa ...
komputer zimny i sie dopiero nagrzewa ...
Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
to przy syncronizacji. A po niej robi się zapis system --> RTC.
Sprytna metoda, która pozwala zachować lepszy czas w systemach
bez połączenia z siecią.
--
Jarek
cezar
Guest
Guest
Wed Mar 23, 2016 1:19 pm
On 23/03/2016 11:47, AlexY wrote:
Quote:
J.F. pisze:
[..]
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc od BTS,
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA który
jest bezpośrednio powiązany z odległością od niego.
[..]
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc od BTS,
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA który
jest bezpośrednio powiązany z odległością od niego.
Dodatkowo chyba każda sieć ma zaimplementowane 3GPP TS 03.71 dzieki
czemu operator moze na zywo odczytywac ten parametr poprzez połączenie
wykonane bez wiedzy własciciela telefonu a nawet odczytywać pozycję GPSa
wbudowanego w telefon. O ile pamietam, moze go nawet włączyć jeśli jest
wyłączony przez użytkownika.
c.
J.F.
Guest
Guest
Wed Mar 23, 2016 2:21 pm
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnf524s.6cp.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:
Quote:
Dlatego napisałem, że ważna jest *stabilność* zegara, a jego
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym
pliku/patrzylem
na aktualne dane.
A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu.
dokładność już mniej. Zaglądam czasem z nudów do pliku ntp.drift
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym
pliku/patrzylem
na aktualne dane.
A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu.
Skoro wymyslili NTP, to chyba bylo latwo :-)
Juz nie pamietam dokladnie jak to robilem, ale zainteresowala mnie
stabilnosc wewnetrznego kwarcu.
Wiec synchronizowalem z jakim zewnetrznym serwerem NTP, i patrzylem
jak sie zmienia wyliczony dryft.
No i wychodzilo tak sobie.
Quote:
Zegar systemowy jest skorygowany przez doświadczalnie
wyznaczony parametr. Tak maszynka, która sobie kilka dni
pochodziła w sieci, nawet po odcięciu od niej zachowuje się
o wiele lepiej od komputera z Windows.
Od komputera z Windows zapewne. Tym niemniej ten wymagany
wspolczynnik korekcji sie zmienial dosc istotnie.
Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej.
wyznaczony parametr. Tak maszynka, która sobie kilka dni
pochodziła w sieci, nawet po odcięciu od niej zachowuje się
o wiele lepiej od komputera z Windows.
Od komputera z Windows zapewne. Tym niemniej ten wymagany
wspolczynnik korekcji sie zmienial dosc istotnie.
Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej.
Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.
Co prawda na reku mam zegarek Casio, ktory jest pierunsko dokladny,
ale inne casio juz takie nie sa.
A kwarc tam chyba inny (tuning fork) niz w procesorze.
Moze teraz sa lepsze kwarce, ale do komputera to sie zasadniczo nikt
nie przejmuje - najtanszy jest najlepszy
Tak czy inaczej - zapamietalem sobie, ze stabilne te kwarce nie byly.
Quote:
Ale kalibracja
tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
urządzeniu.
tego, to już poważniejsza sprawa -- wymaga czasu. Korzystanie z ntpd
pozwala na to, by czas ten płynął nie w fabryce, ale w już gotowym
urządzeniu.
Tak nawiasem mowiac, jak patrze na ten zegarek, ktory potrafi miec
sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
programowej w zegarku.
Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
obliczyc o ile i zapamietac poprawke.
Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?
Quote:
No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
komputer zimny i sie dopiero nagrzewa ...
Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
komputer zimny i sie dopiero nagrzewa ...
Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi stabilnosc
niezbyt dobra.
Quote:
Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
to przy syncronizacji. A po niej robi się zapis system --> RTC.
to przy syncronizacji. A po niej robi się zapis system --> RTC.
Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
Tylko - czy tak sie robi ?
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift, nie
znalazlem - on chyba RTC nie obsluguje ?
Dodatkowa trudnosc - w pececie ten zegar ma sekundowa rozdzielczosc.
Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
"moment" zmiany.
J.
J.F.
Guest
Guest
Wed Mar 23, 2016 2:32 pm
Użytkownik "cezar" napisał w wiadomości grup
dyskusyjnych:ncu1ku$399$1@solani.org...
On 23/03/2016 11:47, AlexY wrote:
Quote:
J.F. pisze:
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc
od BTS,
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w
odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA
który
jest bezpośrednio powiązany z odległością od niego.
Sila sygnalu jest zludna - w GSM byl lepszy wskaznik - odleglosc
od BTS,
gdyz system wymagal precyzyjnego timingu (takiego 500m).
Ale cos mi chodzi po glowie, ze telefon to chyba znal w
odniesieniu
tylko do aktualnie uzywanego, jednego BTS.
A nam trzeba 3 lub wiecej.
Komórka monitoruje kilka BTSów i każdy z nich ma swój parametr TA
który
jest bezpośrednio powiązany z odległością od niego.
O ile pamietam stare zabawy z netmonitorem, to bylo jakos inaczej
jednak.
Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
tylko przy rozmowie.
Albo to po prostu netmonitor byl ulomny na tych telefonach.
No ale z Javy IMO i tak nie bylo do tych danych dostepu.
Quote:
Dodatkowo chyba każda sieć ma zaimplementowane 3GPP TS 03.71 dzieki
czemu operator moze na zywo odczytywac ten parametr poprzez
połączenie wykonane bez wiedzy własciciela telefonu
czemu operator moze na zywo odczytywac ten parametr poprzez
połączenie wykonane bez wiedzy własciciela telefonu
Przede wszystkim to TA jest, a przynajmniej bylo w GSM, zadawane przez
siec.
Wiec siec dobrze wie ktore, siec moze przelaczyc na innego BTS czy
moze nawet moze bez przelaczania ustalic.
Quote:
a nawet odczytywać pozycję GPSa wbudowanego w telefon. O ile
pamietam, moze go nawet włączyć jeśli jest wyłączony przez
użytkownika.
pamietam, moze go nawet włączyć jeśli jest wyłączony przez
użytkownika.
W nowoczesnych to wcale bym sie nie zdziwil.
Ale ja sprawdzalem na telefonie jeszcze bez GPS :-)
J.
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 2:58 pm
Pan J.F. napisał:
Quote:
Kiedys sie temu przygladalem, i w takim "zwyklym pececie" nie
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym
pliku/patrzylem na aktualne dane.
A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu.
Skoro wymyslili NTP, to chyba bylo latwo
bylo dobrze. Nastawy ustawione razy, mogly sie za dwa dni, po
kolejnej synchronizacji, zmienic dosc istotnie.
Ale w jakim systemie?
Linux. Tez ten ntp drift ogladalem, ale chyba w innym
pliku/patrzylem na aktualne dane.
A może niemiał tego ntpd włączonego? Kiedyś często się zdarzało.
I wcale nie było łatwo o publicznie dostępny serwer czasu.
Skoro wymyslili NTP, to chyba bylo latwo
Jedno nie implikuje drugiego. Protokół wymyślono dawno, publiczne
serwery pojawiły się dużo później.
Quote:
Juz nie pamietam dokladnie jak to robilem, ale zainteresowala
mnie stabilnosc wewnetrznego kwarcu.
Wiec synchronizowalem z jakim zewnetrznym serwerem NTP,
i patrzylem jak sie zmienia wyliczony dryft.
No i wychodzilo tak sobie.
mnie stabilnosc wewnetrznego kwarcu.
Wiec synchronizowalem z jakim zewnetrznym serwerem NTP,
i patrzylem jak sie zmienia wyliczony dryft.
No i wychodzilo tak sobie.
Ale co wychodziło tak sobie? Komputer zsynchronizowany z serwerem
tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
zbyt częste.
Quote:
Jak wspomniałem, zmienia się rzadko. W miare łatwo jest wyprodukwać
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej.
Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.
kwarc wysokiej jakości, o dobrej stabilności, w tym temperaturowej.
To się trzaska jedno po drugim na linii produkcyjnej.
Czy tak latwo ... hm, katy ciecia podaja z dokladnoscia do minut.
Dokladnosc obrobki wielka, ale ona na stabilnosc chyba nie wplywa.
A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
zrobić to precyzyjnie według wyliczeń, to będzie stabilny.
Quote:
Tak nawiasem mowiac, jak patrze na ten zegarek, ktory potrafi miec
sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
programowej w zegarku.
Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
obliczyc o ile i zapamietac poprawke.
Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?
sekunde na miesiac, to sie zastanawiam, czy nie zrobili korekcji
programowej w zegarku.
Az sie prosi - jesli uzytkownik koryguje w przod lub w tyl, to
obliczyc o ile i zapamietac poprawke.
Bo inaczej co - ktos w fabryce cierpliwie trymerem krecil ?
Mogli tak zrobić, to przypomina idee NTP, było na czym się wzorować.
Quote:
Ale problem nagrzewania jest już w zancznym stopniu wyeliminowany
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi stabilnosc
niezbyt dobra.
przez technologię. Niekótrzy nawet próbują kompensowac uchyb RTC
w systmach, które są odcięte od sieci. Porównuje się czas sytemowy
z rtc przy starcie (zero z definicji) i po określonych odcinkach
czasu. Wtedy wiadomo ile na dobę ten RTC się spieszy lub spóźnia.
Mozna. O ile pamietam, to tez to mierzylem i wychodzila mi stabilnosc
niezbyt dobra.
Nie mierzyłem, to nie będe się spierał. W praktyce problem synchronizacji
czasu uważam za rozwiązany.
Quote:
Przy kolejnym bootowaniu wiadomo ile się rozjechał i uwzględnia
to przy syncronizacji. A po niej robi się zapis system --> RTC.
Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
Tylko - czy tak sie robi ?
to przy syncronizacji. A po niej robi się zapis system --> RTC.
Mozna. Trzeba wiedziec ile system byl wylaczony, ale to mozna ustalic,
o ile sie zapisze czas zamkniecia czy tez ostatniego ustawienia.
Tylko - czy tak sie robi ?
Widziałem takie rozwiązanie. Można sprawdzać na przykład co godzinę
i *nie* korygować RTC. Czas wyłączenia znany jest od razu po uruchomieniu
-- różnica między czasem bieżącym a czasem ostatnirgo zapisu pliku
z odchyłką.
Quote:
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
nie znalazlem - on chyba RTC nie obsluguje ?
nie znalazlem - on chyba RTC nie obsluguje ?
Z RTC nie ma nic wpólnego. Z *przesunięciem* czasowym też nie. To jest
stan wirtualnego trymera, czyli korekta *częstotliwości*, tak w skrócie.
Quote:
Dodatkowa trudnosc - w pececie ten zegar ma sekundowa rozdzielczosc.
Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
"moment" zmiany.
Dokladniejsze ustawienia wymagaja ciaglego odczytu i czekania na
"moment" zmiany.
A skąd, mikrosekundowa dokładność dostępna jest nawet dla programu
sleep (który śpi z taką dokładnością). Programy związane z ntp też
podają dokładną różnicę czasu.
--
Jarek
elektroda NewsGroups Forum Index - Elektronika Polska - Jak zrealizować precyzyjną synchronizację zegara DS3231 z użyciem GSM?