Příspěvky

931

Hardware / Re:Domácí automatizace - hlavice k topení

« kdy: 21. 01. 2019, 10:34:05 »

Tak asi takhle... Manželka si udělala vedle průjezdu v kumbále nehtový studio (ze třech stran barák, venkovní strana plastový dveře, okýnko s dvojsklem, Porothermy a 10cm polystyrenu). Dvě podobný zimy po sobě, fixovaná cena plynu. Rozdíl mezi oběma zimama byly MT4 + hloupý termostat od Elektrobocku v táhle jedné cimře (testoval jsem to, ve zbytku baráku to ještě nebylo), rozdíl cca 2300. Hlavice 1300, termostat low cost za 300 a pár drátů, co se válely doma.

To by mě ještě zajímalo, jestli je to v přízemí, jak vypadala izolace odspoda (podlaha a základy proti podloží nebo do sklepa). Ve starším domě asi nic moc. Tam pak dává smysl, netopit do matičky země.

Další věc je komfort. Dokud v baráku byl jenom jeden termostat v obýváku, tak v zimě při pečení se vyhřálo přízemí a nahoře v patře, kde netopila trouba, to padlo na 12°C a nebylo boha, který by zapnul kotel, bez průvanu v přízemí.

Jojo. Teoreticky je řešením, mít obyčejnou termohlavici na každém topném tělese = v každé místnosti. Ale pak taky bacha na to jaký máte kotel, jak moc se dá jakožto zdroj tepla regulovat = o kolik se dá přiškrtit z maximálního výkonu a jak dlouho trvá, než zhasne. Třeba uhelný kotel bych se bál připojit na rozvod, kde jsou na všech radiátorech termohlavice. Jo kdyby byl v systému ještě pořádný bojler, nebo spíš tepelný zásobník = nádrž několika m3 vody, kterou plná nálož uhlí ohřeje o 10*C, tak bych se asi nebál :-) Plyn je asi v poho, elektřina naprosto.

932

O serveru Root.cz / Re:Zpomalené forum.root.cz a ostatní stránky

« kdy: 19. 01. 2019, 20:21:21 »

A lidi, co mají normální operační systém [...]
 Ti jsou toho ušetřeni?

No právě že ušetřeni nejsou, pokud mají v síti kolegu / člena rodiny, který má náhodně sosající Windowsy.

Takže pokud máte normální operační systém, naučte se nastavit v desítkách kolegům/příbuzným bandwidth limit Windows Update. Asi si na to vyrobím cucek s příponou .reg pro přímý import do Windows Registry. A asi ještě batovku s
net stop wuauserv
net start wuauserv
net stop bits
net start bits

Ohledně BITS si nejsem jistý, spíš to vypadá, že se ho to netýká.

Jo a abyste vůbec zjistil, kolik uhodilo, je dobré mít na svém CPE routeru iptraf.

933

O serveru Root.cz / Re:totálně zpomalé forum.root.cz a ostatní stránky

« kdy: 18. 01. 2019, 22:54:08 »

tytéž příznaky pozorované lidmi porůznu v internetech proti různým webíkům.

MŮŽEŠ TO vysvětlit? porůznu a proti?

Různí lidé připojení do širého Internetu u různých ISP si stěžují na totéž: "nějak mi to brouzdání dneska drhne. Popravdě spíš asi poslední tejden. Chvíli je líp, chvíli hůř." A když se náhodou sejde pár takto postižených na Rootu, tak pokládají adminům Roota záludné otázky, jestli náhodou není něco shnilého ve státě dánském. A když se sejdou na ATčku, tak se kvůli "přizadrhávání ATčka" zlobí na ATčko. No - shnilého cosi jest, ale nikoli na rootu, nebo $si $dosaďte prakticky jakýkoli jiný webík. Problémem může být Windows Update. A pokud to není Váš osobní počítač, který sosá Windows Update tak že ucpal celou WAN linku, tak je to třeba nějaký kolega v práci nebo spolučlen domácnosti.

Přitom v SoHo prostředí asi není řešením, rozjet si WSUS server. (Nepotřebuje náhodou doménu / Active Directory?)

Existuje možnost, trochu widlím tu jejich rozežranost přiškrtil. Jsou dva základní způsoby:

https://www.thewindowsclub.com/limit-windows-update-bandwidth-windows-10

