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
Czarek Grądys
Guest
Guest
Wed Mar 23, 2016 3:26 pm
W dniu 23.03.2016 o 10:12, Jarosław Sokołowski pisze:
Quote:
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.
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 czy to przypadek, ale ja zawsze trafiałem na późniący się zegar
na płycie głównej! Kiedyś mnie to dziwiło, ale może tak t ma być!
--
Cezary Grądys
czarekgr@wa.onet.pl
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 4:14 pm
Pan Czarek Grądys napisał:
Quote:
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 czy to przypadek, ale ja zawsze trafiałem na późniący się zegar
na płycie głównej! Kiedyś mnie to dziwiło, ale może tak t ma być!
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 czy to przypadek, ale ja zawsze trafiałem na późniący się zegar
na płycie głównej! Kiedyś mnie to dziwiło, ale może tak t ma być!
Od dawna nie miałem do czynienia z niezsynchronizowanym zegarem komputera.
Tej prawidłowości nie odkryłem, co nie znaczy, ze jej nie ma. Sprytne.
Część problemów z załamaniem czasoprzestrzeni taka spóźnialska strategia
może eliminować, ale nie wszystkie. Sam zegar systemowy może się śpieszyć,
więc przy korektach (z serwera lub ręcznych) będzie cofnięcie. Chyba że
zegara systemowego też to dotyczy. Ale tu już jestem niemal pewny, że przy
synchronizacji okresowej widywałem poprawki w jedną i w drugą stronę.
--
Jarek
J.F.
Guest
Guest
Wed Mar 23, 2016 4:17 pm
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnf587s.71h.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:
Quote:
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.
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.
Watpie. Skoro wymyslono protokol, to i serwer musial byc, do
przetestowania :-)
W kazdym badz razie z serwerem nie mialem klopotow.
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.
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.
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.
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.
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.
A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
zrobić to precyzyjnie według wyliczeń, to będzie stabilny.
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.
A na co wpływa? Przecież drga dowolnie ucięty, a dopiero jeśli
zrobić to precyzyjnie według wyliczeń, to będzie stabilny.
O grubosc mi chodzi.
Jak sp* kat ciecia na poczatku, to bedzie niestabilny,
jak sp* potem grubosc - to bedzie niedokladny, ale stabilny - o ile
najpierw dobrze wycieto.
No chyba ze gdzies przy szlifowaniu sie bardziej docisnie z jednej
strony, skos sie zrobi - i wyjdzie tak, jakbys na poczatku krzywo
wycial.
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.
Nie mierzyłem, to nie będe się spierał. W praktyce problem
synchronizacji
czasu uważam za rozwiązany.
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.
W komputerze z linuxem, z czestym dostepem do internetu i rzadko
wylaczanym.
A my tu o zegarku bez dostepu :-)
Quote:
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
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.
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.
Czyli do RTC trzeba osobny program :-)
Quote:
Dodatkowa trudnosc - w pececie ten zegar ma sekundowa
rozdzielczosc.
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.
rozdzielczosc.
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.
RTC w pececie nie ma takiej rozdzielczosci !
Stad, aby sprawdzic jego dryft, trzeba go odczytac wiele razy az
zmieni sekunde, wtedy odczytac dokladny czas systemowy, i mamy
wzglednie dokladnie zmierzony czas w RTC.
Im czesciej odczytujemy, tym dokladniejszy pomiar, ale tez procesor
bardziej zajety przez te srednio pol sekundy.
Nawet wielordzeniowy moze byc przyblokowany, bo dostep do rejestrow
RTC dlugo trwa, przynajmniej kiedys tak bylo.
No i ja sie bawilem chyba jeszcze gdy "microsecond timer" nie byl
dostepny, kernel sam sobie sobie go organizowal, i co przerwanie
dodawal wlasnie tych 10000us do zmiennej timera. Czyli niby
"microsecond" a naprawde 10ms ..
A tak swoja droga ... to jak sobie teraz radza ?
Jest sprzetowy "time stamp counter", z rozdzielczoscia nawet jakby
lepsza niz nanosekunda, ale napedza go zegar systemowy.
Jak sie chce skorzystac i przeliczyc na UTC, to trzeba dosc ambitnie
przeliczac, z ryzykiem cofania czasu .
J.
RoMan Mandziejewicz
Guest
Guest
Wed Mar 23, 2016 4:29 pm
Hello J.F.,
Wednesday, March 23, 2016, 2:32:10 PM, you wrote:
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.
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.
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.
Znaczy jak?
Quote:
Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
tylko przy rozmowie.
tylko przy rozmowie.
Nie.
Quote:
Albo to po prostu netmonitor byl ulomny na tych telefonach.
Ano.
Quote:
No ale z Javy IMO i tak nie bylo do tych danych dostepu.
Bo nie ma potrzeby. Dane o lokalizacji są obrabiane przez serwer a nie
przeglądarkę.
[...]
--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)
J.F.
Guest
Guest
Wed Mar 23, 2016 5:45 pm
Użytkownik "RoMan Mandziejewicz" napisał w wiadomości
Hello J.F.,
Quote:
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.
Znaczy jak?
Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
tylko przy rozmowie.
Nie.
Albo to po prostu netmonitor byl ulomny na tych telefonach.
Ano.
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.
Znaczy jak?
Albo ten parametr byl dostepny tylko dla jednego BTS, a moze wrecz
tylko przy rozmowie.
Nie.
Albo to po prostu netmonitor byl ulomny na tych telefonach.
Ano.
Byc moze.
Z drugiej strony - jak nie ma rozmowy, to telefon tylko z rzadka cos
transmituje, wiec jak ustalic TA ?
Moze i to "rzadko" wystarczy ...
Quote:
No ale z Javy IMO i tak nie bylo do tych danych dostepu.
Bo nie ma potrzeby. Dane o lokalizacji są obrabiane przez serwer a
nie
przeglądarkę.
Bo nie ma potrzeby. Dane o lokalizacji są obrabiane przez serwer a
nie
przeglądarkę.
Ale jakie dane ?
Zrozum sytuacje - stary telefon, SE K550, zaden tam smartfon, ale
jednak "z Java" (J2ME).
Instaluje program od googla - i on ustala pozycje.
Wyslac do serwera mogl tylko to, co jest udostepnione Javie - a w MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.
Byc moze telefon to robil za pomoca JSR179, producent implementujac
funkcje udostepnil potrzebne dane, przeslal na serwer, odebral
odpowiedz, wystawil pozycje aplikacji.
Ale ... dzialalo bez polaczenia internetowego. Hm, a moze nie ...
wszak zeby google pokazal mapy, to trzeba miec polaczenie.
Wyglada mi na to, ze to jednak operator wyznaczal i udostepnial
pozycje.
A wtedy dziwi mnie, ze tak latwo zrezygnowal z naleznych oplat :-)
J.
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 5:53 pm
Pan J.F. napisał:
Quote:
Jedno nie implikuje drugiego. Protokół wymyślono dawno,
publiczne serwery pojawiły się dużo później.
Watpie. Skoro wymyslono protokol, to i serwer musial byc,
do przetestowania
publiczne serwery pojawiły się dużo później.
Watpie. Skoro wymyslono protokol, to i serwer musial byc,
do przetestowania
Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:
# Don't serve time or stats to anyone else by default (more secure)
Dopiero po niej można ustawić upoważnione zakresy adresów.
Quote:
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.
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.
tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
zbyt częste.
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.
Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.
Quote:
Usilowalem na szybko sprawdzic co znacza te parametry w ntp.drift,
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.
Czyli do RTC trzeba osobny program
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.
Czyli do RTC trzeba osobny program
Często RTC o ogóle nie jest potrzebne. Urządzenia przeznaczone do
pracy w sieci szęsto w ogóle nie mają.
Quote:
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.
RTC w pececie nie ma takiej rozdzielczosci !
sleep (który śpi z taką dokładnością). Programy związane z ntp też
podają dokładną różnicę czasu.
RTC w pececie nie ma takiej rozdzielczosci !
No i w ogóle średnio jest potrzebny.
--
Jarek
Grzegorz Niemirowski
Guest
Guest
Wed Mar 23, 2016 6:01 pm
Jarosław Sokołowski <jaros@lasek.waw.pl> napisał(a):
Quote:
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.
jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
Możesz sobie zrobić zaplanowane zadanie i synchronizować kiedy chcesz.
Quote:
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 tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
musi być skokowe cofanie czasu.
Oj chyba dawno, nawet jakieś 15 lat
Windows cofa czas skokowo tylko jeśli
jest jest duża różnica czasów. Jak jest mała, to dokonuje stopniowej
korekty. Odsyłam do parametrów UpdateInterval oraz PhaseCorrectRate,
opisanych tutaj:
https://msdn.microsoft.com/de-de/library/cc773263%28v=ws.10%29.aspx
--
Grzegorz Niemirowski
http://www.grzegorz.net/
OE PowerTool i Outlook Express: http://www.grzegorz.net/oe/
Uptime: 0 days, 18 hours, 49 minutes and 46 seconds
Marek
Guest
Guest
Wed Mar 23, 2016 6:13 pm
On Wed, 23 Mar 2016 11:07:12 +0100, Jarosław
Sokołowski<jaros@lasek.waw.pl> wrote:
Quote:
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.
w sieci, nawet po odcięciu od niej zachowuje się o wiele lepiej
od komputera z Windows.
Nie rozumiem, sugerujesz, że Windows nie umie synchronizować sobie
czasu z sieci (ntp)?
--
Marek
J.F.
Guest
Guest
Wed Mar 23, 2016 6:20 pm
Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:slrnnf5ifd.92m.jaros@falcon.lasek.waw.pl...
Pan J.F. napisał:
Quote:
Jedno nie implikuje drugiego. Protokół wymyślono dawno,
publiczne serwery pojawiły się dużo później.
Watpie. Skoro wymyslono protokol, to i serwer musial byc,
do przetestowania
Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:
# Don't serve time or stats to anyone else by default (more secure)
Dopiero po niej można ustawić upoważnione zakresy adresów.
publiczne serwery pojawiły się dużo później.
Watpie. Skoro wymyslono protokol, to i serwer musial byc,
do przetestowania
Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:
# Don't serve time or stats to anyone else by default (more secure)
Dopiero po niej można ustawić upoważnione zakresy adresów.
patrz raczej po dokumentacji do klienta i roznych HowTo.
Podawane przykladowe serwery nie dzialaly ?
Quote:
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.
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna
strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.
Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.
tryma się wzorca czasu jak pijany płotu. Zmiany w pliku nie są
zbyt częste.
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna
strone.
Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany przez
adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych 10000.
Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.
to jest 200ppm. Utrzymujace sie np 3 doby.
Daje 16 sekund na kazda dobe.
Hm, a moze zle pamietam, 200ppm to bardzo kiepski kwarc.
Quote:
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.
RTC w pececie nie ma takiej rozdzielczosci !
No i w ogóle średnio jest potrzebny.
sleep (który śpi z taką dokładnością). Programy związane z ntp też
podają dokładną różnicę czasu.
RTC w pececie nie ma takiej rozdzielczosci !
No i w ogóle średnio jest potrzebny.
Do startu komputera, jak nie ma lacznosci z internetem. Tzn do
ustawienia zegara na starcie.
Chodzi mi jednak o to, ze sekundowa rozdzielczosc utrudnia nieco
precyzyjne wyznaczenie dryftu.
Nie wystarczy odczytac RTC np co godzina i porownac z dokladnym
czasem.
J.
Marek
Guest
Guest
Wed Mar 23, 2016 6:21 pm
On Wed, 23 Mar 2016 17:45:03 +0100, "J.F."
<jfox_xnospamx@poczta.onet.pl> wrote:
Quote:
Wyslac do serwera mogl tylko to, co jest udostepnione Javie - a w
MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.
MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.
Googlowi wystarczy tylko cellid, mają lokalizację wszystkich.
--
Marek
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 6:27 pm
Pan Grzegorz Niemirowski napisał:
Quote:
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.
Możesz sobie zrobić zaplanowane zadanie i synchronizować kiedy chcesz.
jest jedynie możliwość okresowej synchronizacji ze zdalnym zegarem,
i to chyba tylko raz na dobę, o godzinie wybranej przez użytkownika.
Możesz sobie zrobić zaplanowane zadanie i synchronizować kiedy chcesz.
Ale przecież o to chodzi, by *nie* synchronizować "kiedy ktoś chce",
tylko żeby zawsze było zsynchronizowane.
Quote:
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.
Oj chyba dawno, nawet jakieś 15 lat Windows cofa czas skokowo tylko
jeśli jest jest duża różnica czasów. Jak jest mała, to dokonuje stopniowej
korekty. Odsyłam do parametrów UpdateInterval oraz PhaseCorrectRate,
opisanych tutaj:
https://msdn.microsoft.com/de-de/library/cc773263%28v=ws.10%29.aspx
nie tak dawno było. Jeśli zegar systemowy się śpieszy, to nie ma siły,
musi być skokowe cofanie czasu.
Oj chyba dawno, nawet jakieś 15 lat
Windows cofa czas skokowo tylko
jeśli jest jest duża różnica czasów. Jak jest mała, to dokonuje stopniowej
korekty. Odsyłam do parametrów UpdateInterval oraz PhaseCorrectRate,
opisanych tutaj:
https://msdn.microsoft.com/de-de/library/cc773263%28v=ws.10%29.aspx
Ile to jest "duża różnica czasu" (nie mam w tej chwili dostępu do WWW)?
Najwyżej kilka lat temu to było, kliknąłem w jakiś przycisk "synchronizuj"
czy podobny -- przestawił wskazówki i poinformował, że synchronizacja
zakończona. Różnica nie była wielka, taka jak może się zdarzyc przy
rozjechanym RTC.
--
Jarek
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 6:29 pm
Pan Marek napisał:
Quote:
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.
Nie rozumiem, sugerujesz, że Windows nie umie synchronizować sobie
czasu z sieci (ntp)?
odcięciu od niej zachowuje się o wiele lepiej od komputera z Windows.
Nie rozumiem, sugerujesz, że Windows nie umie synchronizować sobie
czasu z sieci (ntp)?
Sugeruję, że Windows jedyne co umie, to zsynchronizować czas z serwera.
Może potrafi coś więcej, ale ja tego nie widziałem.
--
Jarek
J.F.
Guest
Guest
Wed Mar 23, 2016 6:34 pm
Użytkownik "Marek" napisał w wiadomości grup
dyskusyjnych:almarsoft.7459296190235059062@news.neostrada.pl...
On Wed, 23 Mar 2016 17:45:03 +0100, "J.F."
Quote:
Wyslac do serwera mogl tylko to, co jest udostepnione Javie - a w
MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.
Googlowi wystarczy tylko cellid, mają lokalizację wszystkich.
MIDP
2.0 wiele tego nie bylo. Listy BTS i ich TA na moj gust nie bylo.
Googlowi wystarczy tylko cellid, mają lokalizację wszystkich.
Tez nie bylo. A moze i bylo, tylko ja zle szukam.
Jak program w Javie moze odczytac Cell-ID ?
No samo Cell-ID to troche malo - jeden BTS moze do 30km obslugiwac.
J.
JarosĹaw SokoĹowski
Guest
Guest
Wed Mar 23, 2016 6:40 pm
Pan J.F. napisał:
Quote:
Watpie. Skoro wymyslono protokol, to i serwer musial byc,
do przetestowania
Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:
# Don't serve time or stats to anyone else by default (more secure)
Dopiero po niej można ustawić upoważnione zakresy adresów.
patrz raczej po dokumentacji do klienta i roznych HowTo.
Podawane przykladowe serwery nie dzialaly ?
do przetestowania
Był, lecz niekoniecznie wszystkim dostępny. Nawet plik
konfiguracyjny demona zawiera na końcu linię:
# Don't serve time or stats to anyone else by default (more secure)
Dopiero po niej można ustawić upoważnione zakresy adresów.
patrz raczej po dokumentacji do klienta i roznych HowTo.
Podawane przykladowe serwery nie dzialaly ?
Ja to robiłem krótko po tym, jak internet stał się komercyjny.
Nikt nigdzie przykładowych serwerów ie podawał, a trochę czasu
upłynęło, nim znalazłem pierwszy dostępny publicznie.
Quote:
Chodzi mi o to, ze jednego dnia mam poprawke jakas tam, drugiego
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna
strone. Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany
przez adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych
10000.
Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.
to jest 200ppm. Utrzymujace sie np 3 doby.
Daje 16 sekund na kazda dobe.
Hm, a moze zle pamietam, 200ppm to bardzo kiepski kwarc.
podobna, trzeciego dwa razy wieksza, a czwartego w przeciwna
strone. Jesli mnie pamiec nie myli, to sprawdzalem "tick" podawany
przez adjtimex, i bylo gdzies 9999 do 10002, zamiast nominalnych
10000.
Wszystko to niewielkie różnice. Fluktuacje w jsedna i druga stronę.
to jest 200ppm. Utrzymujace sie np 3 doby.
Daje 16 sekund na kazda dobe.
Hm, a moze zle pamietam, 200ppm to bardzo kiepski kwarc.
Ja nawet nie pamiętam teraz w jakich to jednostkach. Ale na pewno
w rozmaitych. Bo na jednym komputerze mam w tej chwili "1.558007e-05"
-- i nie jestem pewny co to znaczy. Na dwóch innych, z innym systemem
jest "5.630" i "-44.094". Czyli różny jest również kierunek korekty
-- bez niej jeden by się spóźniał, drugi śpieszył.
--
Jarek
Marek
Guest
Guest
Wed Mar 23, 2016 8:19 pm
On Wed, 23 Mar 2016 18:29:43 +0100, Jarosław
Sokołowski<jaros@lasek.waw.pl> wrote:
Quote:
Sugeruję, że Windows jedyne co umie, to zsynchronizować czas z
serwera.
Może potrafi coś więcej, ale ja tego nie widziałem.
serwera.
Może potrafi coś więcej, ale ja tego nie widziałem.
No i gdzie tu wada?
--
Marek
elektroda NewsGroups Forum Index - Elektronika Polska - Jak zrealizować precyzyjną synchronizację zegara DS3231 z użyciem GSM?