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] 2 3 ... 60
1
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 11:55:33 »
@RDa: jo, karta za 250, k ní kabel za litr. To je přesně ono, můj odhad koukám nebyl moc mimo - ten kabel je totiž děsně enterprise storage :-) pokud ne rovnou carrier grade...

2
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 09:20:17 »
uz z principu pouzivat tento u.2 na boot, resp. sys disk je ako kupit LaFerrari a jazdit s tym len v rannej zacpe do prace. Ano da sa to. Ten disk treba jednoznacne pouzit na ine cinnosti.

Pro jistotu: mluvíte o Intel P5410 ?

Fakt je, že 0.5M IOps / 2800 MBps čtení vypadá jako vynikající železo pro nějaký serverový read-mostly workload.

Pokud se týče výdrže pro zápis, tak technologie buněk je TLC a tomu odpovídá necelých 2000 kompletních přepisů. To není moc dobré na windowsí bootovačku. Ten disk by v tomhle nasazení shnil po pár měsících až nízkých letech provozu - jako kterákoli zcela tuctová konzumní flashka. Ale musím uznat... když vidím, kolik se ve Windowsech prohání všelijakých "diskových chroustalů", jako že Windows Update / MRT / Antivir / MS Indexing Service / Thunderbird údržba složek / Chrome ( / defrag je na flashkách odstavený)... ani se navzájem nedomlouvají, kdo kdy poběží aby neběželi současně... tenhle P5410 v roli bootovačky pro Windows by byl *veliké* labůžo :-)

3
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 08:19:13 »
Ano Delock ten adapter má. Zkusím zjistit dostupnost.
Na druhou stranu pro vícečetné redukce již musí být nějaká podpora Biosu/desku - musí umožnit rozvětvení (Bifurcation), ale i bez  jeho podpory by měl běžet alespoň jeden NVMe disk.

Souhlas, taky jsem nad tím kroutil hlavou. Dvě poznámky k tomu:
  • všimněte si, že na kartičce od DeLocku jsou dva mrňaví švábi - žeby PCI-e redrivery? Žeby byly na PCI-e lince paralelně, a dokázaly připojit jeden či druhý konektor? Nasvědčuje tomu poznámka "Pouze jeden port může být v provozu, nikoliv oba současně."
  • na tom odkazu u DeLocku jsem viděl zmíněny "podobné produkty" tuším jenom s jedním konektorem

4
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 08:13:15 »
Koukám, že jsou borci, kteří si do UEFI/BIOSu jsou schopni přidat DXE driver (drivery) pro NVMe. A i bez moddingu BIOSu jsou zřejmě další "lehkotonážní metody" jak z NVMe bootnout (blafák s bootloaderem). Je o tom dlouhatánské vlákno na win-raid fóru. Podmínkou samozřejmě je, že je NVMe disk vidět aspoň jako PCI-e zařízení.

5
Hardware / Re:Připojení 2,5" NVME P4510 do bežného PC
« kdy: 17. 01. 2022, 07:59:47 »
Jenže pozor, dochází ke zmatení pojmů (s dojmy)
VY mluvíte o SSD v provedení M.2 - malá kartička, já mluvím o SSD U.2 - což je vizuálně nomální 2,5" disk - jen s NVMe rozhraním.
A na ty karty u nás prostě nejsou. Proto ten rychlý Ali.

Na všemožné redukce rozhraní chodím k německo-čínské značce DeLock. A myslím, že ani tentokrát nezklamali. Přímý dovozce/distributor u  nás je SWS, ale jejich produkty vídám i v některých dalších e-shopech. Doporučený postup: u DeLocku si vyhlédnete konkrétní objednací kód, a pokud ho u nás nenajdete Googlem, zeptejte se emailem produkťáka u SWS nebo ve Vašem oblíbeném e-shopu, kde výskyt značky DeLock pozorujete. Ten hardware je přinejmenším bezchybně osazený (sletovaný).
Kabely k tomu buď tamtéž, nebo ledacos má v sortimentu třeba SuperMicro.

