Názory k článku Jak jsem lovil přestupnou sekundu
-
bernard (neregistrovaný)
kolega napisal ntp proxy pre test leap second, mozete skusit:
https://github.com/AmadeusITGroup/NTP-Proxy
minula leap second u nas kompletna katastrofa, ale toho roku bez znamky zavahania.
bernard
-
Ondřej CaletkaZlatý podporovatelDíky, to vypadá dobře. Třeba to někdo přetvoří do veřejné služby, která třeba každé dvě hodiny přestupnou sekundu přidá a za další dvě ubere. :)
-
Filip JirsákStříbrný podporovatelDrtivá většina rádiem řízených hodin se totiž z důvodu šetření baterie synchronizuje jen několikrát denně a ve zbylém čase běží autonomně. Proto nejsou takové hodiny schopné ani hladkého přechodu na letní čas nebo zpět.
To není tak docela pravda. Informace o změně časového pásma (změna „zimní“/letní čas) a o přestupné sekundě se přes DCF77 vysílá hodinu předem. Vzhledem k tomu, že pro přestupnou sekundu jsou dvě možná okna v roce a přechod přechod „zimní“/letní čas je také předem naplánovaný, znamenalo by to nanejvýš čtyři synchronizace za rok navíc (v případě změny časového pásma by to bylo jen pro ověření, že se pravidla nezměnila a k posunu opravdu dojde). -
Ondřej CaletkaZlatý podporovatel
Já jsem netvrdil, že se to nevysílá. I příznak přestupné sekundy se v DCF77 vysílání objevuje, takže kdo chce, může pomocí DCF77 implementovat hodiny, které budou jak změnu pásma, tak přestupnou sekundu implementovat správně.
Já pouze popisuji zkušenosti s desítkami komerčních DCF77 hodin, které mám po ruce a ze kterých možná tak jedny implementují přechod na letní čas nebo zpět korektně.
-
Filip JirsákStříbrný podporovatel
Jenom jsem psal, že důvodem není to, že se hodiny synchronizují jen několikrát denně – i s takovou synchronizací lze všechna ta šoupání časem podchytit správně. Důvod je prostě ten, že za tu cenu, za kterou se ty hodiny prodávají, se nevyplatí něco takového do nich implementovat. A ti, co je kupují, zase nechtějí kvůli takovéhle „hlouposti“ investovat víc.
-
M. (neregistrovaný)
Jednak cenová stránka věci - všichni na to serou, spotřebitel to nezaplatí a aní po tom masově nevolá.
A pak i technická. Přestupná sekunda (a příhod letního času) se ohlašuje jen hodinu předem. Navíc tyto signální bity nejsou pokryty paritní kontrolou (ta bere jen vlastní datum/čas), takže musím přijmout několikrát po sobě bity v konzistentním stavu, než tomu budu věřit. A to je třeba na území celého Česka problém. Kolikrát tyto malé hodiny nechytnou správný čas ani 1x celé hodiny, natož několik minut po sobě..
Takže jim tato informace stejně může utéci.
Se spolehlivým příjmem mají u nás i přijímače na to dělané s externí anténou ve východní části země, například Meinberg krabice. Proto jsme DCF77 zcela pustili a pro nenáročné věci používáme Meinberg časové krabice s kombinovaným GPS+GLONASS příjmem. -
me (neregistrovaný)
Cenova stranka veci zde nehraje velkou roli. Jednou se to udela poradne a pak se to replikuje v tisich/milionech kusu, cena replikace je stejna. Problem muze byt testovani, tyto vyjimecne stavy se blbe testuji, je snadnejsi je ignorovat nez si poridit generator, ktery by jev generoval na prani. A vetsina zakazniku vyslednou snahu stejne neoceni....
-
ebik (neregistrovaný)
Ale hraje. Jen ne přímo. Jde o to, že cenu určuje poptávka, nikoli výrobní cena. Rozdíl mezi prodejní a výrobní cenou určuje pouze to, jaký bude zájem ze strany firem takové zařízení dělat. No a výrobní cena obsahuje i amortizované náklady na start. Firma chce aby se vrátili co nejdřív. Takže firmware musí být levně ale hlavně rychle. Pokud se bude dodavatel firmware 5 let šmrdlat s každou kokotinou, tak se počáteční náklady do 5 let od začátku projektu prostě nevrátí.
-
M. (neregistrovaný)
GPS vysílá informaci o tom, jak provést přepočet na UTC, takže i ten seznam přestupných sekund. Jinak je i možný i ten upgrade firmware, kde pak je aktualizované tz soubory.
Používáme nastavneí s normálním UTC časem a přestupnou sekundou. Jde i používat GPS a TAI čas, pokud je to žádoucí (u některých modelů je to ale třeba říci při objednání, pokud chci něco jiného, než UTC, u některých je vc volby v menu, a na každém výstupu můžu mít čas jiný). -
me (neregistrovaný)
Mam jedny DCF hodiny, ktere se synchronisuji jen jednou denne, po pulnoci. V praxi to znamena, ze po zmene casu letni/zimni potrebuji temer cely den, nez si cas opravi, takze 2x do roka temer cely den spatny cas. Programator techto hodin bud zil v pasmu kde nedochazi ke zmenam letni//zimni cas anebo neuvazoval...
-
Ondřej CaletkaZlatý podporovatel
Většina hodin, co jsem viděl já, se synchronizuje jednou denně ve 03:00 nebo 04:00, což je asi nejbezpečnější z hlediska změny časového pásma. Má to ale nevýhodu, že v inkriminovanou noc vůbec netušíte, jestli hodiny už ukazují čas podle nové stupnice, nebo ještě podle staré. Takže pokud bych chtěl třeba v neděli ráno po změně času vstávat v přesnou hodinu, rozhodně si radši nastavím krystalem řízený budík, kde změnu časového pásma předkompenzuji.
-
j (neregistrovaný)
Jenze zadnej problem neni ... z postele vylezu kdyz se rozedni a vlezu do ni kdyz se setmi ... Poledne je kdyz slunce stoji nejvejs ... a zadny dalsi casovy udaje netreba.
A jestli vedle toho nejaky vedatori potrebujou neco merit na nejaky porad stejny jednotky ... at si merej, ale at tim nezasiraj beznej provoz. Koho ve skutecnosti zajima, jestli je ted "astronomicky spravne" 9:08, 9:10, 9:11 nebo 9:15??? ... nikoho. Kupodivu lidem po tisice let nevadilo, ze nemaji kalendar zadnej, a dalsi tisice let nikomu nevadilo, ze se kalendar posunuje, ...
Sem zvedav kdy budem kazdou lichou pulhodinu kazdej treti den zarazovat prestupnou mikrosekundu ...
-
Ondřej CaletkaZlatý podporovatel
Nejen GPS. také mobilní sítě všech generací vyžadují přesný čas na desítky nanosekund.
-
j (neregistrovaný)
Ne, rozhodne nepotrebujou cas, a to tak ze vubec. Ani GPS nepotrebuje cas. Co ve skutecnsoti je pro ty aplikace treba je stabilni citac, ale nikoli cas. Natoz cas astronomicky.
Naopak, prave pouziti casu (ktery se navic snazime udrzet astronomicky spravny) namisto citace zpusobuje spoustu problemu - prave kvuli podobnym kravinam jako prestupne sekundy.
Navic neni defakto mozne trivialne spocitat pred kolika hodinami se neco stalo, kdyz ty hodiny nejsou stejne dlouhe.
-
Ondřej CaletkaZlatý podporovatel
Nojo, ale jak chcete řešit, když tyhle velmi stabilní čítače na každé části země a v každé nadmořské výšce jdou jinou rychlostí. Takže potřebujete nějaký mezinárodně koordinovaný „průměrný přesný čítač“. A to je přesně to, čemu se říká UTC, případně TAI.
-
M. (neregistrovaný)
Jenže takto GPS i řada mobilních sítí fungují. V roli toho stabilně počítajícího čítače používají TAI nebo GPS čas, který není ovlivněn aktuálním stavme Země a čítá rovnoměrně dle definice sekundy.
Nu, pak máte možnost používat čas UT1 (nebo hlazený UT1R, fajšmekří UT2), pokud nechcete být obtěžován přestupnými sekundami a máte klid, budete do +/-0,9 s ve shodě s UTC časem. :-)
Problémem časových intervalů je stále stejný i s UT1. Sice u UT1 snadno spoččítám rozdíl dvou časů, ale nedokážu přesně určit, jak je tento rozdíl ve skutečnosti dlouhý z pohledu plynutí času, ocž zase u řady aplikací působí problém, zvláště pokud mám proovnávat doby trvání různých dějů.. -
Radovan (neregistrovaný)
"ve skutecnsoti je pro ty aplikace treba je stabilni citac"
Takže jako stabilní čítač použijeme dvoje naprosto stejné atomové hodiny, které celé roky ukazují naprosto shodný čas. Pak uděláme experiment, naložíme je do dvou letadel, a pošleme na cestu kolem světa v opačných směrech. A jaké je naše překvapení, když po přistání a porovnání zjistíme že každé hodiny jdou jinak...!
Tenhle experiment proběhl snad někdy v šedesátých letech, a dokázal že teorie relativity funguje. Také dokázal že jenom čítač opravdu nestačí, je potřeba přesná pravidelná synchronizace.
-
Sten (neregistrovaný)
Poledne je kdyz slunce stoji nejvejs
A aby to zůstalo, tak se občas musí vložit přestupná sekunda.
Koho ve skutecnosti zajima, jestli je ted "astronomicky spravne" 9:08, 9:10, 9:11 nebo 9:15??? ... nikoho
Každého, kdo jezdí MHD
Kupodivu lidem po tisice let nevadilo, ze nemaji kalendar zadnej, a dalsi tisice let nikomu nevadilo, ze se kalendar posunuje
Vadilo, proto také Julius Caesar zavedl kalendář bez mensis intercalaris a papež Řehoř ⅩⅢ ho upravil, aby vyrovnal i posuny patrné až během staletí.
-
Jenda (neregistrovaný)
…za 3000 let. Zatímco teď je při daylight saving time ve 13:15. Nebo taky ve 14:45 nebo 11:30. https://en.wikipedia.org/wiki/Time_in_Europe
-
NA (neregistrovaný)
Pro každé časové pásmo současně běží tři časy.
1) technický = čítač přičítá časové úseky. Závisí na něm třeba GPS a počítače.
2) astronomický = Má / snaží se mít poledne když je slunce v nadhlavníku a nový rok vždy na stejném místě oběžné dráhy. Ten potřebuje přestupný čas (resp. odlišné pojmenování časových úseků) a vychází z něj kalendář. Bohužel není rovnoměrný.
3) politický (oblbovači mu říkají občanský) = Vnáší blbosti odporující realitě jako je třeba letní švindlčas a Říjen v listopadu.Ty první dva potřebujeme pro fungování techniky a společnosti.
-
Lael Ophir (neregistrovaný)
Což má ten zajímavý důsledek, že se zemědělské události (setí, sklizeň) jsou každý rok k jinému datu. A přitom zrovna pro účely zemědělství ty první kalendáře tehdejší civilizace vytvářeli. Z toho důvodu už například izraelité zavedli "přestupný měsíc", Adar Bet.
Další problém shody astronomického (řekněme zemědělského) a občanského času nastává s časovými zónami. Pokud jako poledne označíte čas kdy je slunce v rámci dne nejvýš nad obzorem, nastává celkem problém, protože astronomické poledne je v každém místě jindy, a ještě se to mění v průběhu roku. Plánovat pak například jízdní řády železnice je velmi komplikované. Dalším problémem jsou přenosné hodinky. Tyhle problémy vedly k zavedení časových pásem.
Jinými slovy všechny ty "nesmyslné" komplikace s časem mají velmi dobré důvody.
-
robotron (neregistrovaný)
Take jsem si pred par lety zalovil: https://www.youtube.com/watch?v=Fx9bas49Uow
-
robotron (neregistrovaný)
Jeste 2 drobne poznamky:
- chlapik z NPL UK myslim zpochybnoval, ze by trend v pridavani sekund byl skutecne zpusoben zpomalovanim Zeme; zdroj: Splitting a second: story of atomic time; (jasne, z hodne dlouhodobeho hlediska a rustu entropie by se zpomalovani melo konat, ale pry Zeme po dobu existence UTC spis zrychluje, nebo rozhodne nezpomaluje tak rychle, jak by se zdalo podle vlozenych sekund);
- Wharton? Opravdu? Mel jsem za to, ze hodiny pro CRo dodaval pan Vladimir Andel, asi nejznamejsi ceskoslovensky tvurce DCF77 prijimacu a instalaci v prumyslu.
-
JA (neregistrovaný)
Myslim, ze autor se uz dalsi prestupne sekundy nedocka, protoze vetsina predstavitelu z ISO se pry (nutno dodat, ze zcela logicky!) vyjadrilo proti, protoze to zpusobuje problemy na hloupych systemech ..... nutno dodat, ze prakticky vyhradne unixovych.
Je vcelku smesne, ze takovy redhat se musel aktualizovat, aby nahodou .... pritom unixovy timestamp nic jako prestupne sekundy nezna ..... ale treba stupidni python zna dokonce dvojitou prestupnou sekundu (ktera nikdy nebyla, ani nebude) ..... proste je videt, jak nekteri lidi hledaji problemy tam kde nejsou ..... pritom treba vsechny systemy a vsechny interni procesy a aplikace od microsoftu nic takoveho neznaji .... proste se (zcela logicky) tvari, ze zadna prestupna vterina neni, system ji proste nezna! Cili ji ignoruje a pri dalsim NTP requestu se proste upravi systemove hodiny .... jak genialni:o)
Kdezto zaslepena stupidita unixovych vyvojaru k idiotskemu perfekcionalismu (spis by se asi hodilo jine slovo) vedla k obrovskym problemum a pritom stacilo k problemu pristoupit inteligentne (jak to treba udelal microsoft) ......
Ale uplne nejvic me pobavil gugl (na tomhle pripadu je krasne videt, ze se nikdy nemel gugl poustet do programovani radobyoperacnich systemu, proste na to nema mozkovny), kdyz pry den predem posouval cas kazdou chvili o milisekundu:o) To proste blbemu nevysvetlis:o)Opravdu by me uprimne zajimalo, kterou "chytrou hlavu" napadlo implementovat prestupnou vterinu do IT sveta ... hodiny realneho casu OS se inkrementuji porad, univerzalni (dokonce i unixovy) cas je porad stejny .... akorat fyzicky(!) pribyla jedna vterina. Prave kvuli casovym posunum se zavedl UTC, ktery neresi posuny letniho a zimniho casu nebo casove zony .... taky existujou prestupne roky ...... to vsechno se da pochopit a racionalne vysvetlit .... FYZICKA prestupna vterina je uz obhajitelna opravdu hodne tezko, ale budiz ..... ale to, ze si nekdo da tu praci a uplne nesmyslne horkojehlovou implementaci zanese zcela nelogicky proti rozumu problem do operacnich systemu, to mi opravdu hlava nebere ...... nenapada me (a vlastne nikoho) jaka mela polovicata implementace prestupne vteriny v unixu smysl (krom Y2K, aby se par firem napakovalo, pak ANO), proste neexisuje zadna aplikace, kde by to melo smysl ...... sak taky kvuli unixu/linuxu chcou v ISO a NASA do budoucna prestupne vteriny uplne zrusit, respektive pry hodlaji "tajne" upravit cas jenom na hlavnich NTP a GPS a fuck off .... protoze kdyz to daji vedet takhle dopredu, zacnou do toho unixovi neznalci rypat a jsou pak problemy .... takhle si proste jenom unixovy server v naplanovany cas upravi zcela regulerne vnitrni hodiny a do te doby se bude tvarit, ze se o vterinu predbiha ..... big whoop, koho to zajima? NIKOHO!:o) Kdyz to nezverejni, tak nikdo ani nezjisti, ze se nejaka vterina pridala ..... mozna po par pridani zacne par majitelu super drahych hodinek s cesiovym strojkem remcat, ze se jim predchazeji, LOL:o)
-
Ondřej CaletkaZlatý podporovatel
Myslim, ze autor se uz dalsi prestupne sekundy nedocka, protoze vetsina predstavitelu z ISO se pry (nutno dodat, ze zcela logicky!) vyjadrilo proti, protoze to zpusobuje problemy na hloupych systemech ..... nutno dodat, ze prakticky vyhradne unixovych. [Zdroj?]
Tohle se tvrdilo i po té předposlední sekundě…
proste se (zcela logicky) tvari, ze zadna prestupna vterina neni, system ji proste nezna! Cili ji ignoruje a pri dalsim NTP requestu se proste upravi systemove hodiny .... jak genialni:o).
Jasně, takže místo přesně určeného skoku v okamžiku, kdy k němu má dojít, dojde k obdobnému skoku v náhodný okamžik, podle toho, v jakém stavu jsou zrovna NTP časovače… jak geniální… :|
Dál už jsem radši nečetl.
-
Lael Ophir (neregistrovaný)
Ad dojde k obdobnému skoku v náhodný okamžik - nedojde k němu vůbec. Když Windows detekují malý rozdíl mezi lokálním a sítovým časem, provedou změnu rychlosti lokálních hodin tak, aby se bez časového skoku dostaly do shody se síťovým časem. Jen pokud je změna výrazně větší, dojde ke změně času skokem. Na doménovém serveru a stand-alone klientech se by default skokově synchronizují změny větší než 1 sec, na klientech větší než pět minut.
https://technet.microsoft.com/en-us/library/cc773263(WS.10).aspxAplikace ve Windows navíc nespoléhají na to, že lokální čas monotónně roste. Používají funkce QueryPerformanceCounter() a GetTickCount64(). Výjimkou mohou být aplikace portované z Unixů, případně psané nemehly :)
-
m (neregistrovaný)
Jestli se skokem opravuje chyba větší než jedna sekunda, tak po přestupné sekundě to bude v průměru platit alespoň pro polovinů klientů, ne? Nějaká část je napřed o víc jak sekundu, nějaká (menší) část je pozadu o víc jak sekundu a zbytek (pro který se neudělá oprava skokem) je někde mezi tím.
V tom článku co odkazujete se píše, že ten NTP klient neumí držet přesnost hodin lépe jak na pár sekund, tak je to asi stejně jedno. Snažit se řešit nějak rozumně přestupnou vteřinu u hodin s takovou přesností by dávalo asi stejný smysl jako posunovat náramkové hodinky.
Jinak referenční NTP implementace (ntp.org) na Windows řeší přestupnou vteřinu docela pěkně, hodiny se zpomalí na polovinu po dobu dvou sekund.
ČLÁNKY DO MAILU