1336
Sítě / Re:NetBSD - výpadky WIFI
« kdy: 06. 08. 2020, 23:06:27 »
Spust si v terminalu ping router ... spojeni padne i v situaci kdy tento ping bezi co vterinu?
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.
1337
Hardware / Re:SSD pro systémový disk na desktopu
« kdy: 06. 08. 2020, 17:30:03 »Tu je ovela dolezitejsia debata, ci pre SYS disk pouzije QLC alebo TLC z dovodu Lifespanu a fyziky, ktora je v pripade QLC neuprosna.
Preto je potrebne zohladnovat P/E cycles a preto je dolezite vyuzivat co najlepsiu utilizaciu disku v celej sirke jeho kapacity. Takze kupovat disk len pre OS s kapacitou 480GB je uplna zbytocnost. Vsetko nad 128GB (najnizsie dostupna kapacita) je vela. Opakujem - pre samotny OS.
Samotne QLC je nevhodna technologia pre OS disk pretoze na takom disku neustale prebieha write = zrychlenie opotrebenia QLC. Ak na taky disk este nasupete APP, tak to len posilnite.
Dalsi problem QLC je v tom, ze ak naplnite jeho rychlu SSD cache, tak potom kontroler disku zapisuje priamo na disk, cim sa nasobne spomali zapis - moja poznamka, ze to potom staci kupit low-end HDD na taky ucel a dosahnete rovnakych mozno aj 80MB/s.
dalsia moja poznamka, kdesi hore vo vlakne bola, ze ak to ma pouzivat na Sudoku, YT, web, tak to nerobi problem. Pre niekoho, kto na tom bude pouzivat caste kompilacie, resp. este aj swapovat, tak QLC urcite nie. Co moze mat vplyv na vyuzitie NVMe - teda potreba znalosti dosky v desktopu.
Dovod preco som sa opisoval, ze bez znalosti toho na co to chce a co ma v "crevach" toho desktopu to nema dovod riesit do hlbky.
OS ktery zapisuje bezne 10+GB na jeden zatah (coz je cca typicka velikost SLC cache v QLC disku) snad ani neexistuje. Pokud vase kompilace a prace s diskem zahrnuje davku 10GB+ zapisu, tak se nejedna o disk pro OS, nebo nam chcete tvrdit ze ano?
Na OS je prave QLC vyhovujici - zrovna totiz partisna s OS je read-mostly, zadne hromady zapisu tam nemaj co probihat - vyjma prvotni instalace - a kdyz to instalujete normalnim zpusobem (z media, nebo site), tak nejspis nedosahnete limitu SLC cache. To ze W10 si delaj hodiny pri updatu neco, je jiny problem, kdyz ty prodlevy jsou i u lidi bez QLC.
1338
Hardware / Re:SSD pro systémový disk na desktopu
« kdy: 05. 08. 2020, 20:23:45 »Ak uz chcete prispiet do odbornej debaty, preco nie particie na SSD, tak si to dopredu nastudujte, pretoze inak Vas komentar "A este scimsi. Ale uz si nepamatam presne preco. Riesilo sa to vela na serverfault.com kedysi." moze vyzniet, ako prinajmensom povrchny.
Tak nam to vysvetli proc ne partisny a o kolik % na performance hit se bavime. Ono totiz kazdy normalni OS ocekava od disku ze na nem bude nejaka partition table (at uz MBR nebo GPT), a davat data na raw block device ktery mi dodal radic, je v dnesni dobe dost nevhodne - z pohledu managementu. Protoze se lehce muze stat, ze si takovej disk prepisete.
Typicky prikaz ktery pouzivam pri styku s neznamym diskem je: fdisk -l /dev/sdX ... a jestli tam nejaky blboun dal data bez partisen, tak si nezaslouzi nic jineho nez abych mu je premazal.
I kdyz se pouziva mezivrstva typu LVM, je vzdy lepsi tu partisnu vytvorit a priradit tomu spravny partition type, nez pouzivat raw disky. Tech 2MiB vas nezabije, ktere si ukousava novejsi verze fdisk-u, aby si zarovnala partition na erase block u tupejsi generace SSD. Novejsi SSD opravdu nemaji 1:1 exportovane erase bloky.
Ohledne TRIMu - u partition manageru je ta implementace zcela trivialni, tak nevim co za problem s tim mate. Ze vy pouzivate nejake proprietarni reseni, na kterych vam kde co nefunguje a dodavatel/vyrobce to neni schopen opravit... hm?
Btw mych 30T neni provozni stroj ktery by se nahodou preplnil, ale uloziste/odkladiste. Prijdou media s natocenym materialem (40-100GB zaznamu) a sup s tim tam kde podle df je dost volneho mista.. ono jaksi clovek nepredpoklada ze to disk nepojme, kdyz o sobe tvrdi ze tam je dost mista a ze me zustane par giga volneho, o to lepe. Prakticky to ale narazilo na nejake vnitrni limity - konkretne tu fragmentaci skrz volne diry rozhazene v celem poli.
Na to ze je to zcela obycejne pole skrze HBA & sas expander (pac tech disku mam zrovna 24 v cca peti polich), linux (md) swraid, neSMR green/red disky a ext4 si to vede docela slusne v default nastaveni s noatime, skrze NFS. Za ty leta co to funguje na ruzne ucely tam odeslo vice RED NAS disku nez tech green (2:1), parkrat se zmenil radic i zakladovka a v zivote bych nedokazal urcit jaky use pattern mam testovat - nejsem vedma, abych urcil co budu v pristim desetileti delat. Zvazoval jsem nasazeni SSD cache, ale tim jak ruzne se to pouziva, zadny z cachovacich systemu a metod neni schopno odhadnout co vlastne delam a dosahnout toho ceho chci dosahnout - coz je u me minimalni spotreba (= mene tepla a mene hluku).
Muzete nahodit priklad z vasi zkusenosti - co za system/hw jste postavil a jakou optimalizaci jste dosahl drasticky jinych provoznich parametru?
1339
Hardware / Re:SSD pro systémový disk na desktopu
« kdy: 05. 08. 2020, 13:51:24 »btw, ak na 30TB diskovom poli je problem s rychlostou pri 67% zaplnenej kapacite, tak je problem (okrem vhodnosti samotnych diskov) aj niekde inde - data tiering (ake data ukladam kam), vhodny block size, vhodny FS, vhodny RAID vs FS, vhodny controller (SW/HW), ....
Psal jsem 10G zbyvajicich, toz 29.99TB z 30TB je zaplnenost na 99.966 %, pri 50GB+ (<98.3%) nepozoruji zadne potize, protoze nenastava ona nucena fragmentace.
Je videt ze tomu prd rozumite, kdyz davate do souvislosti problem se zaplnenosti (ciste FS issue) s tim, ze musim mit vhodne disky, raid (level?), nebo controller.. vsemu je zcela putna jake procento dat na nosicich jsou potrebna data a co je prazdne misto.
1340
Hardware / Re:Graf. karta na NB Asus K55VM
« kdy: 04. 08. 2020, 20:07:59 »
Tak pokud je v MXM, o to lip - ze jde vymenit. Pokud tedy sezenes idealne stejny model.. kompatibilita MXM neni buhvijak zarucena. Ale v tom K55VM nejsou vystupy z grafiky, ale klasicky pres cpu a pak chipset (viz: Asus-K55VM-Repair-Guide.pdf). Spis je tam teda jen zkriplenej bios ktery vyzaduje pro neco tu grafiku mit v slotu.
1341
Hardware / Re:SSD - formát?
« kdy: 04. 08. 2020, 17:46:28 »Citace..., jen sem chtel upozornit ze nechavat volne misto na SSD je historicka zalezitost a dnes jiz v podstate FUDZe své zkušenosti Kingston a WD opravdu se zpomalí operace zejména s velkými soubory pokud se blíží zaplnění ke 100% (asi od 90% zaplnění při 500GB SSD) Znatelně pozorováno jak u NTFS, tak u ext4 file system. Myslím, že se problém vyřeší nástupem nových souborových systémů jako F2FS pro SSD vyvýjených. >>> Vhodné souborové systémy https://cs.wikipedia.org/wiki/Solid-state_drivevyrobce nechava na SSD nevyuzitej prostor nad ramec uzivateli dostupneho mista, ...
Ale tento problem nesouvisi se SSD - na svem 30TB poli, kdyz jsem mel poslednich 10GB, tak taky vsechno trvalo, protoze se ty data strasne fragmentuji - v podstate do kazde volne diry, namisto preferovane alokace pobliz inode/bitmap tabulky.
1342
Hardware / Re:Podozrenie na elektroniku disku
« kdy: 04. 08. 2020, 17:43:37 »
Pripoj ho normalne do zakladni desky (predtim v biosu povol na danem SATA portu hotplug).
Pres ten USB3 bridge to je fakt blby testovat, kdyz to ani nezpropaguje poradne identifikaci disku.. nechapu proc tam zanasis dalsi prvek, kde neco muze selhat.
Pres ten USB3 bridge to je fakt blby testovat, kdyz to ani nezpropaguje poradne identifikaci disku.. nechapu proc tam zanasis dalsi prvek, kde neco muze selhat.
1343
Hardware / Re:Graf. karta na NB Asus K55VM
« kdy: 04. 08. 2020, 17:38:19 »
Spis nez OS, je treba napsat co je to za hardware. Nektere notebooky maji typicke zavady ze umre diskretni grafika.
1344
Studium a uplatnění / Re:Přechod na IČO
« kdy: 03. 08. 2020, 23:33:57 »
Soude podle otazek, nemas na to pracovat sam na sebe. Mas takovej ten typicky nanynkovskej syndrom ze te pali dobre bydlo? V soucasne dobe pokud mas zamestnani, tak jsi na tom vlastne celkem dobre.
Jestli chces svobodu - zkus si to - samozrejme vcetne vsech rizik, nejsme tady tva pojistovna stesi - nebo si najmi pasaka co za tebe tyhle veci poresi za primerenej peniz :-)
Jestli chces svobodu - zkus si to - samozrejme vcetne vsech rizik, nejsme tady tva pojistovna stesi - nebo si najmi pasaka co za tebe tyhle veci poresi za primerenej peniz :-)
1345
Vývoj / Re:Přerušení v Linuxu
« kdy: 31. 07. 2020, 19:45:24 »
Jaky cip/zarizeni to je, co se snazis obslouzit?
1346
Sítě / Re:Optický kabel nebo metalika
« kdy: 31. 07. 2020, 13:11:11 »
Pokud je to kancelarska budova, tak si nechat zajistit pruchodky (zdmi, stropy) od majitele budovy.
1347
Hardware / Re:SSD pro systémový disk na desktopu
« kdy: 28. 07. 2020, 19:10:02 »
Klidne ti prodam 500GB Samsung 850 Evo :-)
1348
Vývoj / Re:Software-only USB host
« kdy: 27. 07. 2020, 00:19:58 »
Tak je pravda ze je to tak akurat na vybaveni neceho z pameti a poslani na port. Mozna v sw by to slo resit stylem predpocitanych translaci celych bajtu (jen ten stuffing na hranici bajtu znamena 5 ruznejch tabulek). Lze neco jako dvojurovnovy lookup udelat v DMA? nebo to umi pipelinovat bloky, ze zatimco se jeden posila, druhej se zaradi do fronty?
Pokud prestanes posilat SOFy, tak to znamena po 3ms "suspend"... reverzovat tento stav lze udalosti "resume", ktera je ale 20ms dlouha.. takze tohle ti podstatne zpomali jakoukoliv aktivitu - a taky muze resetovat ty casti ktere jsi chtel ladit.
Pokud prestanes posilat SOFy, tak to znamena po 3ms "suspend"... reverzovat tento stav lze udalosti "resume", ktera je ale 20ms dlouha.. takze tohle ti podstatne zpomali jakoukoliv aktivitu - a taky muze resetovat ty casti ktere jsi chtel ladit.
1349
Vývoj / Re:Software-only USB host
« kdy: 26. 07. 2020, 20:33:24 »
Implementace by mela byt takovato:
TX buffer kde bude predpocitany SOF, a pak vlozeny aktivni pakety. Odpali se to kazdou 1ms ven skrze GPIO DMA (nebo instrukcne presny busy loop), pro pozadovanou delku ktera se meni zda probiha aktivita ci nikoliv.. pro cokoliv si vystacis s implementaci 1 paketu s 64B payloadem + prislusne headry. Sw loop ma vyhodu ze si naskladas JK do 1/2 bitu, namisto zrejme bajtoveho pristupu ktery sezere 4-8x vice pameti. Tohle resi control+out pakety.
RX buffer kde se nasampluje response z IN paketu - at uz pres timer/dma, nebo znova v sw-loopu, se stejnym problemem co se tyce spotreby pameti jako u TX, ale aktivovat to postaci jen kdyz se pozaduje odezva.
To SOF musis posilat kazdou milisekundu, takze je to jedina casove kriticka/narocna cast (jinak ti po 3-7ms zaspi periferie). Protoze u USB je to host, kdo ridi deni na zbernici, takze si to osefujes jak je libo - klidne muzes dekodovat odezvu post-capture, jak dlouho chces.. jen na pozadi musis delat ty periodicke SOFy.
Pozor na to, ze u prevodu datoveho streamu na fyzicky JK stream nastava doplnovani o nejake dummy bity - takze ty buffery musi byt o neco delsi.
PS: Ukladat casy zmen ti nicemu nepomuzou a je to neefektivni - pac kodovani ma alespon tolik hran jako bitu - takze se spis snaz samplovat spravne (nebo oversamplovat). SW implementace by ti mela zabrat 64B (512bitu) + overhead rekneme 100% .. takze 1000 UI ... coz pri 1ms=12000 UI znamena zatez cpu jenom na 1/12 casu, pokud pujdes cestou 100% exkluzivity pro implementaci USB.
TX buffer kde bude predpocitany SOF, a pak vlozeny aktivni pakety. Odpali se to kazdou 1ms ven skrze GPIO DMA (nebo instrukcne presny busy loop), pro pozadovanou delku ktera se meni zda probiha aktivita ci nikoliv.. pro cokoliv si vystacis s implementaci 1 paketu s 64B payloadem + prislusne headry. Sw loop ma vyhodu ze si naskladas JK do 1/2 bitu, namisto zrejme bajtoveho pristupu ktery sezere 4-8x vice pameti. Tohle resi control+out pakety.
RX buffer kde se nasampluje response z IN paketu - at uz pres timer/dma, nebo znova v sw-loopu, se stejnym problemem co se tyce spotreby pameti jako u TX, ale aktivovat to postaci jen kdyz se pozaduje odezva.
To SOF musis posilat kazdou milisekundu, takze je to jedina casove kriticka/narocna cast (jinak ti po 3-7ms zaspi periferie). Protoze u USB je to host, kdo ridi deni na zbernici, takze si to osefujes jak je libo - klidne muzes dekodovat odezvu post-capture, jak dlouho chces.. jen na pozadi musis delat ty periodicke SOFy.
Pozor na to, ze u prevodu datoveho streamu na fyzicky JK stream nastava doplnovani o nejake dummy bity - takze ty buffery musi byt o neco delsi.
PS: Ukladat casy zmen ti nicemu nepomuzou a je to neefektivni - pac kodovani ma alespon tolik hran jako bitu - takze se spis snaz samplovat spravne (nebo oversamplovat). SW implementace by ti mela zabrat 64B (512bitu) + overhead rekneme 100% .. takze 1000 UI ... coz pri 1ms=12000 UI znamena zatez cpu jenom na 1/12 casu, pokud pujdes cestou 100% exkluzivity pro implementaci USB.
1350
Sítě / Re:Optika v novostavbě, na co si dát pozor ?
« kdy: 26. 07. 2020, 18:02:59 »minimalizoval rušení od siloviny.
Ruseni od siloviny je (minimalne v rodinnem domku) raritni chimera. Bezne se tahaji tluste svazky UTPcek na hranicni vzdalenosti (treba v halach velkoskladu) ve stejnych zlabech jako 220V a nikdy jsem v praxi nic takoveho nepotkal. Ani neznam nikoho dalsiho kdo by to potkal.
Ja menil v LED lampicce s lupou zdroj (na 230V) - koupil jsem nejakou cinu. Pri zapnuti lampy radio v pokoji ztraci signal a USB v blizkem pocitaci vypadava a bleje do dmesgu errory. Takze ruseni je realny - pokud se sejde vicero nestastnych faktoru.
