Vlákno názorů k článku
Přestupné sekundy mohou být nahrazeny přestupnou minutou, zato méně často od František Ryšánek - K> a pan Jirsák už to nakousli: když...

K> a pan Jirsák už to nakousli: když to přijde jednou za pár let, tak se s tím přeci jenom musí počítat při vývoji a testování kritického softwaru. Pokud to přijde jednou za 200 let, tak nás to při první přestupné minutě může vyhladit jak asteroid dinosaury.

Aplikace skutečně kritické na časování ve zlomcích sekundy, jedou nikoli v UTC, ale v TAI. To je stupnice, která žádné přestupné události neuvažuje, jede "furt rovně". Lidský čas pro zobrazení humanoidní obsluze se z ní odvozuje "UTC ofsetem". Pro mě nejznámějším příkladem použití TAI je IEEE1588=PTP, ale tuším jsem zaznamenal i další zmínky.

Naštěstí pro spoustu potřeb není časování kritické. Problém mezi více stroji může nastat obecně v situaci, když si nějaký software hlídá časy a řeší "integritu" běhu času. Banálním příkladem je třeba nástroj typu "make" - už jste někdy potkali hlášku, že "soubor má čas poslední úpravy v budoucnu" ? Při rychlé obrátce úprav a "buildů" by i sekunda mohla mít vliv na správné fungování.

Bohužel software, který umí přestupnou sekundu košer vložit a normálně s ní počítat, je v menšině. Třeba NTP sice transportuje avízo o přestupné sekundě, ale UNIX (POSIX?) a tuším ani ntpd ji neumí "prostě spolknout", protože třeba UNIXový "epoch time" (sekundy od 1.1.1970) s přestupy nepočítá. A máme dodnes několik různých rodin OS. Prostě není prakticky implementován jednotný způsob, jak se s přestupnou sekundou vypořádat, a různé implementace časomíry se s ní vyrovnávají každá po svém. Zpracovat minutu, která má o sekundu víc (nebo míň), to prostě dělá málokdo. Třeba zapsat do logů divnou minutu není problém, ale pak se přes přestupné sekundy dopočítat přesného rozdílu časů... ouvej. Takže ve finále všichni děláme, že přestupné sekundy nejsou - a když nějaká nastane, řeší se to jako přechodný chybový stav. Dolaďovat se dá skokem, nebo to ntpd doladí postupně podle svého naladění servosmyčky, Google to rozmázne v průběhu jednoho dne... takže den po přestupné sekundě čas různě plave a dějí se divné věci :-( Když to přizpůsobení reálně dělá každý jinak, ve vhodné situaci může nesoulad hezky vykvést. Docela by mě zajímalo, co s tím dělá třeba "high frequency trading". Jestli mají nějakou oborovou normu, nebo nařízení provozovatele burzy, že se dolaďuje skokem a basta, a že o půlnoci jsou stejnak burzy zavřené... (hmm... o půlnoci... lokální, nebo UTC? nevím.)

HFT imho nemusi* brat ohled na absolutni ani relativni cas, protoze jedine kriterium je poradi v jakem pakety dorazi ,)

*) nejspis cas otevreni a zavreni obchodovani jsou jedine kriticke mista, kde se rozhoduje zda plati ci neplati podani

Hele nevim přesně proč, ale obchodníci v HFT si na přesný čas hodně potrpí. A protože vystrčit si vlastní GPS anténu na střechu je v burzovním datacentru nikdo nenechá, řeší se to jedním z několika způsobů:
A) distribuce GPS signálu koaxovým rozvodem (zesilovače, rozbočovače)
B) historicky IRIG
C) PTP. HFT burziáni byli jedni z prvních, kdo HW PTP kupovali.

Skoro bych řekl, že ten systém při řazení požadavků bere zavděk časovou značkou z klientova počítače. Možná i proto se prodávají také softwarové systémy na monitoring synchronizace *PTP slavů*. Jakože kvůli ověřitelnosti těch časových razítek pořízených na klientech... nemám bohužel podrobné informace z první ruky. Živí mě částečně synchronizace, nikoli HFT.

Je to spis dulezite pro provozovatele burzy, kdyz tam maji vicero rozhrani tak pro urceni poradi se muze pouzit timestamp.

U PTP je moznost videt casovou znacku zdroje / doby odeslani? Nebylo to jen oznackovani prichozich paketu casem?

