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 ... 51 52 [53] 54 55 ... 84
781
Windows a jiné systémy / Re:Tisk A5 na šířku
« kdy: 04. 11. 2019, 08:48:57 »
Souhlas s panem Jirsákem - soustředil bych se na tiskárny, které tisknou "po řádcích", tzn. původně jehličkové a po nich i inkoustovky. Nejlíp aby se papír zakládal do stojatého podavače (podavač to nabírá na spodní hraně). U laseru bych se nejspíš bál nadpřirozené inteligence = že pracuje s celými stranami a že si z ležatého podavače nebude umět podat papír poloviční délky. (Možná by šel podavač nepatrně mechanicky přizpůsobit.)

A jehla se dá dodnes koupit, ale bude to profi/business model za ne zcela lidovou cenu. Běžná A4 jehlička s traktorovým podavačem může dneska stát okolo 5-6 kKč. Nemám přehled, co je k dispozici business/poloprůmyslového s inkoustem... Jinak existují taky termotiskárny, ale ty jsem zatím potkal cca do formátu štítků 100x150 mm (nastojato). Pokud jde o značky, zmínil bych Datamax-O’Neil nebo Zebra.

V bance na přepážce jsem si všiml tiskáren, kam se vodorovně strčí do štěrbiny papír, tiskárna si ho vcucne, potiskne a vyplivne na stejnou plochu zpátky. Ale co to bylo za model, to netuším. Ani si nejsem jistý, jestli to je jehla nebo inkoust. Viz např.

782
Vývoj / Re:Jak vytvořit vlastní debugger?
« kdy: 03. 11. 2019, 22:13:23 »
Pánové děkuji za uvedení mého kategorického odsudku na pravou míru. Pokud ten interpreter zná eval(), a nebrání tomu nějaká další omezení, příležitost k partyzánské činnosti existuje :-)

783
Vývoj / Re:Jak vytvořit vlastní debugger?
« kdy: 02. 11. 2019, 16:34:03 »
Dostal se mi do rukou jeden interpreter. Konkrétne tento http://www.hansamanuals.com. Je v nej už neco naprogramováno a já řeším úpravy. Pro debug jsou akorát  alert okna nebo zápis do *.log souboru. No je to náročné. Tak vymýšlím jestli bych neudelal jednoduchý debuger. Neco jako vem řádek, vykonej, a ukaž všechny vnitřní promenné.

Rešil nekdo z vás neco podobné jinde?

Eh... cože? :-)

Obecná odpověď = chcete vyrobit source-level debugger pro nějaký interpretovaný jazyk. To by znamenalo jednu ze dvou možností:

A) nemáte zdrojáky od toho interpretru. V tom případě byste musel reimplementovat cca celý ten interpreter, pokud se má jednat o source-level debugging. A potažmo pak neladíte korektnost programu v proprietárním interpretru, ale ve Vašem reimplementovaném prostředí...

B) máte zdrojáky od toho interpretru. V tom případě se zanořte do vnitřností, a dopište do runtime prostředí nějaké ladící okno, které Vám bude ukazovat např. celý namespace (nebo těch několik dílčích namespaces = globální, lokální, co já vím), bude sledovat "aktuální pozici v programu" (něco jako instruction pointer) a umožní Vám se ve vnitřnostech toho interpretru hrabat. Pokud je to interpretované přímo řádku po řádce, je to ta jednodušší varianta. Nebo ještě pokud se to zkompiluje do "mezipodoby" = do nějakého stromu binárních objektů, jako to dělá Perl 5 - to by taky ještě šlo. Pokud se to zkompiluje do nějakého bytekódu ala Java (pro register-based virtual machine = ztratí se původní struktura programu), tak byste v tom bytekódu musel mít "ladící informace" (odkazy na řádky zdrojáku).

Konkrétně pokud se týče HansaWorld... to je celý nějaký ERP balík!? K tomu nebudou zdrojáky... Podle mého je to celé halucinace. Ledaže byste se dopátral, že má ten runtime nebo IDE nějaké dokumentované ladící API, proti kterému si můžete něco svého doprogramovat...

To je zajímavé. Býval bych si u Vás tipnul, že si tuhle odpověď dáte dohromady sám. Pořád koukám, kde jsem špatně pochopil otázku...