1) v desítkách počínaje "fall creator's update" je přítomno takové táhlo, kterým lze nastavit bandwidth limit v "procentech". Nikde není pořádně vysvětleno, v procentech *čeho*. Asi v procentech rychlosti fyzického portu? Takže když se ke svému domácímu routeru připojíte gigabitovým Ethernetem, tak v defaultním nastavení (50%) se windows patrně pokusí, sežrat 500 Mbps... což má dneska doma každej z nás, žeano :-)

2) ve windowsech "profíkách" se dá nastavit v "group policies" (gpedit.msc) omezení rychlosti downladu updatů. Pozor, to číslo je v kiloBajtech za sekundu!

V češtině:
Konfigurace počítače -> Šablony pro správu -> Součásti systému Windows -> Optimalizace doručení ->
    "Maximální šířka pásma pro stahování (kB/s)"

Ono se na to dá sáhnout taky regeditem:
HKLM\SOFTWARE\Policies\Microsoft\Windows\DeliveryOptimization\DOMaxDownloadBandwidth  (REG_DWORD)

Viz též:
https://getadmx.com/?Category=Windows_10_2016&Policy=Microsoft.Policies.DeliveryOptimization::MaxDownloadBandwidth

(Mimochodem hodně dobrej webík, tenhle getadmx.com .)

Ať už nasadíte libovolné škrtící opatření, doporučuji po úpravě konfigurace restartnout servisky Windows Update a "službu inteligentního přenosu na pozadí" (BITS).

934

O serveru Root.cz / Re:totálně zpomalé forum.root.cz a ostatní stránky

« kdy: 16. 01. 2019, 16:31:00 »

...tak že asi zase někomu torrentuje Windows Update v desítkách...

No a dneska zas. Takže traceroute na zlobící web, ping na default GW u ISP, na poslední IPčko v AS našeho ISP, a nekonečný ping na cílový server. Velkými pakety (1472 B).  Aha, výpadky začínaly u našeho ISP. Máme pásmo ořízlé rate-limitem. Takže jsem ty pingy nechal běžet a vedle nich jsem si pustil iptraf-ng na svém firewallu a šmejdil jsem, kolik teče zvenku (po strop) a kolik teče kam dovnitř. A dohledal jsem počítač, na kterém se uživatel snaží nainstalovat Windows 10 update 1803 a dokola mu to selhává. Po každém selhání se Windows pokusí to znova downloadnout. A žerou pásmo jak BT klient = otevřou mnoho TCP relací najednou, aby zváhly "fair queueing" ve svůj prospěch. Ostatním pak browzdání skomírá.

Nebyl nedávno nějaký větší update desítek? To by vysvětlovalo tytéž příznaky pozorované lidmi porůznu v internetech proti různým webíkům.

935

O serveru Root.cz / Re:totálně zpomalé forum.root.cz a ostatní stránky

« kdy: 14. 01. 2019, 21:31:37 »

Taky se mi kolem poledního chvíli posmívali kolegové, že "mi nějak polehává ten ynternet". Tak jsem jim odvětil že jsou trubky, a pokud ne, tak že asi zase někomu torrentuje Windows Update v desítkách... a pustil jsem si asi tři pingy: na default GW u ISP, na ATčko které konkrétně bylo chvilkami unreachable, a na 8.8.8.8 (se rýmuje takové dětské říkadlo). No a výsledek byl, že jsem od té chvíle neztratil ani ping. A to mám pocit, že stejného ISP se mnou (autonomní systém) má málokdo tady odsud.

Můj sumární dojem: nějaké větry v BGP.

936

Server / Re:Loadbalancing NTP serveru

« kdy: 14. 01. 2019, 12:52:20 »

@M.: díky za další podrobnou reakci :-)

Nepatrná grammar nazi korekce: ten co dostane v ntpq hvězdičku se oficiálně jmenuje "sys-peer" (ve shluku přesných kandidátů něco jako "čestný předseda"). "prefer" je fakt jenom argument v konfiguráku.

Na keyword "true" jsem se zeptal technické podpory. Vzhledem k tomu, jak je poslední týden zkouším z obtížných témat, odpověď možná nebude dneska ;-)

