Użytkownik "JDX" napisał w wiadomości grup
dyskusyjnych:56f25c97$0$22836$6...@n...neostrad
a.pl...
On 2016-03-23 09:49, J.F. wrote:
> 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.

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.

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
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.

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.

do góry

Użytkownik "Atlantis" napisał w wiadomości grup
dyskusyjnych:56f259e0$0$22820$6...@n...neostrad
a.pl...
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.

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.

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

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.

do góry

On 2016-03-23 10:19, J.F. wrote:
[...]
> 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
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.

do góry

Użytkownik "JDX" napisał w wiadomości grup
dyskusyjnych:56f265b2$0$695$6...@n...neostrada.
pl...
On 2016-03-23 10:19, J.F. wrote:
[...]
>> 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.

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.

do góry

Pan J.F. napisał:

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

> Oczywiscie to wbrew narzekaniom nie byly duze zmiany, no ale komputer
> odciety od sieci mogl sie po tygodniu o pare sekund przestawic.

Dla mnie są to ogromne zmiany. Zupełnie nieakceptowalne.

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

Teraz chyba już wpadli na to, by po włączeniu jednorazowo
zsynchronizować czas z serwerem. Kiedyś nawet tego nie było.

--
Jarek

do góry

JDX pisze:

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

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

do góry

Hello Jarosław,

Wednesday, March 23, 2016, 10:12:01 AM, you wrote:

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

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!)

do góry

Użytkownik "Jarosław Sokołowski" napisał w wiadomości grup
dyskusyjnych:s...@f...lasek.waw.p
l...
Pan J.F. napisał:
>>> 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.

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

>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 ?
No to wraca pelnia problemow - czas poczatkowy ustawiony z RTC,
komputer zimny i sie dopiero nagrzewa ...

J.

do góry

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.


--
AlexY
http://faq.enter.net.pl/simple-polish.html
http://www.pg.gda.pl/~agatek/netq.html

do góry