784
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 28. 10. 2019, 21:39:17 »
...
Tie male plastove bednicky kvalitou a vyrovnanostou zvuku (nie vykonom) prekonali moje doterazjsie pokusy o stavbu tranzistorovych zosilnovacov a ladenia vyhybiek, bassreflexov...
Odporucam ist do riesenia "C" aktivne repro s DSP a idealne aj aktivnou vyhybkou (bi-amp).

Pokud je na stole málo místa, tak by mohlo být správně i řešení "B" - ale ne že budou vedle monitoru jenom repráčky velké jako tenisáky. Spíš bych to viděl na bedýnky tak do 10 litrů objemu, jedno či dvoupásmové, menší basáky s poddajným závěsem, ta část na stole ať hraje třeba od 120 nebo 150 Hz nahoru - a pod stolem k tomu subwoofer. Tak by bylo pokryto celé pásmo, ale subwoofer by hrál skutečně jenom frekvence, u kterých už člověk nevnímá směrovost (fázi). A za ten subwoofer vás sousedi budou milovat.

785
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 28. 10. 2019, 21:32:40 »
Co sa tyka stavby repro, nejake zostavy sa daju najst na https://www.prodance.cz/ sekcia Mereni, a Ke stazeni (napr. https://www.prodance.cz/stavebnicemegaton.html)

Hezké kompletní stavebnice. Ale už na první pohled (EM121) spíš muzikantské nářadí. Veliké basáky, hornové výškáče = vysoká citlivost - ale v relativně malé bedně (v poměru k ploše membrány těch basáků) = odhadem spodní konec pásma bude dost vysoko. Odhad potvrzen v datasheetu: udávaný rozsah je až od 120 Hz (= ještě výš, než jsem čekal). Zatížitelnost 300W jenom dokresluje obrázek. Na domácí poslech to hodnotím jako spíše nevhodné.
Ale díky za odkaz, může se hodit.

786
Studium a uplatnění / Re:Jak se dostat k embedded, RTOS
« kdy: 28. 10. 2019, 21:19:42 »
Farlap jako přezdívka je čistě náhoda? :-)

787
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 27. 10. 2019, 08:05:28 »
Možná ještě jeden komentář:

k tomu "aby to hrálo dobře" = k ploché až "přislazené" přenosové křivce můžete mít v dnešní době dva až tři přístupy:

A) postaru = vícepásmové pasivní reprosoustavy s co nejplošším průběhem citlivosti, tzn. na spodním konci co největší bedna a správně k tomu připárovaný basreflex nebo TML,  poměrně složitá výhybka. Nejlíp byste měl mít nějaké vybavení, jak to ladit - buď profi, nebo na koleně + hodně znalostí. Zbytek řešit aktivními tónovými korekcemi. Nebo se v případě beden se vykašlat na chytristiku a udělat to co nejjednodušší - viz moje zmínka o větší bedně a širokopásmových reprákách.

B) "home cinema" = malé bedničky na stole a subwoofer někde v koutě. Těmto řešením často úplně chybí středobas, basový peak je dost ostrý a úzkopásmový, prostě to frekvenčně není vůbec vyrovnané - ale jako ušní výtěr pro neinformované laiky to i dneska asi stačí a někomu to může vyhovovat

C) dnes populární přístup: malý "chytrý reproduktor" nebo štíhlý soundbar. Objem ozvučnice na basovém konci pásma krutě malý, takže i relativně malé repráčky aby to nemělo sklon nechutně dunět (rezonovat vysoko), pasivní citlivost na basovém konci na houby (protože malá plocha membrán). Což se pokud možno dožene elektronickou korekcí. To znamená, že v elektrickém výstupu výkonového konce je hodně zvýrazněná basová složka. S tímto přístupem narazíte na mantinely napájecího napětí a mechanické výchylky membrán (basových) reproduktorů - ale pro relativně tichý poslech to stačí. Čili na basovém konci půjde o kompromis: netahat zbytečně odspoda, protože čím níž, tím větší amplitudy jsou potřeba, naopak ostře skončit možná radši trochu výš a tím získat na spodním konci trochu víc prostoru k elektronickému zvýraznění. Především jakožto profi výrobce takového integrovaného celku máte k dispozici dnešní moderní technologie: digitální signálový procesor (výpočetní výkon pro libovolné audio čarování dneska není problém) a výkonový konec ve třídě D (PWM = maximální využití mantinelů napájení, absence super-otravných zákmitů při "odběhu z clippingu"), a taky profi vybavení a tu nejlepší pozici, naladit digitální tónovou clonu tak, aby přesně invertovala neblahou přenosovou křivku pasivní části řetězce (ozvučnice a repráčků). A není asi ani problém, přenosovou charakteristiku ještě trochu "přisladit", případně "míru přislazení" přizpůsobovat nastavené úrovni hlasitosti (aby to i při vyšším Volume nějak hrálo a basáky nenarážely na doraz), snad i elektronicky vyrobit měkkou limitaci (clipping) a co já vím co všecko se dneska dá. Prostě moderní heslo "maximalizovat loudness".