Tahle debata se mi strefila zrovna do nějakého pracovního úkolu, kde řeším distribuci času v nějaké rozsáhlejší WAN: na periferních lokalitách GPSkové NTP servery s backupem přes NTP na pár centrálních lokalit. "Prefer" keyword u lokálních GPS přijímačů vypadá jako hodně dobrá finta proti systematické asymetrii přenosového zpoždění u záložních NTP uplinků. Za normálních okolností lokální GPSka vyhraje volby i když s ostatními o fous nesouhlasí, ale není tím dotčeno její vyřazení jakožto falsetickera, pokud si začne moc vymýšlet (nesoulad se záložními NTP servery překročí jakousi hranici). V takové situaci si pak periferní lokality musí vystačit s přesností NTP over WAN, o kterém už víme, že může mít offset trochu zatížený asymetrií přenosových zpoždění - která závisí na zátěži ostatním provozem. Asi lepší než drátem do oka.

S tou asymetrií by možná trochu pomohla priorizace NTP provozu v queueingu na síťových elementech "na vstupu do úzkého hrdla" (což může a nemusí být problém v jiných ohledech, ať už se bavíme o L3 nebo o L2).

Kladivem na asymetrii je protokol IEEE1588 (PTP), pokud ho síťové elementy po cestě podporují (aktualizují pole "korekce" v PTP paketech). Tohle kladivo je bohužel docela drahé a jeho Best Master Clock Algorithm bohužel nedosahuje úrovně vychytralosti v třídění a kombinování více upstream zdrojů, kterou známe z NTP. On se bohužel PTP a jeho BMCA pohybuje s jitterem o tři-čtyři řády níž než NTP a asi tam při rozhodování hrají roli jiná hlediska, zejména rychlost konvergence, a třeba taky implementační jednoduchost klientů. Nemluvě o dosud probíhající evoluci PTP (a to "ve více vláknech" - viz ptp "profiles" a ani to zřejmě ještě není konec příběhu o babylónské věži).

937

Server / Re:Loadbalancing NTP serveru

« kdy: 13. 01. 2019, 21:07:34 »

V tom prvním kroku se napřed provede základní "sanity checking" nakonfigurovaných asociací, a následně se hledá "interval překryvu pro maximální počet asociací". Kdo se tohoto maximálně četného překryvu neúčastní, stane se falsetickerem...? Přesné blízké zdroje času dostanou pro potřeby tohoto algoritmu "rozhodnutím strany" určitý minimální rozptyl ("mindist", default 1 ms) aby získaly lepší "koaliční potenciál" a nevypadávaly rovnou jako falsetickers.

No a ve druhém kroku se jedná opět o jakýsi clustering, ale tentokrát nikoli prostým překryvem, ale iterativním odlupováním nejodlehlejších jedinců... dokud nenastane ukončující podmínka. Pokud správně chápu popis.

Poznatky ohledně "prefer" a "true" myslím platí beze změny.

938

Server / Re:Loadbalancing NTP serveru

« kdy: 13. 01. 2019, 20:24:30 »

Hmm... ještě jednou koukám na popis "clock select algoritmu" a řekl bych, že ten můj popis opsaný z prvního odstavce dokumentace zřejmě nesedí.

V prvním kole (tzv. clock select algorithm) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.

Odkazovaný HTML dokument mi přijde interně nekonzistentní, nebo přinejmenším hrubě zkratkovitý. Jsem z toho daněk.

939

Server / Re:Loadbalancing NTP serveru

« kdy: 13. 01. 2019, 13:17:13 »

@M.: hezky...
V tom prvním výpisu mě překvapuje, kam zmizel ten offset okolo 1.5 ms.
Protože round-trip delaye jsou jenom nepatrně nižší, než v předchozím výpisu (provoz přes den).
Případně by bylo zajímavé vědět, kolik z toho delaye je "stabilní základ" a kolik jde na vrub prodloužení front při silnějším provozu (potenciálně asymetrickém).
Přijde mi nepravděpodobné, že by ten rozdíl v delayích zmizel prostě jenom nastavením "prefer" objektivně nejbližšímu upstream serveru.

