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 ... 67 68 [69] 70 71 ... 89
1021
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?

1022
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čí.

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

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

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

1026
K plemennému názvosloví se nechci moc vyjadřovat, protože jakožto programátor jsem převážně hobbík-ochotník. Snad jen, že za našich dob se lidem, kteří identifikovali a modelovali business procesy, říkalo spíš "analytici". A lidi co dohlíželi na fungování podle metodik, těm se říkalo spíš projektový šéf nebo team leader, nebo řekněme metodik, pokud jejich pozice neměla pravomoc rozhodovat o postupu prací.

Umělá inteligence odstraní ohavnou opakující se práci? Bože, už aby to bylo! Kolika lidem se uvolní ruce pro fajnovější, tvořivější práci. Totiž ta opravdu tvořivá a extrémně zábavná programátorská práce, "základní výzkum", není kdovíjak žádaná, protože obvykle nezapadá do business plánu - nezapadá do toho že každý měsíc je potřeba mít na výplaty a dodat finální produkt v nějakém konkrétním časovém horizontu - který se líp počítá "extrapolací normovaného lopatování známými prostředky", než spoléháním na nějaký skok do vyšší dimenze programovací/modelovací černé magie  (vývoj nástroje, který opakovatelné lopatování nějak lstivě zautomatizuje).

Ohledně AI mám zatím spíš pocit, že pravdu měla ta žába výzkumnice z nějaké U.S. univerzity, kde si hrají s učením ANN pro ovládání manipulátorů, že obávat se příchodu AI je jako obávat se přelidnění Marsu. Zahlédl jsem to v nějakém videu, které jsem už druhý den nedokázal dohledat. On se ten názor asi moc nehodí do krámu při podávání grantových přihlášek.

Pokud se týče programovacích prostředků, k tomu co napsal Meh bych snad jenom dodal: ve škole koncem minulého století nás v jednom předmětu učili dělat v databázi tuším Progress, která měla jednoduché 4GL RAD prostředí. V té době existovaly i dražší databáze s mocnějšími RAD nástroji. Pak přišly weboviny a místo aby se 4GL RAD nástroje oděly do webovin, došlo k tomu, že se databázové weboviny mastí v PHP - oproti 4GL éře úkrok kamsi hodně stranou. Dnešní webové frameworky neznám, dělám do včel, ale spíš mi to přijde, že je to o škálovatelnosti napříč cloudem / farmou fyzických serverů, a o "lifecycle managementu", spíš než o 4GL/RAD - nebo se pletu? Kam se podělo dávné "dřinu nechme strojům, i v programování" ? Tohohle se teď máme *bát* ?

Moje soukromá hypotéza, kdo straší příchodem AI:
- novináři, kterým to zvedá "náklad"
- poptávková strana pracovního trhu (ti co tvrdí "každý je nahraditelný, za dveřmi stojí fronta zájemců o Vaši židličku")
- lidé, které těší řečnit o tom na konferencích (bez vazby na hloubku skutečných znalostí a zkušeností v oboru)

Můj dosavadní pocit je, že nedostatek programátorů bude trvat i na zajímavé "tvořivé" činnosti. Stejně jako nedostatek mnoha dalších profesí, kde je nám vyhrožováno příchodem AI. Prostě jakmile jsou k té práci potřeba šikovné ruce, schopnost mezilidského jednání, případně trochu šibalských postupů nebo diplomacie, nebo vysoká tvořivost, všeumělství, autonomní pohyb v prostředí apod., tak dost nehrozí, že by člověka vytlačilo nějaké dostupné AI řešení. Srovnejte si pořizovací cenu a provozní náklady dnešních největších superpočítačů, které zvládnou simulovat tak setinu lidského mozku, s cenou a provozními náklady toho superpočítače, který nám každému šplouchá mezi ušima.