Osobně mi dává smysl A) nebo C) - a co je v daném případě správné, to záleží na Vaší situaci, preferencích, zálibách apod. Podle mě jde vždycky hlavně o to, aby se člověk bavil podle svého :-) Život je krátkej.

788
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 27. 10. 2019, 01:27:32 »
BTW tady je hezky zdokumentována stavba beden svépomocí z MDF (nebo čeho), včetně dýhování povrchů a frézování děr.

789
Hardware / Re:Pomoc s výběrem audio sestavy
« kdy: 27. 10. 2019, 01:24:41 »
Jop... dvoupásmové bedničky, jmenovitá impedance 8 Ohmů. Výhybka 12 dB/okt. Vejškáč textilní kalota, basáky dva shodné čtyřohmové v sérii. Basáky mají ekvivalentní objem (pružnost) asi 13 litrů každej, bedna může mít vnitřní objem nějakých 18-20 litrů - tzn. těm basákům řádově odpovídá. Taky tomu objemu odpovídá relativně dlouhá basreflexová roura...
Nevypadá to špatně. Pokud víte, že nelze očekávat zázraky, tak Vás jistě neurazí, trochu si podle svého vytáhnout basy tónovou clonou ve zdroji signálu. Ty bedničky by měly tahat odspoda cca od 50 Hz (rezonanční frekvence popotažená basreflexem) což stačí na obstojný dusot.

Máte sousedy?

Za pár prvních sranda-vejplat jsem si kdysi taky cosi postavil... Bedny měly asi 250l každá - basáky o průměru 26 cm měly zhruba takový ekvivalentní objem a mně přišlo škoda to nevyužít :-) Rezonanci jsem natáhl basreflexem až někam ke 20 Hz. To už není běžně ani slyšet v hudebních nahrávkách (napadá mě "Stay with me"). Když jsem to trochu testoval sínusovým generátorem (nějaký audio editor v PC) tak to vybudilo kmitnu v opačném koutě bytu, takže já to kousek od beden skoro neslyšel (přestože bylo vidět, jak membrány dejchaj), ale máma přiběhla z obýváku, co je to za divný dunění. Jo to byly časy v rodinném domku u rodičů...

Možná ještě k tématu... než objednávat stavebnici z USA, jestli by to nešlo pořídit tady. Koukám ta stavebnice je holé MDF bez povrchové úpravy? Je na tom, pravda, trochu frézovací práce... Takovou superlevnou stavebnici tady kolem nějak nevidím, všichni prodávají dýhované skříně. Ona to ale nemusí být vysoká truhlařina, pokud ji z toho neuděláte. MDF je i tady dost běžný materiál, nebo můžete použít ještě mnohem běžnější lamino.
 