Cold boot má trvat v optimálním případě asi 12 minut, protože tak dlouho trvá přijetí úplného almanachu z družic (pokud v příjmu nejsou chyby). Meinberg nepodporuje stažení almanachu z Internetu (svého druhu assisted GPS, pokud se nepletu). Následuje "warm boot", který už může být docela rychlý - pokud se nepletu, v průběhu (nebo až na konci?) warm bootu už má přijímač poziční fix a čas. V zásadě se ještě čeká na konstalaci s použitelným DOP (tuším pod 2.5) = družice na "kolmých" směrech, aby se minimalizovala trigonometrická chyba v "průniku kulových ploch". V momentě kdy toto nastane, rozsvítí se stavová kontrolka GPSky zeleně. Pro potřeby NTP je to vše. Pokud je v systému PTP grandmaster, tak se ještě čeká na event "oscillator adjusted" - zmíněný oscilátor je sice v přijímači GPS, ale PTP grandmaster čeká na jeho plný závěs, teprve pak totiž začne v protokolu PTP deklarovat přesnost "<100 ns".

Takže oni Meinbergové cpou GPS refclocku dokonce "true"? No... ono to dává smysl, když přidat alternativní upstream NTP servery do konfigurace ntpd jde u MRS sestav už jenom oklikou, a primárním způsobem závěsu na upstream NTP server je cesta skrz MRS = podle záložního NTP se v případě výpadku příjmu družic (volně) dolaďuje oscilátor přijímače, o čemž ntpd na x86 CPU kartě nemá ani potuchy. Z mého pohledu je to škoda, padají tím totiž výhody toho "dvoukolového prosévacího algoritmu" (MRS tohle neumí) - v odůvodněných případech lze přesto upstream ntp servery do ntp.conf dodat ručně. Tzn. je dobré o těchto nuancích vědět a umět si vybrat. Ještě zkusím zjistit, jestli lze odstranit "true".

A ještě:
> Clock / GPS Clock / Enable Outputs / Pulses : If Sync
To se podle mého netýká interní PPSky pro CPU kartu. Toto se týká programovatelných pulzních výstupů, které jsou samostatně vyvedené ze šasi (na konektory na panelu). Resp. mohou být - jedná se o factory option. Tyto výstupy umí krmit přímo Meinbergovic karta přijímače, lezou z jejího FPGA. (V modulárních IMS sestavách se dále vyskytují přídavné karty jako CPE180, které mají vlastní podružný oscilátor a FPGA a programovatelné výstupy.)

940

Server / Re:Loadbalancing NTP serveru

« kdy: 12. 01. 2019, 08:53:18 »

@M. : ta poslední tabulka je boží :-) Tím Vás nechci nijak poňoukat k dalšímu popisování detailů Vaší sítě, myslím že jich bylo až dost... Vaše závěry jsou přesné. Já bych snad jenom zdůraznil, že je z toho hezky vidět, jak snadno by se mohlo stát, že partička upstream serverů, které mají offset zatížený shodnou systematickou chybou (sdílené úzké hrdlo v konektivitě s asymetrickou zátěží?) může přehlasovat objektivně mnohem přesnější blízký zdroj času :-)

Ony ty podrobnosti skutečně vyplavou na světlo až ve větší množině upstream serverů. Mimochodem všechny servery ve Vaší konfiguraci mají záporný offset. A ta "shluknutá skupina" co vyhrála hlasování má ofset asi o 1.5 ms zápornější než nešťastný outlier. Což by podle mého mělo znamenat, za jinak stejných okolností (pokud se asymetrie na linkách v čase nějak nezmění) že se "náš" ntpd bude snažit ten offset vynulovat postupným doladěním lokální časové základny. Tzn. v ustáleném stavu by "skupina co vyhrála hlasování" skončila rovnoměrně rozmístěná okolo ofsetu 0 a nešťastný NTP1 by skončil s reportovaným ofsetem asi +1.5 ms.

Taky jsem se sám ještě trochu poučil četbou dokumentace. Konkrétně jsem se napřed zajímal o přesný význam těch znamének na začátku řádku NTPq. (Popisuje to asi třetí HTML tabulka od uvedeného relativního odkazu.) Vím dávno, že hvězdička na začátku znamená "vítěz" a plus na začátku znamená "finalista - účastník váženého průměru", ale co znamená třeba mínus? To je ten co musel z kola ven? No a zjistil jsem, že "outlier" (znaménko mínus = Váš případ) není totéž jako falseticker (znaménko "x"). Ten ověřovací a shlukovací algoritmus je totiž dvoukolový.