Spíš je tady v našich končinách problém, že jsme až na pár důležitých výjimek na "přijímajícím konci logistických řetězců". Na Taiwanu a v Číně je práce vývojářů všeho druhu prostě levnější (křemík, HW, SW) - a není to zřejmě vůbec jednoduchý chlebíček. Pravda je, že z té jejich kultury mám takový pocit, že jsou dobří spíš v přejímání a cizelování již prověřených postupů, než v nějaké radikální tvořivosti a průlomové inovaci. Ale řemeslníci jsou to obstojní až vynikající a prostě ta řeka zboží (včetně produktů HW a SW inženýrství) teče bohužel převážně od nich k nám.

Mimochodem oboru "data science" se tehdy koncem století říkalo tuším "data mining", OLAP, základním uživatelským nástrojem byla multi-dimenzionální kostka apod. Módním trendem může být snad jen snaha naroubovat na to moderní "deep" neuronovou síť.

Umělé neuronové sítě nejsou zdaleka "houska na krámě". Vývoj na několika patrech skladebné hierarchie neustále probíhá a hlubší pochopení různých zapojení / algoritmů / topologií / laditelných parametrů rozhodně není o nějaké rutinní aplikaci. Je to spíš téma na dlouholeté soustředěné bádání. Konkrétně TensorFlow vypadá jako dost low-level vývojový prostředek. Potřebujete docela rozsáhlé know-how, abyste zvládl víc než jenom spustit pár hotových examplů.

A tím bych svou dnešní tapetu nejspíš ukončil...

1027
Mě přišel boží požadavek odsouhlasit smlouvu na zřízení "bankovní identity", za kterou mi banka nemusí ale může účtovat peníze podle svého uvážení (zatím je to zadarmo). Jinak se do internetbankingu nově nepřihlásím. A pak samozřejmě to uživatelské rozhraní: homepage je teoreticky široce customizovatelná, můžete si tam vyvěsit služby jaké chcete, ale reálně zabírá čtvrtinu obrazovky zbytečná neodstranitelná reklama na úvěrové služby které nechci, další čtvrtinu zabírá prázdné místo, zbylá horní vodorovná půlka je jakž takž užitečná ale obsahově dost chudá... darmo plýtvat textem na ten paskvil.

1028
Hardware / Re:Hlavice radiátoru
« kdy: 21. 12. 2018, 20:14:05 »

K čemu je měření teploty u té hlavice dobré? :o

K tomu, že po odečtení dvou až pěti stupňů budu znát teplotu místnosti, pokud přes to nepřehodím ručník?

ten pocet stupnu bude spise random od 1 do x. Pokud chces regulovat teplotu v mistnosti, potrebujes nekde cidlo teploty v mistnosti a ne na radiatoru, tohle opravdu neni spolehlive.

Já vnímám jeden nenápadný půvab termohlavic se zabudovaným teplotním čidlem: tím že čidlo je částečně přímo přihříváno regulovaným radiátorem (a možná spíš přívodní trubkou), je zavedena lokální rychlá záporná zpětná vazba. Tato sice snižuje regulační zisk "velké" smyčky (uzavřené přes místnost) a tedy "zhoršuje přesnost" regulace, ale také potlačuje sklon termohydraulického systému k oscilaci regulační smyčky. Hlavice s čidlem dál v místnosti (přenos třeba kapilárou) jsou sice napohled "správnější" a teoreticky přesnější, ale pokud by měl ventil příliš velký regulační zisk, tak objem teplé vody v natopeném radiátoru může snadno způsobit náběhový přemit nebo i cyklickou oscilaci regulace. Záleží samozřejmě na velikosti místnosti, na jejím topném příkonu potřebném na krytí ztráty, na teplosměnné ploše a objemu topného tělesa a jak psali ostatní, na tepelné akumulační kapacitě budovy... není to úplná sranda :-) Pokud by se do systému zavedl nějaký elektronický regulátor, který je schopen se setrvačnostmi pracovat (prekompenzovat) tak samozřejmě čidlo v prostoru dává velmi dobrý smysl. Viz učebnicový model PID regulace.