U nás v krajském městě mám asi kilometr od bydliště firmu, která naporcuje pravoúhlé přířezy z lamina (nebo i jiného materiálu) podle přání, podmínkou bývá odběr celé desky surového materiálu (některé prodávají i po půlkách). Lamino umí i ohranit. Dodáte nářezový plán a vyzvednete si nařezané obdélníčky olepené hranou. Nakreslit tu skládačku ve sketchupu snad není problém - jenom si předem zjistěte, u koho byste to nechal nařezat a jaké materiály mají k dispozici. Třeba lamino je běžně tlusté 18 mm (jiné tloušťky tolik k vidění nejsou) ale MDF je k dispozici v mnoha tloušťkách a dá se lepit Dispercolem prakticky na tupo (nebo můžete vlepit do rohů pro jistotu hranolky). Zkuste se rovnou i zeptat, jestli by zvládli taky kruhové díry na repráky - a pokud nebudete trvat na zafrézované polodrážce pro zapuštění repráku, bude to ještě menší problém. Pokud byste rád povrchovou úpravu, tak to nemusí být zrovna dýha, existují plastové samolepicí tapety (široký výběr v hobby marketech). Jinak ruční elektrická horní frézka je zajímavé nářadí, tím by se ta díra s polodrážkou dala zvládnout prakticky na koleně, stejně tak sražené vnější hrany na bednách apod. - spíš je problém "kde", v bytě asi těžko, ale třeba by se našel kamarád co má zahrádku, garáž apod.

Pokud se týče měničů, zkuste zvážit, jestli nepoužít širokopásmový reprák. Dělají se repráky s jedinou cívkou, které mají uprostřed velké membrány "pomocný trychtýřek" pro lepší vyzáření výšek. Přitom ekvivalentní objem můžou mít jako docela slušný basák, a taky tak hrají. Příklad: Monacor SP-200X (Vas=48l) nebo Visaton BG-20-8 (Vas=110l). Tzn. ušetříte si starosti s výhybkou, ušetříte jistou ztrátu citlivosti, dokonce mají jednopásmové repráky podle mého nejlepší podání "fáze" a potažmo stereo obraz, který žádná vícepásmová soustava nevyrobí... Mírný nadbytek citlivosti na vyšších středech případně dohnat tónovými korekcemi v zesilovači. Vzhledově je to trochu známka punku, to ponechám na Vašem vkusu :-)

Navrhnout bednu je trochu věda, ale existuje na to software. Konkrétně jsem tuším nedávno něco zkoušel v prográmku AJ Audio Vented Designer (download, screenshot). TS parametry se opíšou z datasheetu repráku, Dp znamená průměr basreflexové díry. Přijde mi škoda, že v tom softíku není možnost ten návrh nějak ovlivnit, třeba si nastavit naschvál menší bednu (navrhuje bedny dost velké, větší než ekvivalentní objem repráku) a pohrát si s rezonanční frekvencí basreflexu. Ale jako doporučení je to určitě bezva. S trochou zkušeností pak už zhruba víte, že menší bedna o něco zvýší rezonanční frekvenci (= spodní konec použitelného pásma) a že když to zkusíte zpátky natáhnout basreflexem (dáte delší trubku) tak to stejně už není ono... Potkal jsem už softy a online kalkulátory, kde měl člověk o něco větší svobodu, mrvit si tu ozvučnici trochu víc po svém. Třeba já jsem tuším ty svoje krávy veliké kdysi počítal v DOSu v něčem, co už nedohledám... Momentálně vypadá dobře excelová tabule zvaná Unibox.

Hloupé je, že ty větší repráky, co jsem zmínil, vedou optimálně na dost velkou bednu (mezi 50 a 100 litry). Pokud chcete malé bedničky, držte se menších měničů (průměr membrány, ekvivalentní objem). Velký basák v malém objemu dost ohavně duní... Dva basáky "akusticky paralelně" v jedné bedně znamenají tuším o 3 dB lepší citlivost, ale zase si mezi sebe musí rozdělit objem bedny = bude to mít vyšší rezonanční frekvenci, než kdyby tam stejně velký reprák byl jenom jeden...

790
Ono když z jakéhokoli důvodu provedete na tom vzdáleném desktopu logout, tak samospádem pochcípají všechny aplikace, co na tom desktopu běžely. Čili je na Vás se nějak ujistit, že skutečně došlo k zásahu nějakého OOM mechanismu, vs. že jste byl odhlášen kvůli timeoutu...

Odhadem se nejedná o problém toho typu, že prostě jenom uhnila konektivita - jsem zvyklý, že v tom případě desktop zůstane přihlášený a běží dál, lze se k němu znova připojit. Pravda je, že i toto chování je asi konfigurovatelné, a může být konfigurovatelné spíš na Windows Serveru, než na běžných klientských windowsech (vzdálená pomoc). Navíc jsem tyhle věci řešil osobně zatím jenom v TS Plus, kde jsou různé konfigurační volby a standardní MS triky v registrech shromážděny v jednom či dvou GUI dialozích - takže s konfigurací vanilkového MS RDS asi moc nepomůžu...