Ještě vysvětlivka obecněji k tématu: pokud vím, NVMe je vespod zcela standardní PCI-e. Tzn. souhlasím, že by to mělo být vidět na PCI-e v libovolném motherboardu, který do toho buď naschvál nehází vidle (BIOS) nebo nemá nějaké sdílení linek mezi sloty.
Druhá půlka problému ovšem je, schopnost BIOSu z toho nabootovat. Starší BIOSy nemají driver pro NVMe "disky", takže starý/hloupý BIOS/UEFI takové zařízení nenabídnou jako disk device v rámci svých "služeb pro přístup k disku" a bootovací sekvence. Pokud je v tomto problém, znamená to bootnout z nějakého tradičnějšího diskového zařízení a NVMe disk mít případně jako další disk v systému. Třeba v Linuxu stačí bootnout "odjinud" jenom kernel (nebo kernel+initrd), čímž si OS natáhne svůj vlastní driver pro NVMe a jede se dál. Prakticky bych prostě takový "legacy" bootdisk mountoval jako /boot, aby se s tím snadno pracovalo při updatech. Asi by stačila USB flashka. Pod windows si nejsem jistý, jestli by stačilo, strčit na "starý" disk jenom EFI oddíl resp. EFI bootovací adresář, nebo jestli na něm musí být taky C:\Windows = prakticky celý systém... na což USB flashka není vhodná jednak v rovině svých obecných vlasností, jednak se Windows instalaci na USB flashku dost brání.

6
Server / Re:Co už je v MariaDB veliká tabulka?
« kdy: 14. 01. 2022, 08:15:50 »
Okolo 10 000 zaznamov je pre MySQL velka tabulka.

Ten čas letí... kdysi dávno panovala představa taková, že MySQL sice neumí všechny možné vychytávky co se týče transakcí / triggerů / stored procedur, ale je pekelně rychlé a na jednoduchém datovém modelu škáluje kamsi za horizont. Desítky milionů záznamů nebyly problém... Proti tomu stál Postgres, který uměl důkladně všecky možné fičury, ale nebyl až tak rychlý. Pravda je, že to bylo v dobách, kdy kapacita disků byla o tři nuly kratší číslo, přitom random IOps per spindle vypadaly dost podobně.

7
Studium a uplatnění / Re:Lhaní recruiterů
« kdy: 10. 01. 2022, 08:10:48 »
Může být, ale jak člověk pozná, co je “jeho profese”, aniž by si vyzkoušel aspoň to, co ho nejvíc baví?

Jednoduše - prostě syn zdědí řemeslo svého otce. Ano, je to staromódní názor, nad kterým spousta frikulínů z "moderní" společnosti ohrne nos, ale je to systém prověřený staletími.

Vnímám vážně míněné jádro pudla a určitou příměs nadsázky...

První problém vidím v tom, že určitá vloha nebo talent se běžně dědí přinejlepším ob generaci. Málokdy je synek ve všem po tátovi. Ve šťastných případech se ten materiál vhodně navzájem doplní a proloží v čase. Nástupnictví v rodinných firmách vůbec není sranda. A když se to provede "na sílu"... bude cca každá druhá generace nešťastná.

Navíc před asi 150 lety se technickej pokrok utrhl ze řetězu, takže mnohé technické profese moc dědit nejdou. Radši nedomejšlím, jak bude trh práce vypadat pro moje vnoučata. Nemluvě o pravidelných převratech a světových válkách včetně vyvlastňování v našem prostoru ve 20.století - to k těm rodinným firmám.

8
Server / Re:RAM Memory Cache a Buffer
« kdy: 04. 01. 2022, 00:20:30 »
Dokud je nějaká paměť "available", tak by neměl být problém. Možná to s pamětí vůbec nesouvisí.
V momentě kdy ten stroj sežere 100% CPU, dá se zjistit, čím je procesor konkrétně vytížený?
Mimochodem popis problému mi cosi připomněl, ale asi je to podobnost čistě náhodná.

9
Server / Re:RAM Memory Cache a Buffer
« kdy: 03. 01. 2022, 13:52:30 »
Palec nahoru za dotaz a za používání šedé kůry :-)
Ano správně, to téma je kontroverzní.