Z druhé strany jsem také slyšel ve svém okolí o případu, kdy "odborník" topenář nainstaloval ústřední topení s novým plynovým (nebo jakým) kotlem, s automatickou digi regulací výkonu... no a uživatel si stěžoval, že je mu v bytě zima, přitom že kotel se nikdy nerozjede na plný výkon, že se neustále přiškrcuje. Odborník-dodavatel se přijel asi dvakrát podívat, zkoumal konfiguraci regulace v kotli, ale na nic nepřišel, a věc uzavřel s tím, že "to je normální - spočítané, smontované a nakonfigurované je to správně". No a když se pak u svých rodičů stavil o víkendu kolega, našel staříky ve svetru a prostorové čidlo pověšené na zdi za kotlem. Smajlíka si odpustím, je doufám zbytečný - řešení si domyslíte.

1029
Hardware / Re:Doporučení NB/NUC pro teenagera na Linux
« kdy: 17. 12. 2018, 22:58:41 »
Hmm... OP už myslím vzdal to dál poslouchat, ale debata se slibně rozjela i bez něj, takže...

Můj synek mě k tomuto kroku dotlačil, když mu bylo pět. Sápal se mi na pracovní noťas. Dostal levný 15" Acer s nějakým Haswell Celeronem (a 8 GB RAM - v té době to byl chvilku základ z výroby). To bylo před 6 lety. Ten noťas má pořád, jenom už u něj nesedí tolik času jako dřív. Má jiné zábavy. Prostě není po mně :-)

Desktop nebo "NUC" má jistý smysl v případě, že je k dispozici pevně umístěné pracoviště a fakt nechcete, aby potomek mohl "počítat" kdekoli potřebuje, klidně někde mimo domov.
Možnost tahat si úsporný noťas do pelechu může být v malém bytě velká výhoda.

Odolnost Aceru nepodceňovat. První Extensu jsem tahal do práce a domů každej den asi 6 let, než se ukejvaly panty. Ty jsem vyfutroval hliníkem, ale následně asi po dalším roce se mi v displeji projevila výrobní vada (špatně nalepená uzemněná hliníková stínící fólie škrtala o měnič podsvícení) a konečnou diagnózu jsem pořídil tím způsobem, že se mi to při hledání závady potkalo pořádně, s prošlehem do motherboardu (čipset kaput).

@MasoxCZ: díky za potvrzení mého dojmu, že NUC je přehřátá naleštěná bída. Intel umí procesory, ale počítače moc ne - resp. nestydí se hnát teplo úplně na hranu. Hnus, velebnosti.

Gemini Lake ATOM umí hardwarově akcelerovat přehrávání H.265 tuším i ve 4k a v 10 bitech (Apollo Lake byl tuším s 10b hloubkou na štíru). Jak je to s jinými kodeky, jako x264 nebo VP9, to netuším. Obecně na YouTube ve 320x240 stačil už starý dýchavičný 45nm ATOM N270. S full HD mají problém i low-end plnotučné procesory, pokud má video dekódovat software na CPU.

Měnit noťasy jako ponožky? By mi brzy hráblo, pořád dokola zabydlovat nové syrové windowsy. Teda pod Linuxem by to mohlo být jednodušší: prostě pokaždé dist-upgrade, nový kernel, přehodit nebo naklonovat disk do nové mašiny a jede se dál. Já potřebuju na noťasu pracovat, ne se pořád jenom znovu a znovu zabydlovat. Zabydlet nové widle k obrazu svému je počáteční práce tak na tři dny, do stavu, kdy udělám počáteční zálohu zhruba zabydleného systému. Ale rozumím tomu že lidem, kteří mají noťas 1) na parádu 2) na facebook 3) na maily které čtou stejně v browseru, těm je jedno k čemu si zrovna sednou. Hardware střídají jako ponožky hračičkové, pro které má nový hardware jakousi pornografickou přitažlivost. Mezi ně nepatřím - vůči konzumním naleštěným hračkám pro ovečky jsem čím dál víc technofobní.

1030
Hardware / Re:Zhodnocení výběru desky
« kdy: 16. 12. 2018, 19:20:27 »
Rozdíl mezi ATX a MicroATX je fakt jenom těch pár PCI slotů navíc. Třeba ve smyslu chlazení výkonných součástek ta plocha desky navíc nestojí za řeč.