791
Vše se zpomalí a nakonec to zdechne... to nezní jako že "se náhle potkal motor s motorem", spíš něco sežralo všechnu paměť nebo procesor, eventuelně může přihnívat disk (buď kabel nebo samotná mechanika/médium tzn. vadné sektory). Toto by mělo být pozorovatelné a rozlišitelné. Třeba já jsem přestal používat Firefox pod Windows proto, že zejm. při větším množství tabů má sklon občas uletět ve spotřebě RAM a poslat OS do kotrmelců. Widle se prostě během pár desítek sekund uswapujou do té míry, že nezbývá, než je násilím restartovat (v lepším případě stihnete zabít FF a pak widle restartnout se všemi lichotkami a poctami, protože ta RAMka je zřejmě i tak už dost zfragmentovaná nebo co).

Kolik má ten stroj RAMky?

Taky si vybavuju situace, kdy běžící Windows Update service (nebo co) nemá svoji spotřebu řádně zohledněnu ve Správci Procesů - prostě se to tváří, jako že RAMky je dost, přestože reálně se ten stroj už dusí. Onehdá jsem už koukal, kde je schovaný nějaký rootkit apod. parazit, ale nakonec jsem naznal, že to jenom Windows Update přepočítává databázi závislostí, odmocňuje pí nebo co a tak podobně. Podobně se může chovat počáteční indexace zabudovaného fulltextového vyhledávání, nebo třeba pravidelný antivirový sken... Taky jsem zejm. s menším objemem RAM v určitých situacích pozoroval, že má microsoftí "engine pro správu databáze závislostí" v rámci Windows Update sklon, divergovat do jakéhosi podivného limba, kdy prakticky nešáhne na disk, ale žere celé CPU jádro a poměrně dost paměti, a když ho necháte, tak v téhle zfetované nirváně vydrží neomezeně dlouho (klidně přes víkend, tzn. obvykle do tvrdého restartu). Sice byly v průběhu let nějaké updaty, které to měly řešit, pokaždé "tentokrát už doopravdy", ale vídám to od dob Win7 skrz Win8 (zejm. před 8.1) až po některé konkrétní updaty Win10... Nebo se to pravidelně stane v případě, kdy použiju DISM na úklid WinSXS - nezávisle na objemu RAM.

Pod Windows býval standardní součástí systému prográmek "resource monitor" = resmon.exe. Tuším v novějších windowsech (10 a nové servery) se velká část dříve unikátních schopností Resmonu překlopila i do standardního "správce procesů" - jako třeba schopnost sledovat disk I/O transakce per proces, taky tuším nově jde vidět spotřeba jednotlivých servisek (nikoli pouze svchost.exe jako celek) apod. Takže doporučuji nastartovat na té vzdálené ploše resmon nebo jeho moderní ekvivalent a nechat běžet na liště. V momentě, kdy "se všechno zpomalí", rychle ho otevřít a podívat se, co se přesně děje, než to celé padne na hubu.

Rozlišit "disk se fláká, nejde na něj skoro žádný provoz" od "disk se nefláká, ale drhne, a proto si bere už jenom čůrek provozu" se dá nejsnáz pohledem na activity LEDku disku. Což předpokládá, že ten vzdálený počítač nějakou diskovou LEDku ještě má, a že je poblíž někdo, kdo by se podíval. Případně pro Windows existuje port smartctl.exe z balíku Smartmontools - ten taky ledacos ukáže. Neukáže sice activity LEDku, ale obsah SMART tabulky disku včetně logu chyb taky není k zahození :-) Bohužel to není až tolik užitečné na flashky/SSDčka.

A pokud to končí modrou, a podstatou není havárie v oblasti přístupu na disk, měl by na disku zůstat "bobek" zvaný crashdump. Ze kterého např. nástroj WhoCrashed dokáže zjistit aspoň driver, který modrou údajně hodil. Pokud je to pokaždé jiný driver, tak je problém ještě kdesi o kus dál = buď v HW nebo v jiném driveru, který hnojí náhodně kolem sebe.

Přeji úspěšný lov.