Základní princip fungování PTP je k nalezení třeba tady. Všimněte si obrázků se čtyřmi časy: T1, T2, T3, T4. Následuje nějaký vzoreček. Je to asi vcelku pochopitelné :-)

Ten obrázek je poněkud zjednodušený.
- když už zmínili Sync a Follow-Up, měli by zmínit vedle Delay Request + Response také Delay Response Follow-Up (když už two-step režim)
- když se vloží do hry switch, tak ten diagram dost naroste. Tuším jsem nějaké takové viděl u Cisca.

Taky může být relevantní, že na rozdíl od NTP, kde request+response je jedna transakce, ze které se spočítá čas, u PTP se čas měří každým směrem zvlášť: Sync je jeden směr (master-slave) a Delay Request+Response je druhý směr (slave-master). Delay Response paket donese slavovi jenom hotový výsledek, který se měřil ve směru slave-to-master.

Tzn. časových značek a korekcí je tam ve hře hned několik.
Stejně nakonec zůstává prostor pro reziduální chyby - třeba asymetrie přenosového zpoždění fyzické trasy může být docela peklo. Záleží, jaké máte potřeby a co jsou zač Vaše přenosové trasy. Asymetrie fyzické trasy se nedá automaticky eliminovat, pouze externě dokalibrovat a ošetřit v konfiguraci slava...

Úplně jiná otázka je myslím věc "důvěry" - důvěry v reziduální offset slava, který se "v dobré víře" snaží ofset eliminovat, dále věc důvěry ve "skutečně čisté úmysly slava" (nepodvádět) apod. Těžko budete jako burza nebo DC ke každému slavovi poskytovat svého externího slava, který toho zákazníkova slava bude nějak externě kontrolovat. Podepsat se dá řekněme zpráva od masteru pro slava, a podpis doloží pravost mastera - ale už neochtání proti "zdržovacímu útoku" apod.

Reálně co jsem viděl "monitoring PTP slavů" tak fungoval na tom principu, že se monitorovací stanice pravidelně dotazuje slavů (tuším pomocí PTP management messages) zda jsou na živu a jaký vidí okamžitý offset proti PTP masterovi. Toto se na monitorovací stanici loguje, ukládá, grafuje, hlídá, je to k dispozici k vizuální kontrole.

Ale jak by chtěl někdo garantovat, že nějaký HFT klient nevkládá do svých požadavků naschvál čas o něco dřív, než jaký má ze své časové základny... to mi hlava nebere.

Chcete-li zabřednout o patro hlouběji do formátu PTP paketů, HW značkování apod., můžeme se pokusit.

Ohledně implementací HFT softwaru nemohu sloužit. Vím jenom, že obchodníci na HFT trzích umisťují svoje "klientské" obchodující stroje do datacentra co nejblíž k burze, aby měli na její "vnější obchodní rozhraní" co nejkratší latenci. Jak je to s razítkováním požadavků (děje se na tomto klientském stroji) a s důvěrou v taková časová razítka... nemám představu.

> Aplikace skutečně kritické na časování ve zlomcích sekundy, jedou nikoli v UTC, ale v TAI.

To je super ale komplikuje interoperabilitu se zbytkem světa -- ta aplikace asi vyžaduje nějaký vstup a produkuje nějaký výstup (minimálně logy) a to čte okolí které jede v UTC (v lepším případě) nebo v náhodné místní timezone. A teď to bude o náhodný počet kolem 40 sekund ujeté.

Nikoli. Mezi TAI (a podobnými systémy) a UTC je jednoznačný přepočet (ne více než půl roku do budoucnosti a libovolně daleko do minulosti). A když je potřeba zobrazit „lidský“ čas, přepočítá se to do UTC (nebo libovolné jiné časové zóny).

Dovolím si poopravit: přestupná sekunda se aplikuje v poslední minutě 30. června nebo 31. prosince a musí být avizována 7 měsíců předem. Vyhlašuje jí IERS ve svém Bulletinu C.

Chyba je v tom „půl roku“ vs. 7 měsíců? Bral jsem to jako vyjádření řádu a nechtěl jsem řešit to, že také nějakou dobu trvá implementace do konkrétního systému. Aby mne pak někdo nenařkl, že 1. prosince ve 2 ráno počítal s tím, že v červnu přestupná sekunda nebude, a přitom neměl aktualizovaný software.