V prvním kole (tzv. clock select algorithm) se nahrubo oddělí zrno od plev. Vyházejí se upstream servery, jejichž offset je větší než polovina round-tripu + směrodatná odchylka jitteru.

V druhém kole (tzv. clock cluster algorithm) dojde na jemnější shlukování - a outlier je server, který se dostal do druhého kola, ale jeho "interval pravděpodobných hodnot" (střední hodnota ofsetu +/- směrodatná odchylka jitteru) stojí mimo většinový shluk. A právě toto se stalo nejbližšímu serveru na stratu 1 :-D

Mám experimentálně nepotvrzený dojem, že rozdíl mezi oběma případy (fázemi vyhodnocení) bude v účinku klíčového slova "prefer". Jasný falseticker bude vyloučen i v případě, že má v konfiguraci slovo "prefer". Ale prostý outlier by s "prefer" argumentem patrně zvítězil :-)

Přiložím jeden screenshot. Zajímavé je, že lokální rádiem řízené hodiny nemají znaménko "o" (PPS peer), ale prázdné pole " " - což podle tabulky znamená "peer invalid". Tak mám dojem, že jsem ten screenshot típnul příliš brzy po startu stroje - ono chvíli trvá, než je refclock driver "spokojený". Patrně vstupní signál napřed chvíli sleduje a hledá případné nekonzistence, a ostatně jádro ntpd se refclock driveru taky ptá s delší periodou než 1/s. Nebo tam mají Meinbergové pod kapotou něco čemu nerozumím. Kromě toho se jednalo o hodně nový firmware na hodně starém hardwaru... A kromě toho dnešní Meinbergovic firmware už NEobsahuje dva pseudo-samostatné refclock drivery: pro ToD na sériovém UARTu driver "parse" + zvlášť PPS refclock 0, ale jenom jeden driver, který má podporu PPS integrovanou. Takže názvoslovně už nejedná o čistý PPS refclock. Hmm... na tohle se asi ještě zaměřím. Brzy bude příležitost.
Vlastně jsem chtěl ještě dodat, že interní GPS/PPS refclock má u Meinbergů (a zřejmě i jinde) vždycky právě prefer keyword. Resp. samostatný PPS refclock míval tradičně nějaké úplně specifické zacházejí, jako že "PPS má vždycky pravdu a vždycky offset 0".

941

Server / Re:Loadbalancing NTP serveru

« kdy: 10. 01. 2019, 22:43:38 »

@M.: díky za názorná čísla :-)

Koukám že ten výsledek ve virtuálu nevypadá vůbec špatně... jitter 35-40 mikrosekund. Hezké.

A ten první výpis, kde je záporný offset asi půl milisekundy... pokud by tam bylo v sérii několik relativně pomalejších opto-převodníků, tak by to snad i mohlo něco vysvětlovat. Kabeláž od GPS antény k přijímači bych nepodezíral, protože 5 ns na metr, a těch metrů anténního svodu nebude moc. I kdyby stometrový svod, pořád jsme na 500 nanosekundách, to je o tři řády míň než ta cca půl milisekunda.
Ale jestli je tam dopravní zpoždění nějakých 12 ms, tak by tam mohla být cca půl ms asymetrie (ntpd počítá se symetrickým přenosovým zpožděním). Mimochodem si myslím, že by to asi šlo i dokompenzovat - třeba argumentem "bias" na řádku v ntp.conf?

942

Server / Re:Loadbalancing NTP serveru

« kdy: 10. 01. 2019, 08:52:52 »

Má smysl provozovat NTP servery ve virtualizaci? Dejme tomu ve vmware. Nějak podvědomě mám pocit, že by to nemusel být úplně dobrý nápad ve smyslu dopadu na přesnost. Nijak systematicky jsem se ale tou problematikou nezabýval, takže se možná pletu.

NTP ve virtuálu: jasně že to není správně, ale pro někoho má virtuálka zřejmě praktické výhody, takže se výrobci hypervizorů zřejmě dost snaží, aby to až tolik nebolelo. Ono se to tady už probíralo :-) a možná ne jednou.

Používám veřejné stratum 1 servery od CESNETu, CZ.NIC a UFE AVČR - Národní časové laboratoře a uvnitř LAN mám pár NTP serverů, které jsou na bare metal strojích.