792
Ano tohle všechno v PHP funguje, ale je zde zásadní otázka: Proč dělat tyhle binární opičky, když je to už hotové, v knihovnách, napsáno v C/C++, takže je to i rychlé?

Já věděl, že se mám tentokrát zdržet komentáře :-)

793
S tím se váže otázka na používání funkcí chr a ord. Když bych do souboru chtěl zapsat uživatelská idečka a je třeba to udělat binárně a bezpečně tj. zkopírovat dva bajty s daným id, jak to správně udělat? Já znám jen ty dvě funkce chr a ord mám obavy o to, že tyhle věci budou náročné na výkon. A neměl bych taky řešit endianness (česky endianita?) správnost přečtení z binárního souboru?

Popravdě mi teprve teď došlo, že nemáte k dispozici Céčkový typový systém, pointerovou aritmetiku apod. Prostě všechen ten bordel, který umožňuje koukat na data střídavě jako na buffer binárních bajtů, nulou zakončený řetězec znaků, integer o potřebné délce na nějaké adrese apod. Takže nevím, jak s tím bufferingem. Má PHP aspoň něco jako perlový "binmode" režim souborů? Datový typ "buffer binárních bajtů", nebo třeba jenom stringy co nesmí obsahovat nulové bajty?

Ohledně endianity... procesor při aritmetických operacích očekává data uložená v RAMce v souladu s endianitou Vaší instrukční sady. Formát uložení binárních dat v souboru (nebo na síti) může mít nějaký standard, který endianitu jasně stanoví = může být potřeba, konvertovat indiány mezi instrukční sadou a diskovým formátem.

Koukám, že PHP má jenom jeden integer podle architektury, a to se znaménkem... Tzn. 16bit unsigned hodnota se Vám do něj nejspíš vejde bez problému. Jak k tomu přistupovat po bajtech... jakožto PHP analfabet, bez pointerové aritmetiky, bych se to asi pokusil ohnout pomocí bitwise operátorů, ty jsou zřejmě k dispozici. Levý a pravý shift, stejně jako masky používané s operací "AND" fungují na úrovni zdrojového textu všude stejně, nezávisle na indiánech v instrukční sadě = tyto operace použité ve zdrojáku jsou multiplatformní. A funkce ord() a chr() jsou myslím použitelné jenom na zobrazitelné ASCII znaky. Pokud potřebujete 16bit čísla ukládat buď jako dva bajty v binárním souboru nebo jako číslo v ASCII textu, podle mého budete potřebovat spíš sprintf()/sscanf() nebo něco na ten způsob (pro konverzi do/z ASCII formátu).

794
@Kit: Po jak velkých blocích je nejoptimálnější načítat data ze souboru? Dejmetomu, že mám texťák s emaily a id-éčkama uživatelů, na začátku je hlavička s rejstříkama cca 2KB. Je nějaký rozdíl v rychlosti či odezvě v tom jestli napoprvé načtu 2kB, 4kB nebo 8kB? Opakuji, že jde jen o první načtení hlavičky, z toho zjistím přesné umístění bloku, ve kterém hledat email po přihlášení; Takový blok by pak měl mít prakticky mezi 50-250 znaky. Takže i kdyby měl soubor 4MB, během přihlašování načtu jen hlavičku a pak ten hledaný blok.

Optimální by mělo být 8 KiB, protože to je obvyklá velikost bufferu.