1031
Sítě / Re:100gbit v Praze
« kdy: 15. 12. 2018, 13:59:00 »
Ještě mě napadlo, pokud zadání ve skutečnosti zní, obsloužit velký počet klientů nějakým streamem, downloadem apod., jestli to náhodou není spíš úloha pro CDN. Než se to obsloužit jedním centralizovaným "tlustým úzkým hrdlem", tak raději využít služeb někoho, kdo má prostředky k distribuované obsluze předpokládaných klientů, má svoje peeringy případně hostované servery u velkých ISP apod.

1032
Sítě / Re:100gbit v Praze
« kdy: 14. 12. 2018, 14:17:07 »
Možná by Vás mohl zajímat seznam připojených sítí na webu NIXu. Možná ne přímo relevantní pro Vás, ale každopádně zajímavý je také ceník.

1033
Sítě / Re:100gbit v Praze
« kdy: 14. 12. 2018, 13:39:18 »
Pokud je to jenom "point to point", tak odhadnu že je blbost poptávat 100 Gbps na třetí vrstvě. Switchovaný L2 ethernet tu kapacitu přechroupe snáz, ale možná vůbec nejjednodušší by nakonec bylo, pronajmout vlákno. Nechci tvrdit Lambdu - tušímže 100 Gbps jedinou lambdou snad vůbec nejde. Čili nenasvícené vlákno, a může být providerovi jedno, jestli tam teče terabit skrz DWDM nebo nějaká RS485.

Jo aha... pokud "jenom lokální traffic" ve smyslu "sloužit českému internetu", tak by právě připadal v úvahu ten NIX. Zkuste se zeptat. Odhadem Vás nepustí přímo do svého AS, ale nerad bych kecal, dělám už jenom do včel. Nebo někdo kdo má s NIXem v baráku pohromadě svůj nájemný hosting pro zákazníky - takových providerů bude několik. V Praze míval hodně silnou metropolitní síť Pragonet, ale to už je opravdu hodně let. Hodně optiky po Praze natahal Sitel. Ale jinak prakticky jakékoli velké jméno.

1034
Sítě / Re:100gbit v Praze
« kdy: 14. 12. 2018, 12:36:13 »
...mam pozadavek na specificky provoz na nejakou dobu...

Matně si vybavuju článek od někoho tuším z CESNETu, že se krátkodobé / časově omezené požadavky na vysokou kapacitu vyskytují v jejich "akademické sféře", možná i v mezinárodním měřítku (GÉANT) - a že se snaží stavět svou síť tak, aby mohli vyhovět.

Jinak nemám přehled (jsem 15 let mimo) jaká je dneska u českých ISP běžná kapacita IP páteře někam za kopečky. Možná by to někdo uměl i na L2. Místní peeringový uzel není špatné místo, kam se zaústit, pokud ta věc má obsluhovat hlavně tuzemské zákazníky. V této souvislosti, autonomní systém máte svůj, nebo vezmete zavděk ASkem svého hostitele?

Každopádně L3 router schopný uroutovat terabity není levné železo a 100Gb port v něm taky ne, a další věc je kapacita z toho routeru dál do světa...

Potřebuje ta věc vidět do divokého internetu? Já jenom jestli to není spíš zakázka na nějakou L2 nebo L3 VPN / spoj.

1035
Hardware / Re:Doporučení NB/NUC pro teenagera na Linux
« kdy: 14. 12. 2018, 09:52:08 »
BTW co zmiňoval /dev/inat ten Thinkpad s i5 Haswellem, to vůbec nevypadá špatně, procesorově to bude dělo, od Haswellu se toho v procesorech už moc neudálo a tahle 22nm generace už moc netopí. Taky integrovaná grafika je OK z hlediska spolehlivosti. Otázka je, jak moc je olítaný. Vidím vlevo wiki vysvětlivku "grading" (A/B/C) ale nevidím nikde u produktu zařazení do kategorie. Protože ošoupanost je docela dobrý indikátor "naběhaných hodin".

Stran: 1 ... 67 68 [69] 70 71 ... 89