To mi přijde jako rozumná kombinace. Nezkoumal jsem, ale v téhle množině by měl být k nalezení alespoň jeden server, který nekolabuje přetížením. Konkrétně CZ.NIC si dává dost záležet na průchodnosti poskytované infrastruktury.

V rovině "zážitků z natáčení" (jedna paní povídala) jsem zaslechl o národním etalonu času v jedné východoevropské zemi, kde si postavili veřejný NTP server, a po zveřejnění IP adresy jim za nějakou dobu začla "záhadně" kolabovat IP konektivita do sídla dotyčného úřadu - příčinou byl právě nápor NTP dotazů zvenčí.

943

Server / Re:Loadbalancing NTP serveru

« kdy: 10. 01. 2019, 00:53:12 »

(Jsem ve střetu zájmů: tento obor mě živí.)

Děkuji M. za zmínku o značce Meinberg :-) Mimochodem ten Geode na 500 MHz zvládne bez autentikace zodpovědět 10k NTP transakcí za sekundu. Slušně vychovaný NTP klient se ptá jednou za desítky sekund až jednotky minut (pseudonáhodný interval). Takže spíš stovky tisíc slušně vychovaných klientů. Ale jak M. a další správně píšou, zdaleka ne všichni NTP klienti jsou zdvořilí a inteligentní.

Geode má tu výhodu, že jak CPU tak zbytek čipsetu (sběrnice) jsou jednoduché jako koloběžka = má to krátké a deterministické latence, což je optimální podvozek, pokud Vám jde o přesnost, minimální jitter. Ntpd běžící na Geodovi s kvalitní GPSkou vidí jitter PPS vstupu běžně do 1 mikrosekundy = na hranici toho, co dokáže ntpq vůbec nahlásit. Dnešní výkonnější procesory s košatým stromem PCI-e sběrnic, message-signaled interrupty apod. může mít determinismus latence obsluhy IRQ citelně horší. Jinak se říká, že NTP dokáže za ideálních podmínek (nezatížený Ethernet, Linux a v něm plnohodnotný ntpd na klientu i serveru) dosáhnout přesnost cca 20-50 us.

Popravdě zmínku, že někdo zkouší load-balancovat NTP nějakým generickým "content switchem", to slyším prvně :-) U NTP jde o časování (minimální jitter, minimální rozptyl round-trip zpoždění) a u jednotlivé NTP asociace může mít smysl, aby transakce po sobě jdoucí se ptaly vždycky téhož upstream serveru. Pokud se totiž servery v clusteru trochu rozejdou, a ten balancing je per transaction (nikoli per NTP "session") tak to bude z klienta vypadat, jako že syntetický balancovaný server má hrozný jitter. Pravda je, že u load-balanced clusteru bych předpokládal, že servery budou mít mizivý vzájemný offset, protože budou někde pohromadě a budou mít optimálně shodný upstream zdroj...

Máte-li v síti nějaké NTP klienty, kteří jsou tupí a nevychovaní, a máte důvodné obavy, že by mohli vymazlené rádiem řízené servery na stratu 1 poslat za určitých okolností do kolen, není nic jednoduššího, než vyrobit pro ně 1-2 nebo více serverů na stratu 2. Linux, ntpd nebo Chrony (podle osobní libosti), pár řádek v konfiguraci, hotovo. Pokud pro stratum 2 použijete nějaké trochu výkonnější železo než je Geode, tak tyhle servery budou mít i lepší šanci ustát "DoS příval" než Geode nebo ARM apod. v rádiem-řízeném serveru. Kromě toho na "Meinberga" už případný "zombie útok zvlčilých SNTP klientů" především vůbec nedoputuje, což je hlavní cíl. Vanilkový ntpd tuším dodnes jede v jediném vlákně (a není úplně trivka to rozložit na víc jader) takže nemá smysl postavit na tuhle pozici 12jádrový Xeon. Ale ono i Core2Duo nebo nějaký moderní BayTrail ATOM tomu Geode natrhnou tričko (za cenu vyššího topného výkonu, pochopitelně).

