A k CRTčkům - onehdá revoluční technologie Sony Trinitron - dvě viditelné vodorovné linky po zpevňujících drátcích zcela jistě zabíraly mnohem větší plochu než pár/6000000! a jak byla chválená, prodávaná a kopírovaná dalšími výrobci!
Odpovědět0 0
Navíc srovnání s onou bankovkou je holý nesmysl. Bankovka váží zhruba 1g. Je zcela jisté, že pouhým zasunutím a vysunutím z peněženky dojde otěrem k větší ztrátě než 1ug (což je zhruba stejný poměr jako 6 vadných subpixelů na FullHD displeji) a přesto každá banka takto "poškozenou" bankovku zcela jistě PŘIJME!!!
Odpovědět0 0
Vzhledem k tomu, že po většinu času procsory čekají na intervenci uživatele není pro výsledné TCO důležitá špičková spotřeba, ale klidová spotřeba (zejména s technologií postupného vypínání jader ve W7). Nejsem první komu tento údaj chybí, není možné jej ještě (alespoň orientačně) doplnit?
Ještě u porovnávání cen a spotřeby nebo cen a výkonu by bylo asi vhodnější uvést než dva sloupečky klasický poměr (resp. součin).
Jinak určitě palec nahoru.
Ještě u porovnávání cen a spotřeby nebo cen a výkonu by bylo asi vhodnější uvést než dva sloupečky klasický poměr (resp. součin).
Jinak určitě palec nahoru.
Odpovědět0 0
Tak třeba tři důvody pro dělenou plochu:
Spravuji a vzdálenou plochou se denně připojuji k desítkám serverů. Na primárním displeji mám místní nástroje (Outlook, skrývací lištu, zástupce na ploše,...) a právě na sekundárním displeji (s věším rozlišením) maximalizuji vzdálenou plochy připojeného serveru. Je to vlastně jako další počítač se stejnou myší a klávesnicí. Samozřejmě podobného efektu mohu dosáhnout organizací oken na jednom širokoúhlém displeji s vyšším rozlišením, ale:
1. organizace je složitější a pomalejší než prostá maximalizace, kterou si navíc RDP klient pamatuje, resp. je uložena v RDP souboru. Vím, že lze uložit i tu pozici a velikost, ale opět je to složitější a jak se svým notebookem pracuji z práce (1280x1024) nebo z domu (1680x1050) nebo z cest (často jsem rád i za sekundár s 1024x768), tak bych vše musel nastavovat třikrát a mít tři sady zástupců...
2. skrývací lištu na vzdáleném serveru "vytáhnu" prostým "naražením" myši na okraj. Žádné přesné trefování na pixel okraje okna...
3. pokud už jen tak dobrouzdávám apod. a nepotřebuji velkou plochu, tak prostě druhý výstup vypnu. Anebo při výpadku proudu...
Spravuji a vzdálenou plochou se denně připojuji k desítkám serverů. Na primárním displeji mám místní nástroje (Outlook, skrývací lištu, zástupce na ploše,...) a právě na sekundárním displeji (s věším rozlišením) maximalizuji vzdálenou plochy připojeného serveru. Je to vlastně jako další počítač se stejnou myší a klávesnicí. Samozřejmě podobného efektu mohu dosáhnout organizací oken na jednom širokoúhlém displeji s vyšším rozlišením, ale:
1. organizace je složitější a pomalejší než prostá maximalizace, kterou si navíc RDP klient pamatuje, resp. je uložena v RDP souboru. Vím, že lze uložit i tu pozici a velikost, ale opět je to složitější a jak se svým notebookem pracuji z práce (1280x1024) nebo z domu (1680x1050) nebo z cest (často jsem rád i za sekundár s 1024x768), tak bych vše musel nastavovat třikrát a mít tři sady zástupců...
2. skrývací lištu na vzdáleném serveru "vytáhnu" prostým "naražením" myši na okraj. Žádné přesné trefování na pixel okraje okna...
3. pokud už jen tak dobrouzdávám apod. a nepotřebuji velkou plochu, tak prostě druhý výstup vypnu. Anebo při výpadku proudu...
Odpovědět0 0
Jestli jste si nevšiml, své výpočty jsem prováděl právě přes střední dobu poruchovosti (tj. MTBF).
Dále jsem po necelých 18 minutách doplnil pojednání ohledně vanové křivky (možná se to nyní jmenuje von Neumannovo rozložení - za mých studií tomu tak nebylo) a také jsem jasně zdůvodnil, proč jsem použil právě rozložení odpovídající bílému šumu, které dobře odpovídá období stability.
.
Při ignoroci pouze období dětských nemocí, ale počítání s obdobím dožití, by pak špička dožití vanové křivky šla poměrně přesně aproximovat právě gaussovým rozložením, ke kterému by ale bylo nutné znát i střední kvadratickou odchylku. Ta se ale bohužel neuvádí. Nicméně z hlediska tvaru vzestupné části gaussovy křivky věřte, že pro malá časová období oproti vrcholu (v uvedeném příkladě 3 roky versus 137 let) je ono rozložení bílého šumu pro výslednou pravděpodobnost horším případem. Ve skutečnosti tedy bude p ještě o něco menší a jak jsem popsal, čím menší je p, tak pro dva disky je výsledná pravděpodobnost blíže k dvojnásobku (limitně jde přesně k dvojnásobku).
.
Otočit gaussovu křivku - co to je za nesmysl... Integrál za celou dobu musí být 1 (100%), tedy okraje musí být v nule... Nemá cenu to asi rozebírat, to je už úlet zcela mimo téma.
.
.
.
"Kdo vyhrál": nevím proč pořád porovnáváte s číslem vypočteným z p=10%. Na konkrétním disku s konkrétním použitím jsem jasně spočetl, že p<1% a tímto pojednáním ukázal, že ještě o něco menší... Při pesimistickém přístupu a volbě p=1% pak vychází výsledná pravděpodobnost poruchy dvou disků 1,99% a
1,99 > 1,9783
:-)
P.S. Při reálném p<1% to tedy bude ještě o něco blíže k té dvojce...
Dále jsem po necelých 18 minutách doplnil pojednání ohledně vanové křivky (možná se to nyní jmenuje von Neumannovo rozložení - za mých studií tomu tak nebylo) a také jsem jasně zdůvodnil, proč jsem použil právě rozložení odpovídající bílému šumu, které dobře odpovídá období stability.
.
Při ignoroci pouze období dětských nemocí, ale počítání s obdobím dožití, by pak špička dožití vanové křivky šla poměrně přesně aproximovat právě gaussovým rozložením, ke kterému by ale bylo nutné znát i střední kvadratickou odchylku. Ta se ale bohužel neuvádí. Nicméně z hlediska tvaru vzestupné části gaussovy křivky věřte, že pro malá časová období oproti vrcholu (v uvedeném příkladě 3 roky versus 137 let) je ono rozložení bílého šumu pro výslednou pravděpodobnost horším případem. Ve skutečnosti tedy bude p ještě o něco menší a jak jsem popsal, čím menší je p, tak pro dva disky je výsledná pravděpodobnost blíže k dvojnásobku (limitně jde přesně k dvojnásobku).
.
Otočit gaussovu křivku - co to je za nesmysl... Integrál za celou dobu musí být 1 (100%), tedy okraje musí být v nule... Nemá cenu to asi rozebírat, to je už úlet zcela mimo téma.
.
.
.
"Kdo vyhrál": nevím proč pořád porovnáváte s číslem vypočteným z p=10%. Na konkrétním disku s konkrétním použitím jsem jasně spočetl, že p<1% a tímto pojednáním ukázal, že ještě o něco menší... Při pesimistickém přístupu a volbě p=1% pak vychází výsledná pravděpodobnost poruchy dvou disků 1,99% a
1,99 > 1,9783
:-)
P.S. Při reálném p<1% to tedy bude ještě o něco blíže k té dvojce...
Odpovědět0 0
Jo v mailu jsem přehlédl první odstaveček. Jak jsem se zmínil, poruchovost v přírodě se řídí tzv. vanovou křivkou (a nejedná se jen o techniku, ale třeba i o živé tvory). Nejprve je období vysoké poruchovosti - tzv. období dětských nemocí, pak je období stability s velmi nízkou pravděpodobností poruchy a pak nastupuje období dožití, kdy pravděpodobnost začíná opět růst. Oněch zmíněných 2-8% reklamací je právě z období dětských nemocí (a vůbec záruční doba je právě kvůli tomuto období) a jedná se zejména o případy, kdy se disk nerozjede ani na poprvé. Pak ale z něj ani nemáte příležitost RAID0 vytvořit (P.S. kategorii disků s 8% reklamací raději nebrat, brrrr). Dále znám lidi, kteří počítačové komponenty záměrně ničí těsně před koncem záruční doby, kdy už se navíc daný model nevyrábí a pak (pokud se neprokáže úmyslné poškození) ze zákona musí dostat adekvátní náhradu - obvykle si tedy zdarma značně polepší... nebo vrátit původní cenu, za kterou si koupí modernější a s novou zárukou...
Ve svých výpočtech jsem tedy počítal s obdobím stability, kdy je rozložení pravděpodobnosti poruchy blízké bílému šumu.
Ve svých výpočtech jsem tedy počítal s obdobím stability, kdy je rozložení pravděpodobnosti poruchy blízké bílému šumu.
Odpovědět0 0
Když už tak už 19%/10% = 1,9 násobek (opomíjím překlep 1.9873-nasobek - správně je 1.9783-nasobek). Navíc s těmi 10% tu kalkulujete Vy, já tvrdím, že p<10% (ono se totiž ve statistice zrovna těch 10% považuje za hranici, kdy lze pravděpodobnosti pro zjednodušení sčítat, podobně jako sin x=x (v radianech) pro úhly do 4,5°).
Pojďme ale k reálným diskům: např. disk Hitachi Ultrastar A7K1000 má udávanou střední dobu bezporuchového provozu (MTBF) 1200000 h, tj. cca 137 let nepřetržitého provozu. To znamená, že za 137 let se jich porouchá 50%. Abychom určili, kdy jich bude poroucháno Vašich 10% potřebovali bychom znát střední kvadratickou odchylku (tj. šířku gaussova rozložení, příp. další parametry ještě lépe odpovídající vanové křivky poruchovosti), což se ale běžně neuvádí. Za značného zjednodušení lze ale odhadnout, že 10% těchto disků se porouchá za cca 30 let provozu (vzato v potaz mírné zpomalování růstu výsledné pravděpodobnosti s časem - viz. můj první dlouhý příspěvek). To už ten disk určitě bude morálně dávno po totální smrti - vzpomeňte si na disky z roku 1978 :-D. Budu-li počítat s reálnými 3 lety provozu bez jakéhokoliv zálohování dostávám stále p<1%. Budu pesimistický a vezmu p=1%. Pravděpodobnost selhání jednoho ze dvojice těchto disků potom je 1,99%.
No a kde jsme? 1,99%/1%=1,99-násobek... Kdo vyhrál? ;-)
Pojďme ale k reálným diskům: např. disk Hitachi Ultrastar A7K1000 má udávanou střední dobu bezporuchového provozu (MTBF) 1200000 h, tj. cca 137 let nepřetržitého provozu. To znamená, že za 137 let se jich porouchá 50%. Abychom určili, kdy jich bude poroucháno Vašich 10% potřebovali bychom znát střední kvadratickou odchylku (tj. šířku gaussova rozložení, příp. další parametry ještě lépe odpovídající vanové křivky poruchovosti), což se ale běžně neuvádí. Za značného zjednodušení lze ale odhadnout, že 10% těchto disků se porouchá za cca 30 let provozu (vzato v potaz mírné zpomalování růstu výsledné pravděpodobnosti s časem - viz. můj první dlouhý příspěvek). To už ten disk určitě bude morálně dávno po totální smrti - vzpomeňte si na disky z roku 1978 :-D. Budu-li počítat s reálnými 3 lety provozu bez jakéhokoliv zálohování dostávám stále p<1%. Budu pesimistický a vezmu p=1%. Pravděpodobnost selhání jednoho ze dvojice těchto disků potom je 1,99%.
No a kde jsme? 1,99%/1%=1,99-násobek... Kdo vyhrál? ;-)
Odpovědět0 0
Ano, máte pravdu, že v případě NAS má celé zařízení svou paměť, kterou používá i jako cache a v tomto případě může nahodile vyřídit souběh dvou požadavků rychleji i než RAID0. Nedosáhnete toho ale cíleně...
Navíc NAS obvykle nepoužijete jako primární disk pro operační systém (neberu v potaz drahé Fibrechannel nebo zastaralé SCSI řešení), protože režije Ethernetu je u malých přenosů obrovská a zejména latence bufferů výrazně degraduje výkon, ale jako large storage. Pro tento případ je ale opět výhodnější RAID0 (mám-li stejně velké disky...)
Obecně JBOD přináší jedinou výhodu - zvýšení kapacity s různě velkými disky a není jeho smyslem honit výkon (nemá ve zkratce ono R). Mám-li stejně velké disky, nejlépe i stejný model, pak je bez diskuzí lepší RAID a level volím podle potřeb konkrétní aplikace. Z důvodu snížení rizika ztráty dat pak v době NTFS je lepší se JBODu vyhnout a použít NTFS reparse pointy, příp. Volume Sety.
Navíc NAS obvykle nepoužijete jako primární disk pro operační systém (neberu v potaz drahé Fibrechannel nebo zastaralé SCSI řešení), protože režije Ethernetu je u malých přenosů obrovská a zejména latence bufferů výrazně degraduje výkon, ale jako large storage. Pro tento případ je ale opět výhodnější RAID0 (mám-li stejně velké disky...)
Obecně JBOD přináší jedinou výhodu - zvýšení kapacity s různě velkými disky a není jeho smyslem honit výkon (nemá ve zkratce ono R). Mám-li stejně velké disky, nejlépe i stejný model, pak je bez diskuzí lepší RAID a level volím podle potřeb konkrétní aplikace. Z důvodu snížení rizika ztráty dat pak v době NTFS je lepší se JBODu vyhnout a použít NTFS reparse pointy, příp. Volume Sety.
Odpovědět0 0
1. V reálu je pravděpodobnost přesného střídání požadavků mezi dva disky na kterých jsou náhodně rozmístěny soubory jdoucí k nule.
2. Řadič JBOD by musel dávat požadavky asynchronně a tedy mít svou cache. U kvalitnějších řadičů (s cache pamětí) jsem obvykle variantu JBOD ani neviděl...
Jde tedy pouze o akademickou úvahu...
2. Řadič JBOD by musel dávat požadavky asynchronně a tedy mít svou cache. U kvalitnějších řadičů (s cache pamětí) jsem obvykle variantu JBOD ani neviděl...
Jde tedy pouze o akademickou úvahu...
Odpovědět0 0
P.S. Z pohledu jazyka: Omlouvám se za malé překlepy (ZDALEKO,...).
"howgh" = nemíním o tom diskutovat... (diskutujte si sami :-))
"howgh" = nemíním o tom diskutovat... (diskutujte si sami :-))
Odpovědět0 0
Vážení pánové, jste jak malí kluci... Na Vaší debatě mne docela baví akademické rozebírání slovních spojení "ZDALEKA NE" a "SKORO", ale nebaví mne Vaše vzájemné útočení.
Pokud se budeme zabývat matematikou, tak:
Matematika mne bavila a potvrzuji, že uvedené výpočty i vzorečky jsou správné (jedinou mýlkou byla chybná úvaha přičíst již započtené, ale tuto chybu v0cas SÁM opravil a je jedno jestli cca 87 min. je "skoro zdaleka ne" hned.) Ze vzorečku vyplývá, že pravděpodobnost vzniku alespoň jednoho děje ze dvou stejně velmi nepravděpodobných je SKORO dvojnásobná (limitně pro p->0 až k PŘESNĚ dvojnásobné). S rostoucím p výsledná pravděpodobnost sice roste, ale čím dál pomaleji až pro p=1 dosáhne 1, tedy POUHÉHO jednonásobku, což opravdu "ZDALEKA NENÍ" dvojnásobek.
Já doufám, že ve světě disků co kupuji je pravděpodobnost selhání v době morální životnosti VÝRAZNĚ menší než oněch 10% - mám i disky o "obrovské" kapacitě 2GB (tedy morálně dávno po smrti) a jsou stále funkční. Pokud počítáte s tak závratnou pravděpodobností poruchy, pak buď používáte disky ještě starší (nevím proč se pak bavit o výkonu) nebo je používáte mimo specifikace výrobce (agresívní prostředí, vibrace,...) nebo máte nějaké opravdu shitózní (já kupuji pouze některé značky, nemohu tedy psát za všechny disky).
Důležitá pro nás je HLAVNĚ pravděpodobnost rizika ztráty dat, zvláště u RAID0 či JBOD zapojení. Pravděpodobnost ztráty i u sebedokonalejších disků je sice malá (a u uvedených zapojení SKORO n-násobná) je ale REÁLNÁ. A proto by jsme měli zálohovat, že? Zálohováním zkrátíme interval, ve kterém sledujeme riziko selhání disku a tedy i ono základní p. A jak jsem uváděl, čím nižší p, tím je celková pravděpodobnost VÍCE SKORO n-násobná.
Pokud se budeme zabývat jazykem, tak:
Káždé malé dítě zná rozdíl mezi ZDALEKA NE a SKORO. Je jasné, že v různých aplikacích se rozdíl mezi těmito slovy výrazně posouvá (např. u amerických pokusů zasáhnout jednu letící raketu jinou, vypuštěnou z místa i několik tisíc km vzdáleného, která ale mine o pár metrů (odchylka řádově 0,0001%), pak se nesporně SKORO trefili, ale ZDALEKO to NEpřineslo očekávaný výsledek :-)).
Pravdou je, že v prvotním příspěveku chmod777 správně narážel na autorovu nepřesnost a použil k tomu autorův slovník (parafrázoval jej). Tato parafráze ale přinášela subjektivní dojem, že to nebude až tak špatné, což není pravda. Proto zcela chápu v0case, který na to reagoval akorát nemusel hned útočně. Na to stačilo chmod777-em odpovědět "Máte pravdu, parafrázoval jsem autora, což je znázorněno i uvozovkami." A ne psát zjevnou nepravdu "Presne to jsem totiz napsal (ze je hodne vyssi, nikoliv vsak dvojnasobna)." versus "podstatně vyšší pravděpodobnosti ztráty dat (zdaleka však ne dvojnásobné)".
Pokud se budem zabývat pohledem disků (a ten by asi měl být hlavní), tak:
Čím více je SKORO dvojnásobná, tím vlastně lépe, protože předpokladem je nižší základní p a tedy i celková výsledná pravděpodobnost... :-)
Ještě můžeme srovnávat které ZDALEKA NE je více zdaleka a které skoro. Do toho vstupují dva faktory - doba používání disků bez zálohování (s ní roste základní p) a způsob používání (druh ukládaných dat). Budeme-li se držet morálního věku disků (po něm používat RAID0 nebo JBOD je absolutním nesmyslem, protože koupě nového i jediného low endového disku přinese za pár drobných vyšší výkon i kapacitu při nižší spotřebě a hluku), pak p<0,1 a je na místě spojení SKORO "howgh".
Dále se budu zabývat technologií RAID0 (JBOD nepřináší žádné zrychlení, tedy ZDALEKA NE dvojnásobné je správně). Technologie RAID0 rozděluje data na jednotlivé disky v proužcích (tzv. stripech), které mají velikost 8 KiB - 1 MiB.
Budeme-li na disku mít malé soubory (menší než velikost stripu - různé tmp soubory, ikonky, polovina dll Windows je do 64 KiB,..) nebo střední soubory (příp. i velké - swap, logy, DB,...) s náhodným přístupem (jednorázový přenos menší než velikost stripu), pak RAID0 nevede k žádnému zrychlení, ale naopak (díky režii) k mírnému zpomalení. Zde je tedy na místě spojení ZDALEKA NE "howgh".
Zrychlení pomocí RAID0 můžeme dosáhnout pouze při ukládání velkých souborů s převážně sekvenčním přístupem (typ. multimédia nebo zálohování), kdy mohou oba disky zpracovávat data paralelně. Aby to ale bylo možné, musí k tomu dostat asynchronní pokyny od řadiče a ten musí rozdělit/sloučit data od/pro operační systém (ten se tím obvykle nezabývá - ignoruji SW RAID0, který není výkonově zajímavý). To že řadič podporuje RAID0 neznamená, že toto umí!!! - k tomu totiž potřebuje značnou vlastní cache paměť! Bez těchto vlastností je výsledná rychlost spíše loterií - vyšší režie=zpomalení, NCQ, cache disků a náhodný soulad řadiče s rytmem otáček a tedy nájezdu správného místa plotny pod hlavičku může vést k náhodnému zrychlení, ale opravdu NE ZDALEKA dvojnásobnému. Budeme-li mít profesionální (serverový) řadič RAID (typ. SCSI nebo SAS) s cache pamětí i pro zápis (předpoklad bateriové zálohy pro případ výpadku napájení), pak pouze v tomto případě můžeme začít používat slovíčko SKORO dvojnásobný. SCSI i SAS disky mají ale nižší p než obyčejné disky a tedy zodpovědně mohu tvrdit, že toto SKORO bude dál než ta SKORO dvojnásobná pravděpodobnost.
Shrnu-li statisticky všeobecné používání disků, je spojení "ZDALEKA NE" u výkonu opravdu na místě "howgh".
Pokud se budeme zabývat matematikou, tak:
Matematika mne bavila a potvrzuji, že uvedené výpočty i vzorečky jsou správné (jedinou mýlkou byla chybná úvaha přičíst již započtené, ale tuto chybu v0cas SÁM opravil a je jedno jestli cca 87 min. je "skoro zdaleka ne" hned.) Ze vzorečku vyplývá, že pravděpodobnost vzniku alespoň jednoho děje ze dvou stejně velmi nepravděpodobných je SKORO dvojnásobná (limitně pro p->0 až k PŘESNĚ dvojnásobné). S rostoucím p výsledná pravděpodobnost sice roste, ale čím dál pomaleji až pro p=1 dosáhne 1, tedy POUHÉHO jednonásobku, což opravdu "ZDALEKA NENÍ" dvojnásobek.
Já doufám, že ve světě disků co kupuji je pravděpodobnost selhání v době morální životnosti VÝRAZNĚ menší než oněch 10% - mám i disky o "obrovské" kapacitě 2GB (tedy morálně dávno po smrti) a jsou stále funkční. Pokud počítáte s tak závratnou pravděpodobností poruchy, pak buď používáte disky ještě starší (nevím proč se pak bavit o výkonu) nebo je používáte mimo specifikace výrobce (agresívní prostředí, vibrace,...) nebo máte nějaké opravdu shitózní (já kupuji pouze některé značky, nemohu tedy psát za všechny disky).
Důležitá pro nás je HLAVNĚ pravděpodobnost rizika ztráty dat, zvláště u RAID0 či JBOD zapojení. Pravděpodobnost ztráty i u sebedokonalejších disků je sice malá (a u uvedených zapojení SKORO n-násobná) je ale REÁLNÁ. A proto by jsme měli zálohovat, že? Zálohováním zkrátíme interval, ve kterém sledujeme riziko selhání disku a tedy i ono základní p. A jak jsem uváděl, čím nižší p, tím je celková pravděpodobnost VÍCE SKORO n-násobná.
Pokud se budeme zabývat jazykem, tak:
Káždé malé dítě zná rozdíl mezi ZDALEKA NE a SKORO. Je jasné, že v různých aplikacích se rozdíl mezi těmito slovy výrazně posouvá (např. u amerických pokusů zasáhnout jednu letící raketu jinou, vypuštěnou z místa i několik tisíc km vzdáleného, která ale mine o pár metrů (odchylka řádově 0,0001%), pak se nesporně SKORO trefili, ale ZDALEKO to NEpřineslo očekávaný výsledek :-)).
Pravdou je, že v prvotním příspěveku chmod777 správně narážel na autorovu nepřesnost a použil k tomu autorův slovník (parafrázoval jej). Tato parafráze ale přinášela subjektivní dojem, že to nebude až tak špatné, což není pravda. Proto zcela chápu v0case, který na to reagoval akorát nemusel hned útočně. Na to stačilo chmod777-em odpovědět "Máte pravdu, parafrázoval jsem autora, což je znázorněno i uvozovkami." A ne psát zjevnou nepravdu "Presne to jsem totiz napsal (ze je hodne vyssi, nikoliv vsak dvojnasobna)." versus "podstatně vyšší pravděpodobnosti ztráty dat (zdaleka však ne dvojnásobné)".
Pokud se budem zabývat pohledem disků (a ten by asi měl být hlavní), tak:
Čím více je SKORO dvojnásobná, tím vlastně lépe, protože předpokladem je nižší základní p a tedy i celková výsledná pravděpodobnost... :-)
Ještě můžeme srovnávat které ZDALEKA NE je více zdaleka a které skoro. Do toho vstupují dva faktory - doba používání disků bez zálohování (s ní roste základní p) a způsob používání (druh ukládaných dat). Budeme-li se držet morálního věku disků (po něm používat RAID0 nebo JBOD je absolutním nesmyslem, protože koupě nového i jediného low endového disku přinese za pár drobných vyšší výkon i kapacitu při nižší spotřebě a hluku), pak p<0,1 a je na místě spojení SKORO "howgh".
Dále se budu zabývat technologií RAID0 (JBOD nepřináší žádné zrychlení, tedy ZDALEKA NE dvojnásobné je správně). Technologie RAID0 rozděluje data na jednotlivé disky v proužcích (tzv. stripech), které mají velikost 8 KiB - 1 MiB.
Budeme-li na disku mít malé soubory (menší než velikost stripu - různé tmp soubory, ikonky, polovina dll Windows je do 64 KiB,..) nebo střední soubory (příp. i velké - swap, logy, DB,...) s náhodným přístupem (jednorázový přenos menší než velikost stripu), pak RAID0 nevede k žádnému zrychlení, ale naopak (díky režii) k mírnému zpomalení. Zde je tedy na místě spojení ZDALEKA NE "howgh".
Zrychlení pomocí RAID0 můžeme dosáhnout pouze při ukládání velkých souborů s převážně sekvenčním přístupem (typ. multimédia nebo zálohování), kdy mohou oba disky zpracovávat data paralelně. Aby to ale bylo možné, musí k tomu dostat asynchronní pokyny od řadiče a ten musí rozdělit/sloučit data od/pro operační systém (ten se tím obvykle nezabývá - ignoruji SW RAID0, který není výkonově zajímavý). To že řadič podporuje RAID0 neznamená, že toto umí!!! - k tomu totiž potřebuje značnou vlastní cache paměť! Bez těchto vlastností je výsledná rychlost spíše loterií - vyšší režie=zpomalení, NCQ, cache disků a náhodný soulad řadiče s rytmem otáček a tedy nájezdu správného místa plotny pod hlavičku může vést k náhodnému zrychlení, ale opravdu NE ZDALEKA dvojnásobnému. Budeme-li mít profesionální (serverový) řadič RAID (typ. SCSI nebo SAS) s cache pamětí i pro zápis (předpoklad bateriové zálohy pro případ výpadku napájení), pak pouze v tomto případě můžeme začít používat slovíčko SKORO dvojnásobný. SCSI i SAS disky mají ale nižší p než obyčejné disky a tedy zodpovědně mohu tvrdit, že toto SKORO bude dál než ta SKORO dvojnásobná pravděpodobnost.
Shrnu-li statisticky všeobecné používání disků, je spojení "ZDALEKA NE" u výkonu opravdu na místě "howgh".
Odpovědět0 0
To je redukce na PATA. Redukce na SATA není třeba (jde pouze o mechanické upevnění disku do skříně...
Odpovědět0 0
Ono těch chybiček bude více:
1. Jestli si matně vzpomínám,tak u CHS bylo 10b na cilindr, 4b na hlavu a <b>6b</b> (nikoliv 8b) na sektor.
Z toho pak i vychází onen limit 512 MiB (2^(10+4+6)* 512B (velikost jednoho sektoru) - výpočet je zjednodušen, protože sektory se nepočítají od 0, ale od 1, 1. celý cylindr je na MBR,...).
2. Běžně jsem zapojoval CD-ROM jako secondary slave i bez masteru a vždy to fungovalo správně a to i pro BIOS (tedy i boot z CD). S hard diskem v režimu Slave bez Masteru je to horší, ale pouze co se BIOSu týče. Windows NT a vyšší si s tím vždy poradil (pokud nebyl bootovací - tam je akceptace BIOSem nutná). V mé stávající desce (pouze jeden PATA) z takto zapojeného disku (ve výměnném šuplíku) i bootuji, pouze BIOS zareptá, že nenašel master disk a pro pokračování musím stisknout F1. P.S. vím, že je to oficiálně nepodporované zapojení, ale nepsal bych "nefungovalo by".
Při čtení jsem narazil ještě na nějaké další drobnosti, ale ty jsemm už vypustil...
1. Jestli si matně vzpomínám,tak u CHS bylo 10b na cilindr, 4b na hlavu a <b>6b</b> (nikoliv 8b) na sektor.
Z toho pak i vychází onen limit 512 MiB (2^(10+4+6)* 512B (velikost jednoho sektoru) - výpočet je zjednodušen, protože sektory se nepočítají od 0, ale od 1, 1. celý cylindr je na MBR,...).
2. Běžně jsem zapojoval CD-ROM jako secondary slave i bez masteru a vždy to fungovalo správně a to i pro BIOS (tedy i boot z CD). S hard diskem v režimu Slave bez Masteru je to horší, ale pouze co se BIOSu týče. Windows NT a vyšší si s tím vždy poradil (pokud nebyl bootovací - tam je akceptace BIOSem nutná). V mé stávající desce (pouze jeden PATA) z takto zapojeného disku (ve výměnném šuplíku) i bootuji, pouze BIOS zareptá, že nenašel master disk a pro pokračování musím stisknout F1. P.S. vím, že je to oficiálně nepodporované zapojení, ale nepsal bych "nefungovalo by".
Při čtení jsem narazil ještě na nějaké další drobnosti, ale ty jsemm už vypustil...
Odpovědět0 0
Když už tak už 400GB = 372,5 GiB!
Odpovědět0 0
