Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - František Ryšánek

Stran: 1 ... 69 70 [71] 72 73 ... 92
1051
Ale já musím souhlasit, že tam je rozdíl v modulačních rychlostech, a že prostě ve směru "upload" se modulační bitrate naváže rychlejší :-) Je mi záhadou "proč", ale je to prostě tak.

1052
Tzn. ty dvě rádia (mikrotik proti klientovi) jsou de facto "peer to peer". Nejsou tam další klienti, kteří taky sosají z toho samého AP.

Řekněme, že za to skutečně můžou navázané modulační rychlosti (bitrates), a nikoli třeba download Windows Update probíhající paralelně s měřením ;-)

V tom případě je otázka, proč se rádia v upload směru (TP-link -> Mikrotik) dohodnou na větší modulační hloubce (bitů na symbol) než ve směru  download (Mikrotik -> TP-link). Jedná se o wifi, takže šířka rádiového kanálu v MHz bude oběma směry shodná. Pokud v tom nebudu hledat jiné záludnosti a implementační rozdíly / bugy, tak bych řekl, že rádio od TP-Linku vnímá na příjmu horší odstup signál/(šum+rušení) než rádio od Mikrotiku - proto si TP-Link řekne o nižší přenosovou rychlost. Chtělo by se říci, že má TP-link prostě horší anténu, ale to není nutně příčinou, protože pasivní rádiová cesta mezi oběma rádii má oběma směry shodný útlum (shodné antény, shodný frekvenční kanál). Žeby TP-link měl na příjmu vyšší úroveň rušení? Protože širší vyzařovací diagram? Nebo má jeho RX horší vrozené šumové číslo (vlastnost "křemíku")? Nebo do něj ruší zblízka hostitelský počítač?

Co se stane, pokud TP-link dongle vzdálíte od počítače pomocí USB prodlužováku?

Ještě bych si troufl od oka navrhnout experiment, "vykašlat se na MIMO a použít jediný chain na každém konci", což by možná zlepšilo stabilitu spoje, ale zřejmě omezilo přenosovou rychlost. Kromě toho že na tom TP-link donglu to zřejmě ani nepůjde konfigurovat.

1053
Server / Re:Kolik stojí 1PB úložiště?
« kdy: 29. 01. 2019, 21:01:57 »
...nebo bych zmínil německý Stordis...
Uff... s/Stordis/Starline/g . Starline dělá RAIDy. Stordis dělá HPC věci a míval tuším i nějaké storage boxy, ale dneska už zřejmě jenom switche na Ethernet/SAS/FC a optickou bižuterii. Kupodivu tam nevidím ani Infiniband... Mívali značkové SFP transceivery. Asi taky nemají na webu všechno, co jsou schopni obstarat.

Je to asi deset let, co jsem si hrál s iSCSI v rámci SCST nad Myricom 10Gb Eth a koukám, že i SCST jde dál, má drivery pro dost moderní čipy Qlogic, ale bohužel je dodnes "out of tree", na rozdíl od LIO které se dostalo do kernelu... a jako RCS používá SCST dodnes Subversion.

1054
Server / Re:Kolik stojí 1PB úložiště?
« kdy: 29. 01. 2019, 09:10:07 »
Top-loading za relativně málo peněz by se asi ještě dal, ale ten fibrechannel je zřejmě fakt docela stopka :-)

Jsou trapný v tom Supermicru, že to mají všecko jako NAS (aneb "udělejte si sami iSCSI")
https://www.supermicro.com/products/nfo/storage.cfm

Jinak klasické kastle se šuplíkama zepředu si začala sama prodávat taky Areca, nebo bych zmínil německý Stordis - mají nějaká svoje noname šasi (kromě toho že zastupují Infortrend)

1055
Distribuce / Re:Skvělý Linux na míru
« kdy: 21. 01. 2019, 10:45:22 »
-nektere programy stare, nektere programy nove

-pripadne mit vedle sebe nekolik ruznych verzi toho sameho programu (s tim, ze pokud by kazda verze vyzadovala jine knihovny a balicky, tak mit i ruzne verze knihoven s tim, ze kazda verze programu by odkazovala na ty spravne knihovny a balicky ktere potrebuje)?

Dependency hell. Pokud chcete radikálně starší / novější verze programů, tak nejlíp asi běžet si starší verze distra ve virtuálkách. Pokud jde o to, že máte v Debianu od přírody nějakou dost uleželou verzi, a chtěl byste novější, tak si novější verze kompilujte každou zvlášť ve zdrojákovém adresáři, a spouštějte přímo z individuálního "build" adresáře = bez instalace, pokud to lze (i tak bude legrace řešit verze knihoven, pokud nevyhovuje standardní varianta, že je v systému více číslovaných verzí téže knihovny, modulo garance zpětné kompatibility mezi minor verzemi). Na posledním "Debianu stable" obvykle zkompilujete nejnovější vývojové verze všeho možného. Hmm přemejšlím jestli lze snadno spouštět grafické aplikace (pod X) chrootnuté v nějakém sandboxu. Jasně flatpak.

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

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

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

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

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

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

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

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

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

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

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

Stran: 1 ... 69 70 [71] 72 73 ... 92