Mimochodem Meinbergové dokázali to rozvláknění nějak pořešit po svém - prodávají nějaký vcelku béžový 1U server se svým vlastním Linuxem, který zvládne snad 320k Tps (80k jedním vláknem) a servíruje to softwarově. Kromě toho mají Meinbergové modul PTP grandmasteru s FPGA implementací PTPv2 nebo NTP - tenhle modul zvládne hardwarově odpovědět taky na cca 300k NTP Tps, při spotřebě asi 5W a při přesnosti časových značek někde v desítkách ns (dáno přesností GPS přijímače, který tomu dodává referenci = PPS a 10 MHz). Má to nějaké další technické nuance, každopádně cenovky jsou lehce astronomické.

Zpátky na zem. Tzn. nejlepší "NTP balancer" je IMO dedicated serveřík pro stratum 2 s Linuxem (nebo jestli má někdo radši BSD, vyjde to asi podobně). Nebo servery dva, aby se vzájemně zálohovaly. A nepotřebují mít mnoho jader.

Nabízí se nápad, vyrobit to stratum 2 ve virtuálu - tohle se už tuším tady probíralo, že tradičně NTP ve virtuálu je hřích, ale novější informace říkají, že už to v nových verzích hypervizorů není taková hrůza jako bývala. Osobně bych doporučil vyhradit "NTP virtuálu" celé CPU jádro, pokud už se tím chcete zabývat. A jako guest OS (nebo na holém železe) pro běh ntpd/Chronyho každopádně nějaký Linux. Jestli si pak ještě zkusíte hrát s podporou high-resolution timerů (nevím zda to pro ntpd má smysl) nebo zkusíte real-time kernel, to už je čistě na Vašem vkusu a zálibách. Ale i běžné distribuční jádro poskytne rozumnou službu.

Někdo taky provozuje stratum 2 na páteřních switchích LAN (větší Cisco apod.) - je asi věcí posouzení rizika, jestli to neohrozí management CPU přetížením.

Pokud nechcete dobročinně servírovat NTP do divokého internetu, tak v běžné firmě nebudete mít v síti pohromadě tolik klientů, aby položili třeba jenom toho Geode. Nějaké příhody z natáčení by se našly, když to výrobce SNTP klientů nevzal za správný konec... ale nemá cenu vláčet tyhle případy veřejně blátem. Tyhle historky slýchám i přímo od výrobců klientských krabiček a to v tom smyslu, že si z incidentu vzali správné ponaučení.

Meinbergovic proprietární NTP "cluster" (pro hloupé klienty, kteří umí v konfiguraci jenom 1 upstream NTP server) funguje do jisté míry analogicky jako HSRP/VRRP = servery si navzájem půjčují IP adresu (patrně nikoli MAC adresu). Ovšem aktivní je vždy pouze jeden Meinberg v clusteru. Tzn. pro rozkládání zátěže to použitelné není.

Tik a Tak u Cesnetu bývali tradičně hodně vytížení. Asi bych nedoporučoval, obracet se na ně přímo. Použijte třeba 5 aliasů z pool.ntp.org a on už si to Váš ntpd přebere.

V tom výpisu "ntpq -p" mě reach=377 nijak nešokuje, to vypadá dobře. Reach je octal bitmaska posledních pár pokusů (NTP transakcí) proti dotyčnému upstream serveru. Spíš mě tam šokuje jitter 140 ms. Z pool.ntp.org běžně dostanu některý server se stabilním jitterem a ofsetem v nízkých jednotkách ms.

Plnohodnotný ntpd (nebo Chrony) si skutečně vybírá server nebo malou skupinku serverů s navzájem blízkým ofsetem a co nejnižším rozptylem (jitterem). Takže pokud klientovi/klientům nebo "svému NTP serveru" nakonfigurujete větší počet upstream NTP serverů, dojde automaticky k rozložení zátěže mezi upstream servery i na té bázi, že přetížené servery mají horší jitter a z "volby" vypadnou jako první. Zátěž bude nakonec směřována přednostně na méně vytížené upstream stroje.

Druhou fajn vlastností plnohodnotné implementace NTP je, jak již zmíněno, detekce a odmítnutí lhářů (falsetickers) - viz obrázek s titulkem "intersection interval". Jde o svého druhu algoritmus pro shlukovou analýzu na bázi konsezu kvóra a "outlier rejection". Věc jde dokonce tak daleko, že pokud přímo na serveru s GPS přijímačem dáte "refclock driveru" direktivu "prefer", aby "vžycky zvítězil", tak pokud vedle refclock driveru uvedete v konfiguraci také pár upstream NTP serverů z divokého internetu, mohou ve "volbě" vytěsnit refclock driver včetně jeho "prefer" přídomku jakožto falsetickera, pokud se svým názorem na přesný čas zůstane osamocen (viz poslední odstavec v kapitole 5 na uvedeném odkazu).

