Użytkownik "Jarosław Sokołowski" <j...@l...waw.pl> napisał w wiadomości
news:slrnnf2a17.mf7.jaros@falcon.lasek.waw.pl...
>> W sumie, skoro i tak musi się zalogować, to czemu nie, te kilka
>> dodatkowych bajtów chyba nie obciążą tak bardzo systemu?
>
> To już decyzja psa ogrodnika. Czyli operatora.

Logiczne.

>
>> Mnie wystarczy NTP, ostatecznie mogę sobie "ręcznie" doliczyć
>> różnicę. Jak mi radio piknie za każdym razem półtorej sekundy
>> po czasie w kompie, czy przed nim, to dalej, patrząc na zegar,
>> dodaję ten uchyłek i mam w miarę dokadny czas. Toleruję zegar
>> z uchybem, jesli wiem, ile on wynosi.
>
> Przecież tak właśnie działa NTP, że niczego nie trzeba samemu
> doliczać. Synchronizuje się do zdalnego zegara (atomowego, bo
> dlaczego by miało do innego). Czas propagacji danych nie wpływa
> na dokładność, bo protokół uwzględnia przelot wte i wew te,
> i dolicza ten uchyb do lokalnego czasu. Nie jest też bardzo ważna

Patrząc jak to działa, nie pozostaje nic innego, niż się zgodzić.
Miałem na myśli bardziej to, ze czasem mi jakiś program na tyle kompa
przydusi, ze zegar potrafi się rozjechać. Ale spoko, sam zegar w kompie jest
dobry.

> dokładność strojenia lokalnego kwarcu. 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

Aż tak dokładnie mi nie trzeba, bo już i tak jest.

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

No niestety, trzeba w Rejestrze grzebać, bo od jakiegoś czasu zniknęło mi to
z Polis, w których zwykle to sobie ustawiałem. Trochę utrudnia to sprawę,
mogę sobie synchro co godzinę ustawić. Mógłbym częściej, ale co godzinę
chwatit'. Najczęściej się rozjeżdża, gdy podmieniam dysk i odpalam Ubuntu,
po którym jak wrócę do Windy., muszę pchać zegar do przodu o godzinę.

--
To nie wstyd być biedakiem, ale, żeby to był zaszczyt,
to ja tego też nie powiem!
(C) Tewje do Pana Boga.

do góry

ACMM-033 napisało:

>>> Mnie wystarczy NTP, ostatecznie mogę sobie "ręcznie" doliczyć
>>> różnicę. Jak mi radio piknie za każdym razem półtorej sekundy
>>> po czasie w kompie, czy przed nim, to dalej, patrząc na zegar,
>>> dodaję ten uchyłek i mam w miarę dokadny czas. Toleruję zegar
>>> z uchybem, jesli wiem, ile on wynosi.
>>
>> Przecież tak właśnie działa NTP, że niczego nie trzeba samemu
>> doliczać. Synchronizuje się do zdalnego zegara (atomowego, bo
>> dlaczego by miało do innego). Czas propagacji danych nie wpływa
>> na dokładność, bo protokół uwzględnia przelot wte i wew te,
>> i dolicza ten uchyb do lokalnego czasu. Nie jest też bardzo ważna
>
> Patrząc jak to działa, nie pozostaje nic innego, niż się zgodzić.
> Miałem na myśli bardziej to, ze czasem mi jakiś program na tyle
> kompa przydusi, ze zegar potrafi się rozjechać. Ale spoko, sam
> zegar w kompie jest dobry.

Szczerze mówiąc, nie spotkałem się z takim przypadkiem. Żeby
przyduszenie rozjeżdżało. Nawet trudno mi to sobie wyobrazić,
jak ktoś to mógł tak zaprojektować. Ale kto wie, myśl ludzka
nie zna granic.

>> dokładność strojenia lokalnego kwarcu. 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
>
> Aż tak dokładnie mi nie trzeba, bo już i tak jest.

Ale nie zawsze jest. Mówiąc inaczej, przy korzystaniu z demona NTP
bardziej istotna jest długoterminowa stabilnośc kwarcu, niż dokładne
jego dostrojenie.

>> 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".
>
> No niestety, trzeba w Rejestrze grzebać, bo od jakiegoś czasu
> zniknęło mi to z Polis, w których zwykle to sobie ustawiałem.
> Trochę utrudnia to sprawę, mogę sobie synchro co godzinę ustawić.

To nie jest dobre rozwiązanie. A wielu przypadkach fatalne. Jeśli
lokalny zegar się śpieszy, to zostaje nagle cofnięty. No i mamy
lokalne załamanie czasoprzestrzeni. NTP nie dopuszcza do sytuacji,
kiedy czas staje się nieciągły. Jak ma skorygować o kilka sekund,
to rozkłada operację na wiele minut, delikatnie korygując tempo
zegara.

> Mógłbym częściej, ale co godzinę chwatit'. Najczęściej się rozjeżdża,
> gdy podmieniam dysk i odpalam Ubuntu, po którym jak wrócę do Windy.,
> muszę pchać zegar do przodu o godzinę.