Vedle hodnot Buffers/Cached jsou zajímavé také hodnoty MemTotal/MemFree/MemAvailable, Dirty/Writeback, SwapTotal/SwapFree a další. V zásadě je zajímavá velká část obsahu /proc/meminfo, a jeho vývoj v čase.

Odpojit swapáč za jízdy na serveru, který začíná drhnout, mi přijde jako poněkud kaskadérský nápad :-) Zejména bez mrknutí do /proc/meminfo, kolik je naswapováno.

Free_caches způsobí:

- zahození obsahu stránek, který zůstal v ramce ve smyslu "čtecí cache". Tzn pokud něco z toho bude zanedlouho potřeba, vyvolá to nějaký ten přístup k disku navíc = zdržení.

- nejsem si jistý (nepoužívám to) zda způsobí také flushnutí dirty stránek (write-back cache). Pokud to navíc provede "bariérovou operaci", může to způsobit dost dlouhé zdržení. Záleží jaký objem stránek je ve stavu dirty/writeback, kolik je to transakcí, jak rychlé jsou disky a jakou další zátěž ten storage táhne (pokud je sdílený více hostitelskými stroji).

Objem Cached/Buffers sám o sobě mnoho neříká. Stránky "buffered" (čtecí cache) jsou teoreticky "obratem k dispozici" (téměř free), prostě se jenom vyřadí z cache. Tzn. "uvolnit je násilím" by samo o sobě nemělo mít velký přínos. Je možné, že to má vedlejší efekty a konotace. Četl jsem něco o interakci NFS a vespod ZFS, kde free_caches řeší reálný problém. Nebo že konkrétně ve virtualizovaných prostředích to má taky svůj dobrý smysl - cca aby guesti zbytečně nedrželi hostiteli alokovanou fyzickou RAM na nějaké svoje poviderní čtecí cache, "jenom proto že je ta RAMka k dispozici". Protože ve virtualizaci se fyzická RAMka přiděluje vlastně "nadvakrát" - probíhá memory management v rámci hostitele a následně v rámci jednotlivých guestů, tato dvě patra mohou spolupracovat. Padla v této souvislosti taky na okraj zmínka o ballooning driveru (asi jakožto o alternativním způsobu, jak nutit guestův kernel ke střídmému zacházení s využíváním RAMky).

Téma do jisté míry souvisí s fragmentací RAM - té se dá bránit explicitním spuštěním "defragmentace RAM":
echo 1 > /proc/sys/vm/compact_memory
...což ale zřejmě neřeší konkrétně otázky specifické pro virtualizované prostředí.

Odkazy = rychlým dotazem do Googlu jsem našel k tématu několik výživných debat - řazeno cca sestupně podle relevance:
https://serverfault.com/questions/597115/why-drop-caches-in-linux
https://savvinov.com/2019/10/14/memory-fragmentation-the-silent-performance-killer/
https://www.unix.com/unix-for-advanced-and-expert-users/248922-memory-fragmentation-linux-settop-box.html
https://lwn.net/Articles/368869/

10
Bazar / Re:Koupím procesor Celeron G3900T
« kdy: 30. 12. 2021, 08:00:48 »
Ja prave premyslel nad tim, ze to asi moc resim a nejak jsem si neuvedomil, ze tam jsou ty disky, ktery bych fakt mohl zkusit odpojit a zjistit, co bude za rozdil. Tech 9w u dellu je peknych, kdybych se tam dostal bez tech disku, bylo by to pekny.

Ty disky žerou údajně v idle každý asi 0.8 W. Pod zátěží mají udávané v průměru 2W (jednotlivý disk). Při rozběhu do otáček 5.5W.

11
Bazar / Re:Koupím procesor Celeron G3900T
« kdy: 30. 12. 2021, 07:56:38 »
Co me ale prekvapilo, ze kdyz jsem celkove omezil vsechna jadra na 800MHz a nebo treba 2 jadra ze 4 'vypnul' prikazem

Kód: [Vybrat]
echo 0 > /sys/devices/system/cpu/cpuX/online
tak se ta spotreba vicemene nesnizila ani o 1W.

Co vy na to?