Pokud budete někdy řešit nějakou redundantní NTP topologii uvnitř rozsáhlejší sítě, doporučuji držet se striktní hierarchie klient/server (master/slave). On ntpd umí nakonfigurovat i "peer to peer" asociaci, ale některé praktické zkušenosti říkají, že není radno konfigurovat to "do kruhu", kromě toho se pak taková konfigurace chová dost "automagicky" i na poměry ntp algoritmů. Striktní hierarchie je jistota.

Naopak pokud budete mít v lokální síti několik kvalitních rádiem řízených zdrojů, a budete o stratum níž pozorovat "clock hopping", tak vězte, že to ničemu nevadí.

Holé minimum (počet upstream serverů) pro outlier rejection (detekci manipulace) je patrně 3. Pokud máte v lokální síti 3 rádiem řízené NTP servery, mělo by to stačit. Podotýkám, že samotný GPS přijímač dokáže samozřejmě detekovat a přes NTP dál předávat chybové stavy, jako je ztráta příjmu z družic nebo hrubý pokus o manipulaci. A pokud by se nakonec někomu povedlo, přijímač GPS zmanipulovat ke skokové změně hlášeného času, tak se vzápětí sám vypne ntpd (nebo se vykašle na dotyčný refclock driver, pokud má nakonfigurované další upstream zdroje), protože ntpd si toho skoku taky všimne a považuje ho za vážnou chybu.
Zpět k tématu: pokud jde o "minimální počet pro outlier rejection"... servery z divokého internetu bývají na štíru s dostupností, takže má smysl požadovat 4 nebo víc upstream serverů. Lichý počet je možná teoreticky lepší, aby nemohlo dojít k "patu" - ale on skutečný počet upstream NTP asociací bude beztak po svém vandrovat mezi sudými a lichými čísly podle reálné dostupnosti nakonfigurovaných serverů, a v NTP poolu je zřejmě dost serverů s poměrně mizerným round-tripem a jitterem. Výpis ntpq na stroji, který bere čas z divokého internetu, je obvykle mnohem barvitější a zajímavější, než výpis ntpq v síti s několika lokálními rádiovými zdroji (v ntpq skoro samé nuly).

Ohledně PTPv2... ano připomíná to legendu o babylonské věži. Jednomu vendorovi PTP klientů (a třeba switchů) se konfigurací grandmastera ještě přizpůsobíte, ale v multi-vendor heterogenních sítích může být těžké najít společného jmenovatele.
Mimochodem na takové to domácí žvýkání PTPv2 doporučuji linuxptp a hardware i210 ev. i350 - případně může být zajímavé pohrát si s PPS vstupem nebo výstupem na GPIO pinech i210. Případně zavěsit jeho 25MHz krystal na vnější kvalitní referenci (GPS, Rubidium apod). Pokud pro to máte využití (vedle PTP třeba capturing provozu s přesnými časovými značkami - rozlišení v ns) tak si užijete třeba i dost zábavy.

944

Desktop / Re:Notifikace ze vzdáleného serveru

« kdy: 09. 01. 2019, 23:10:24 »

Nestačilo by pípnout, až to skončí? Třeba jenom za ten "zdlouhavý" příkaz do skriptu přidat následující:

echo -n $'\a'

Schválně si to zkuste pastnout do shellu, jestli něco uslyšíte.
A zkuste to na dálku v SSHčku.

945

Server / Re:Jak zjistit, v jaké zemi se nachází server?

« kdy: 07. 01. 2019, 21:17:27 »

První po čem sáhnu je v příkazovém řádku whois na IP adresu. Překlad doménového jména na IP adresu buď nslookup / host / dig, nebo klidně třeba jenom ping. Jasně pokud to jede na nějaké CDNce apod. tak v různých částech světa dojdu potenciálně k různým výsledkům, nebo pokud je to v AS nějaké mamutí firmy napříč kontinenty tak poznám stejně houbeles.