Można w Ubuntu ustawić, by w RTC pył przechowywany lokalnyczas, jak
w Windzie, a nie czas uniwersalny.

--
Jarek

do góry

Hello J.F.,

Tuesday, March 22, 2016, 12:33:53 PM, you wrote:

>>>> Całkiem pasywnie, czyli przez nasłuch częstotliwości, to nie.
>>>> Potrzebne jest zalogowanie do BTS. I nie wiem czy wystarczy
>>>> logowanie "w trybie 112", czyli bez karty SIM. Dla zegarów
>>> W sumie, skoro i tak musi się zalogować, to czemu nie, te kilka
>>> dodatkowych bajtów chyba nie obciążą tak bardzo systemu?
>>To już decyzja psa ogrodnika. Czyli operatora.
> A propos - ktos pamieta jak to z lokalizacja bylo ... i jest ?
> Bo ja pamietam, ze pojawila sie techniczna mozliwosc zgrubnej
> lokalizacji telefony przez siec na podstawie odleglosci od BTS,
> operatorzy wkrotce przekuli to na usluge platna zlotowke od zdarzenia,
> a potem jakos wyskoczyly mapy google i potrafily sie lokalizowac.
> I to jeszcze w Javie J2ME.

Mapy Google nie lokalizują dokładnie. Jeśli nie mają położenia na
podstawie okolicznych routerów WiFi, to pokazują pozycję BTSa, do
którego telefon jest zalogowany. Błąd bywa i kilkanaście kilometrów :(

Usługi operatorów próbowały wykonywać coś w rodzaju triangulacji i
korzystały z więcej niż jednego BTSa oraz parametru TA, co dawało
dokładność rzędu kilkuset metrów teoretycznie.

[...]

--
Best regards,
RoMan
Nowa strona: http://www.elektronika.squadack.com (w budowie!)

do góry

Użytkownik "Jarosław Sokołowski"

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

Pierdoły do kwadratu http://niusy.pl/9p0

>
> No niestety, trzeba w Rejestrze grzebać, bo od jakiegoś czasu
> zniknęło mi to z Polis, w których zwykle to sobie ustawiałem.
> Trochę utrudnia to sprawę, mogę sobie synchro co godzinę ustawić.

To nie jest dobre rozwiązanie. A wielu przypadkach fatalne. Jeśli
lokalny zegar się śpieszy, to zostaje nagle cofnięty. No i mamy
lokalne załamanie czasoprzestrzeni. NTP nie dopuszcza do sytuacji,
kiedy czas staje się nieciągły. Jak ma skorygować o kilka sekund,
to rozkłada operację na wiele minut, delikatnie korygując tempo
zegara.
---
Ale to jak sam napisałeś wcześniej daemon a nie prosta synchronizacja za
pomocą NTP

do góry

W dniu 22.03.2016 o 12:10, Jarosław Sokołowski pisze:
> 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.

--
Cezary Grądys
c...@w...onet.pl

do góry

Użytkownik "Czarek Grądys" napisał w wiadomości grup
dyskusyjnych:56f25102$0$694$6...@n...neostrada.
pl...
W dniu 22.03.2016 o 12:10, Jarosław Sokołowski pisze:
> 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 :-)

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

Jakby to bankom jakos przeszkadzalo. Juz sie przyzwyczailem, ze widze
np odsetki naliczone w sobote, z data w poniedzialek :-)

Ale owszem, multum problemow moze powodowac ... u Unixie, widac
Windows lepiej zaprogramowany :-)
Albo te serwerowe robia to jednak podobnie :-)

J.

do góry

W dniu 2016-03-22 o 12:33, J.F. pisze:

> 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. W
przypadku WiFi robią to od bardzo, bardzo dawna. Pamiętam, jak w czasach
smartfonowej prehistorii (używałem wtedy bodajże HTC WIzarda z
odbiornikiem GPS na Bluetooth) zauważyłem, że aplikacja do map Google'a
potrafi dokładnie określić moją lokalizację bez GPS-a, jeśli tylko byłem
w zasięgu sieci WiFi, z której korzystałem wcześniej, mając równocześnie
podłączony GPS.
O sprawie zrobiło się głośno kilka lat później, gdy już co druga osoba
miała smartfona. Potem chyba nawet wyszło na jaw, że ich samochody z
kamerami uprawiają coś w rodzaju Wardrivingu, zbierając dane o
lokalizacji okolicznych sieci WiFi.

Nie widzę powodu, dla którego nie mieliby robić czegoś takiego w
przypadku BTS-ów. 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. Na podstawie
tego można już wyliczyć lokalizację BTS-a, z której potem można
korzystać do świadczenia usług geolokalizacyjnych bez GPS.

do góry

On 2016-03-23 09:49, J.F. wrote:
> Użytkownik "Czarek Grądys" napisał w wiadomości grup
> dyskusyjnych:56f25102$0$694$6...@n...neostrada.
pl...
[...]
>> 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.

do góry

Pan J.F. napisał:

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

--
Jarek

do góry

Pan Czarek Grądys napisał:

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

--
Jarek

do góry