Přepočítává se to v běžných uživatelských výstupech. Jakmile třeba nějaký takový program vyvíjíte nebo ladíte a musíte se dívat na interní reprezentace (v datových strukturách v paměti, ve věcech co běhají po drátě…), tak vám to nikdo nepřepočítá.

Bohatě mi stačí že se mi produkují názvy souborů s časem v UTC a na „svůj občanský“ si to musím přepočítávat. To by mi měl předělat kdo? Mám mít na prohlížení vlastního správce souborů a na nějakou běžnou manipulaci shellem, scp, rsync… zapomenout?

6. 11. 2023, 22:44 editováno autorem komentáře

V datových strukturách to číslo je uloženo jako počet sekund, nebo třeba milisekund. Nemyslím si, že by vám nějaký software produkoval názvy souborů v TAI – a pokud ano, tak proto, že se s tím dál v TAI pracuje.

Vtipné je, že i těch časů ala TAI, kdy někdo zapíchl prst do UTC a řekl „od teď každou uplynulou sekundu přičteme jedničku“ je víc. Takže máme TAI, který je oproti UTC posunutý aktuálně o 37 sekund (jsou v něm započítané všechny přestupné sekundy od počátku věků). Pak máme GPS čas, který vznikl v roce 1980, takže je dnes posunutý o proti UTC 18 sekund. A nejspíš existují i další podobné časy.

Vztah UTC a TAI je ale obrácený - UTC se vypočítá z TAI pomocí přestupných sekund.

U GNSS to nakonec až tak rozmanité není: japonský QZSS, indický NavIC nebo SBAS mají stejnou časovou stupnici jako GPS, tedy s počátkem 6. 1. 1980; evropské Galileo má počátek 22. 8. 1999, tj. v době prvního přetečení 10-bitového čísla týdne GPS; čínský BeiDou má počátek 1.1. 2006. GLONASS je jediný, který má časovou stupnici odvozenou od UTC(SU).

Jenže zároveň UTC vzniklo dřív, než TAI. Teprve později se redefinovalo a UTC se vypočítává z TAI. Přičemž TAI je přepdokládám definováno svým začátkem v UTC…

Vy ste p. Rybka?

Úvaha: Jak chyba v algoritmu vyhladila planetu Zemi
Michal Rybka
10. 8. 2012 03:00
Prvního srpna se o hrůze rychlých, ale chybně vykonávaných příkazů přesvědčila firma Knight Capital. Na burze NYSE v době mezi 9:30 až 10:15 místního času spustili nový program pro rychloobrátkové obchodování (HFT, High Frequency Trading), který se podle všeho měl jenom testovat, ale po dobu 45 minut si hrál na skutečné burze a se skutečnými penězi. Při rychloobrátkovém obchodování se snažíte levně kupovat a dráž prodávat, což se neděje s moc velkým ziskem, pokud to ale děláte vážně hodně rychle, můžete na tom vydělávat. Algoritmus místo toho začal kupovat za vyšší cenu a prodávat za nižší a to tak, že například na nákupu a prodeji akcií společnosti Exelon v každém jednom obchodu prodělal 15 centů. Takových obchodů udělal 40 za sekundu, tedy 2400 za minutu. A samozřejmě nebyly to jediné akcie, se kterými obchodoval - podobných "obchodů" rozjel celou řadu. Protože šlo o „vytrvalé krvácení“ a nikoliv jeden vyšinutý obchod, jsou obchody platné a Knight Capital to přišlo na 440 milionů dolarů, způsobilo propad jejich akcií a zcela vážně se dostali na hranici bankrotu.

V únoru 2011 automatické HFT systémy vyrobily propad ceny cukru o 6% za jednu sekundu, o měsíc později postihlo to samé kakao (13% pokles)

https://pctuning.cz/article/uvaha-jak-chyba-v-algoritmu-vyhladila-planetu-zemi#article-header

...aha, já se tu schovávám za nickname... už jsem to napravil. Ne, s panem Rybkou se osobně neznáme. Ani se neživím jako novinář.

Co tak zrusit HFT a mame o problem menej?

Vobec nechapem preco nieco take existuje(aj dalsie podobne sposoby "obchodovania"). To nepovazujem za obchodovanie ale za spekulaciu/za­rabanie na nicom(bez vytvarania hodnoty).

Obávám se, že s tímhle přístupem bys musel zrušit tak polovinu současné lidské činnosti.