To je totiž dobrá otázka :-(

Na úrovni blokové vrstvy a zřejmě i filesystému je dnes nejmenší optimální velikost přístupové transakce na x86 pravděpodoně 4 kB, což je obvyklá velikost stránky VM a obvyklá velikost sektoru na blokové vrstvě. A nejlíp ještě zarovnat na hranice 4 kB od začátku souboru. Filesystém sice alokuje ve větších "clusterech", ale ty IMO nemusí naráz číst a zapisovat. (Odhlédněme od faktu, že donedávna obvyklá velikost sektoru na disku bývala 512 B - ono to na věci možná mnoho neměnilo, vzhledem k tomu, jak funguje v UNIXu memory management v těsné spolupráci s blokovou vrstvou a souborovými systémy. A odhlédněme od existence "huge pages" na Linuxu a snad i jinde.)

A Kit má naopak pravdu v tom, že 8 kB/kiB je alokační jednotka Apache HTTPd "buckets", konkrétně:
Kód: [Vybrat]
/* default bucket buffer size - 8KB minus room for memory allocator headers */
#define APR_BUCKET_BUFF_SIZE   8000
Což osobně čtu tak, že user-space alokátor Apache si přidělenou virtuální paměť (přidělena kernelem po 4 kB) parceluje pro potřeby file IO po 8kB (8192 B), ale payloadu Vaší PHP aplikace z toho dává jenom 8 kiB (8000 B).

Kromě toho je v Linuxu na blokové vrstvě nějaký pevný read-ahead, by default to bývalo 128 kB. A nějaký svůj vlastní adaptivní read-ahead má souborová vrstva - a dá se tuším i ladit explicitním syscallem na otevřený file descriptor, což ale spousta softu nedělá. A při dlouhém sekvenčním zápisu jsem pozoroval, že Linux láme ten stream na ATA transakce dlouhé taky řádově pár set kB - a pokud moje transakce (předávané mým softwarem z user space) nebyly zarovnané na určité hranice mocniny dvou v LBA adresaci disku, tak mi je "lámal vejpůl", aby na blokové vrstvě na té hranici končil a začínal... už je to pár let, dneska to může být jinak.

Při čtení jednoho bloku (Vaše "hlavička") podle mého vůbec nemá smysl se zabývat velikostí čtecí transakce. Obecně důležité je, minimalizovat počet těch transakcí. Jestli načtete jenom 2 kB, které opravdu potřebujete, nebo budete spekulovat na celý bucket, to je myslím dost jedno. Tady bych doporučil: zbytečně to nedrobte. Pokud jde o jednu transakci, tak si prostě řekněte "svému prostředí" o ta data která potřebujete, ale netřeba to zbytečně nafukovat, nepomůžete si. Ony už si to "vrstvy mezi vámi a diskem" vhodně přifouknou a zarovnají (případně zlomí vejpůl, pokud se někde netrefíte na zarovnání).

Podle mého má smysl optimalizovat především *zápis*. Pokud máte data hezky za sebou = taková optimalizace je možná, zapisujte v co největších blocích (zas tak aby Vám to nezačlo dělat problémy s dostupným objemem RAM). Usnadníte tím práci fyzickým diskům - ať už se bude jednat o flash (erase bloky velké pár set kB až jednotky MB) nebo o točivý disk (pro transakce větší než 1 MB se průchodnost v random zátěži začíná blížit průchodnosti sekvenční). Nemá ale smysl, dělat kvůli tomu po svém nějaký read-ahead a write-back, protože potřebujete zapsat 1 B a chcete to systému usnadnit. To je blbost - pokud potřebujete drobné zápisy rozprostřené po ploše, tak se asi nedá nic dělat, a uděláte líp, když to necháte na operačním systému.

Obecně třeba ten bucketový systém v Apačovi je podle mého původně myšlen tak, aby bylo možno transparentně optimalizovat práci s daty na souborovém systému / na disku. A dost jsem se svého času vztekal, že konkrétně pro problém "mnoho paralelních čtoucích sekvenčních klientů nad točivým diskem" ty buckety rozhodně nejsou optimalizované a není je jak ladit. (Jednotná velikost bucketu, nulová možnost práce s maličkými transakcemi vs. s read-aheadem pro zjevně sekvenční streamy. Leda by člověk celou tu bucketovou vrstvu zásadně přepsal.) Asi to docela dobře sedí na VM vrstvu s její 4kB velikostí stránky.

795
Sítě / Re:Montáž 1U rackmount switche na stěnu
« kdy: 06. 10. 2019, 21:57:29 »
Hele, ty čtyři šroubky, za které drží každé rackmount ucho k plechovému šasi switche, nejsou náhodou ve čtvercové rozteči? Tzn. nedalo by se to ucho prostě jenom namontovat na switch otočené o 90* ? Viz HW quick install guide, str.4. (Jako u D-linku...)

Ovšem pokud by k tomu měl být ještě patch-panel, nebo dva nebo tři, pro zakončení "pevných vedení" (strukturky), tak už je to skutečně zralé na nějaký "EIA vingl" nebo malý rack...

Stran: 1 ... 51 52 [53] 54 55 ... 84