Pokud je to porovnávané ve stavu bez zátěže (idle) tak se systém drží velice při zdi i sám od sebe. Roli také hraje, jaký "governor" je v Linuxu natažený - v idlu sníží frekvenci prakticky kterýkoli governor (z ovladače intel_pstate), s výjimkou natvrdo nastavené konkrétní vyšší frekvence.

Zrovna si trochu hraju s prográmkem CoreFreq. Osvědčilo se mi, spouštět corefreq-cli buď bez argumentu (pak ale ukazuje frekvenci ještě násobenou procentem času v C0 = násobeno zátěží = nesmysly) nebo spíš

Kód: [Vybrat]
corefreq-cli -0a -t frequency
Pozornosti obecenstva bych doporučil ještě menu na klávesách F2-F3-F4 v interaktivním režimu, a pak dump
Kód: [Vybrat]
corefreq-cli -s

V idlu je procesor jednak automaticky podtaktovaný na minimum, co dovolí EIST, jednak stráví většinu času uspaný = C stavy C1 a hlubší. Popravdě pokud se procesor fláká, tak na mém systému reálně tráví nejvíc času v C6/C7.

= ruční nastavení nižší nebo úplně nejnižší Fmax nemá prakticky význam, pokud je procesor tak jako tak bez zátěže.

Ono je toho v moderních procesorech víc, co má svoje hodiny - grafika, všelijaké uncore bloky, nevím jak cache... a moderní procesory si toto řídí čím dál víc po svém (v hardwaru). Konkrétním milníkem v míře této autonomie je Skylake = 6th gen. Na moderním procesoru spíš než frekvenci nastaví OS něco jako "žádané procento maximálního výpočetního výkonu" a CPU už se interně zařídí po svém. Pravda je, že na pozadí je tam (ohledně CPU jader) vždycky nějaký násobič referenční frekvence a štelování napájecího napětí - ale děje se to čím dál víc automaticky.

Ohledně reálného srovnání spotřeby procesoru "s T vs. bez T"... nemám představu, neposloužím :-) Třeba rozdíl v objemu aktivní L3 cache může udělat dost, ty téčkové procesory mohou dosahovat na hlubší mez podtaktování při nejnižším P-state apod.

Přikládám pro zajímavost diagrámek spacích stavů (C-stavů) procesoru, v rámci "celkových ACPI stavů počítače". V obrázku nejsou namalované P-stavy CPU (= švidrání frekvence a napětí podle zátěže) ani T-stavy CPU (nouzové škrcení = vynechávání jednotlivých taktů) - tyto si představte "kolmo" jako další dimenze ;-)

12
Sítě / Re:Zkušenost multicast (video) a levné switche
« kdy: 21. 12. 2021, 07:29:17 »
Ale vrtá mi hlavou, jestli switch nějak vytěžuje i forwarding multicastového payloadu. Uvítám případně odkazy na další čtení ohledně architektury switchových čipsetů :-)

Tady někdo tvrdí, že v levných switchích se multicast (a broadcast, a nenaučený unicast) děje s účastí CPU. Hledejte nadpis "replication engine".

13
Sítě / Re:Zkušenost multicast (video) a levné switche
« kdy: 20. 12. 2021, 23:13:42 »
@Hobbit díky za poučený komentář :-)

vemu to pokud mozno zkratka:

Citace
Multicast bez IGMP by se měl chovat jako broadcast. Nepochopím, jak tohle může fungovat chvíli a pak už ne :-)
Switch proste neustoji tu zatez broadcastu a zacne kravnout. U nizsich switchu naprosto bezna vec
Rozuměl bych, že vést seznamy živých IGMP příjemců v L2 síti může být dost zátěž na management CPU. Čím větší L2 segment, tím hůř.

Ale vrtá mi hlavou, jestli switch nějak vytěžuje i forwarding multicastového payloadu. Uvítám případně odkazy na další čtení ohledně architektury switchových čipsetů :-) Co je to přesně ten crossbar/matrix? To přece nemůže fungovat doopravdy "každej s každým" (neblokující full mesh) = je to třeba velmi rychlá sběrnice do nějaké paměti, ze které se paket ve fázi "forward" vytáhne a jednotlivé egressové porty si "dekódují" cílové adresy, které je zajímají? RAM buffery pro "store and forward" jsou sdílené, nebo nějak nadrobené per port?

Na Vašem empirickém poznatku samozřejmě tyhle ohavné interní detaily nic nemění.

Citace
Citace
Ještě mě napadá - pokud by se multicast bez IGMP choval jako "nenaučený unicast", asi by se to dalo zabít odesláním paketu se zdrojovou příslušnou multicastovou L2 adresou ;-)
Prekvapko: mac adres odpovidajicich IP adresam multicastu neni nejak extra moc, stava se, ze vice multicastu ma stejnou macovku. Krabice si to pak musi prekousat na vyssich vrstvach.
No já jsem se bavil spíš o zdrojových L2 adresách. Při odeslání paketu na multicast destination může být source adresa unicastová. Celá ta moje poznámka byl spíš vtípek, že by multicast destination šel protáhnout opravdu hloupým switchem i jako nenaučený unicast destination, což by ale fungovalo jenom do chvíle, než někdo použije dotyčnou multicastovou adresu jako zdrojovou. Je to fakt jenom blbej vtip, protože jak sám píšete dál, pro seriózní použití je praktickou nutností IGMP snooping.

Citace
Citace
Měl jsem pocit, že to že pakety mohou dorazit "out of order", není v paketových sítích chyba ale vlastnost :-)
Ten counter v hlavicce multicastu ma 4 bity. Takze 16 packetu v rade a pak jede od nuly. Nic moc rezerva.
Heh netušil jsem že je tam aspoň 4bit counter...

Citace
Z principu UDP nema vetsi bufferovani u multicastu zadny smysl - co nedorazilo ve spravnou chvili to uz nedorazi.
Taktak. Ono by nemělo smysl ani u unicastového provozu baleného do UDP.

Citace
Citace
Předpokládám, že multicastovat video v mixu s normálním provozem má smysl jedině v kombinaci s priorizací videa - jinak se budou ztrácet pakety toho videa, s popsanými důsledky.
jakakoliv prioritizace je jenom berlicka, jedine overene reseni je dostatecna kapacita linek.
:-D ano! nejnamáhavější na konfiguraci shapingu je vždycky vysvětlit "vlastníkovi řešení", že jakýkoli shaping/priorizace je nakonec na pikaču resp. že primární problém s přetíženým úzkým hrdlem ve finále neřeší. Případné výjimky spíš potvrzují pravidlo.

Citace
To uz dneska neni takovy problem, 10Gb lasery stoji par korun. A na vsech switchich (pokud zrovna na nich zrovna neni PIM) musi byt zapnuty igmp snooping, jinak napriklad zakaznikovi v panelaku dorazi do boxu vsechny mulsticasty prihlasene na dane lokalite -> to box vazne neukousa.
PIM je v control plane pro třetí vrstvu, IGMP pro druhou vrstvu. Ale se zbytkem ze srdce souhlasím :-)


14
Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat
« kdy: 19. 12. 2021, 22:35:07 »
...no já si z dob svého telecího mládí pamatuju nějaké open-source ASN.1 knihovny, kde se tuším generovaly C++ třídy nějakým lexerem z ASN.1 symbolické notace, a pak se to C++ kompilovalo. Něco takového bych do MCU rozhodně cpát nechtěl. Tenkrát kdysi pod Windózama, když jsem si chtěl hrát se SNMP, a nějak jsem nedokázal najít vyhovující portovatelnou jednoduchou knihovnu ASN.1, tak jsem si pár základních datových typů ASN.1 BER napsal v jednoduchém C++ sám. (Ty zdrojáky dávno nemám. Stejně to bylo jenom torzo.)

15
Vývoj / Re:Rust - serde/bincode serializacia/deserializacia dat
« kdy: 19. 12. 2021, 19:04:05 »
Spravy su vsehovsudy jednoduche, nieje nutne ich balit do msgpack, protobuf, bson a pod.

ASN.1 BER ?
[/provokace]

(Hihihi :-D a zdrhám až se mi za patami práší, než po mně někdo něco hodí.)

Stran: [1] 2 3 ... 60