Názory k článku Linuxová záplata na Spectre v2 způsobuje až 50% pokles výkonu

V souvislosti s Meltdown a Spectre bych se bal v takovych clancich mluvit o opravach. Jedna se o potlaceni nasledku. Ke skutecnym opravam na soucasnych CPU nikdy nedojde a je mozne, ze ani na nekterych budoucich.

Taky bych byl spíš po použití pojmu workaround (obezlička).

Takže Kubrick nebol ten kto natočil pristanie na Mesiaci?

Ale bol. Kedze ale Kubric bol perfectionista tak sa natacalo na skutocnych lokaciach na aktualnom Mesiaci.

To predsa vie každý. Rovnako tak aj to že Wernher von Braun s rodinou tam chodili každý rok na dovolenku :)

pretoze dokaze ocenit kvalitu tajnych mesacnych syrovych restauracii

Já myslel že to bylo čerstvě rekonstruované mládežnické křídlo základy z Iron Sky, k natáčení využité v termínu před rekolaudací.

Už rozumiem. Tak preto šíria svoju propagandu aj v linuxových článkoch na roote.

Resenim je proste se na HT vys*at! Bylo to dobry jako takovej "falesnej" a levnej multiprocessing v casech, kde dvou-jadro bylo vrcholem nabidky. Dnes kdyz mam k dispozici i pro desktop levne 6-8 jadrove CPU uz HT nepotrebuju.

Pro vps-hosting to samy. Dnes jsou k dispozici levne >20 jadrove CPU, tak proc se trapit s HT a riskovat ze se objevi naka bambilionta verze spectre? Tohle je skratka slepa vetva vyvoje, a budouci generace CPU by mela byt bez HT. Narust vykonu minimalni, nestoji to za ty problemy...

btw, mam tady v praci 2x Xeon 4114 (20 cores + HT). Testoval sem na reseni velkejch soustav rovnic metodou ktera pekne skaluje s poctem CPU. Meril sem celkovej cas, a 20cores+HT bylo o ~3% rychlejsi, nez kdyz sem pouzil jenom 20cores. Naco tedy HT? Na nic! Pohrbit tuhle vec, a jede se dal...

Ta tak. Kdyby vykopli HT a flákající se jednotky použili místo branch prediktoru tak, že se pojedou do rozhodnutí obě větve v rámci dvou pipelines. Pak výkon nezávisí na skoku (volí se jeden nebo druhý zpracovaný výsledek) a vnější pozorovatel vidí načtení cache za podmínkou ať je splněná, nebo ne. A nikdo cizí paralelně s taskem nesdílí stavový informace. A kernel při výměně threadu prostě musí uklidit tak jako tak.

Ale pokud se bude spekulovat nad víc než jedním větvením (1. větvení = 2 větve; 2. větvení = 4 větve atd. geometrická řada), tak by se podvětvení stále daly IMO nějak natrénovat.

Větvení je problém kvůli pipeline, že se musí zahazovat co už je hotovo. Pokud je pipeline s 10 řezy, zpracovává 10 (mikro) instrukcí. Když se skok vyhodnotí jinak, těch 10 rozpracovaných instrukcí se zahodí. Branch prediktor se snaží tohle zahazování omezit.
Pokud za skokem další skok následuje po >= 10 instrukcích, vystačíš si s dvěma "pipelinama" pro zpracování, protože při další podmínce je už předchozí slepá větev zahozena.
Při < 10 instrukcích by se holt muselo v té větvi interně vložit pár NOPů, ale furt lepší tři NOPy, než zahozených 10 instrukcí.
Průšvih by to byl akorát v případě cyklu s <10 instrukcema, tam by se musel proložit NOPama a výkon by šel trochu dolů. Tam BP dává lepší výsledky.

Jo to by šlo. Co jiná vlastnost a to že pokud by dneska branch prediktor předpověděl dobře a zároveň pouze ve špatné (= nepředvídané a nepředpočítávané) větvi by bylo plnění cache, tak se ušetří tak stovky taktů kdy by se při špatné předpovědi muselo čekat na RAM?

Nesmysl. To je totéž jako tvrdit, že stejně nesmíš v ČR jezdit víc než 130, tak se všem autům vyndá z jednoho hrnce píst, aby to nikoho ani nenapadlo. Hardware prostě umožňuje efektivnější využití hardwaru a tím zvýšení výkonu výměnou za snížení bezpečnosti, takže ať si každý zvolí co mu s ohledem na jeho potřeby vyhovuje. Samozřejmě je lepší informovaný souhlas a jako výchozí bezpečnější nastavení, ale je kokotina to zatrhnout natvrdo jen proto, že jseš paranoidní a nechceš, aby v NSA viděli jak ti jdou miny a na jaký porno koukáš.

Sice fajn myšlenka, ale problém je, že tady to přepnout prostě nejde.

Prodali ti bezpečnostní dveře, který sice odolají střelbě ze samopalu, ale nemají kvůli rychlejšímu otevírání zámek (hledání klíčů a strkání do dírky přece zdržuje) a ten se ani nedá doinstalovat. Tak se na ně montují petlice a když chceš zamknout zevnitř, musíš napřed ven oknem, odemknout a vrátit se oknem dovnitř. Což je mnohem pomalejší, než kdyby tam ten zámek dli rovnou.

A momentálně vývojáři přemýšlí, jak udělat do dveří díru, skrz kterou bys dosáhl na zámek u té petlice, aniž by utrpěla neprůstřelnost.

Jenomže oni to tak udělali proto, že to zákazníci chtěli, a pořádný dveře odmítali kupovat. Fakt pochybuju, že by IT a následně prakticky všechno bylo tam kde to teď je bez toho, že by posledních 20 let byly k dispozici dostupný procesory. Myslíš, že by v každý rodině byla SPARCstation a každej člen rodiny by měl v kapse SPARCphone, a jupíci by si před roštěnkama ve školní jídelně šudlali iSPARCmini?
Bylo by to na úrovni katolickýho školství v době Jiráskova Temna.

Súhlasím, HT je overrated. Skúšali sme paralelný fingerprint matching na 12 cores+ht a pri paralelizme 12 prestal výkon stúpať. HT som vypol na svojich všetkých masinach.

To by me taky zajimalo, jestli testoval nekdo ten patch i na nativnim non-ht cpu? Jestli se desit toho co jadro 4.20 prinese nebo byt v klidu:)

Nebude to náhodou záležet na architektuře konkrétního CPU? V hlavě to nenosím, ale pokud by cache byly mezi fyzickými jádry sdílené, tak si dovedu představit, že by některé varianty útoků mohly fungovat i bez HT.

2MasoxCZ: A samozrejme taky fungujou, protoze v CPU se sdili prakticky vse. V dalsim kroku se totiz bude resit, ze vsechny CPU pristupujou do stejny RAM. A kupodivu, si tam kazdej jeden muze precist a zapsat co chce a kam chce. A pak se s prekvapenim zjisti, ze to vsechno pouziva jeden disk, o kterym plati totez.

Hyperthreading nie je urceny pre ulohy, ktore jednostranne vytazuju len urcity typ vypoctovyvh jednotiek v CPU ako je riesenie rovnic (FPU jednotky). HT vylepsuje celkovy vykon systemu, kde bezi mix rozlicnych uloh, ktore rovnomerne vyzivalju rozlicne typy jednotiek (FPU, integer, load/store...), vtedy sa da dosiahnut navysenie vykonu o 30-50%.
Je samorejme, ze "skutocne" jadro je ovela lepsie ako to z HT a suhlasim s tym, ze v pripade dostupnosti viacjadrovych procesorov straca HT postupne zmysel. Napriklad POWER8 procesor podporuje SMT8 (to je IBM nazov pre HT - Symetric Multithreading s 8 threadmi na core) ale da sa to v systeme (v AIXe) za chodu menit na SMT4, SMT2 alebo sa da HT uplne vypnut a administrator tak moze odladit vykon systemu podla uloh ktore tam bezia.
POWER9 sa uz dodava v dvoch verziach alebo s SMT8 alebo s maximalne podporovanym SMT4, ktory ma ale na cipe 2x viac jadier ako verzia s SMT8.

Tak mi rekni, jak dokaze beznej uzivatel vytizit cpu s 10 cores + HT? Samotne efektivni vyuziti 10 jader neni tak jednoduche, to musi byt aplikace specielne napsana a nekdy to ani nejde.

Tak naco ma byti na cpu s 10 cores jeste HT? Ja bych bral radsi 12cores bez HT za stejnou cenu (coz by snad plochou cipu mohlo byti +/- na stejno)...

dvě slova: Windows Update.

Běžný uživatel nevytíží ani deset jader. Chyba byla, že si vůbec takový procesor koupil. Zda to má nebo nemá HT na té chybě nic nezmění.

Tolik jader a ještě s HT si bude pořizovat někdo, kdo provozuje třebas virtuálky nebo webový server, který v jednu chvíli obsluhuje desítky požadavků. Prostě na něco, co samo o sobě obnáší desítky vláken, každé dělající něco jiného nebo v jinou chvíli.

Na paralelní výpočty je lepší maximalizovat počet jader * frekvence. HT pomůže jen v hodně specifických paralelních úlohách, které vyžadují jednotky, které jsou skutečně zdvojené (příkladem budiž zpracování textu). Jenže většina zátěže půjde po věcech jako jsou FPU a tam na sebe ta vlákna budou čekat, protože FPU je pomalejší než jedno vlákno. A obvykle jich tam není tolik, aby to upočítalo vlákna dvě.

Takvej beznej user si pusti trebas ... hru ... a takova hra mi naprosto klidne (netvrdim ze efektivne) sezere i 16 jader na 80+% ... a takovej benzej BFU ma 4/6/8 jader i ve svym patlafounu.

Pri konverzii videa dokazem bez problemov vytazit 8 jadier na Ryzen 7. Verim tomu, ze by sa dalo vytazit aj 10 alebo viac jadier.
HT ma ale zmysel hlavne na servroch, kde bezia rozlicne typy uloh, kde ale zase kvoli bezpecnosti HT nie je vhodny :-)

A jakej rozdil v rychlosti konverze je, kdyz pouzivas HT, a kdyz HT zablokujes (i kdyz HT na AMD neni to same co HT na Intelu)? Kazdopadne ja osobne bych bral radsi 9 plnohodnotnejch jader, nez 8+HT...

Dobre napsana rekomprimace videa? Ta by mela umet vytizit libovolny pocet jader (proste tim, ze video rozseka na vic casti). A stejne tak i dalsi ulohy, ktere se daji rozsekat na vice casti.

Wow, sběrač kovu, já už jsem fyzický server neviděl ani nepamatuju :-)

Ja taky ne. Tohle je muj pracovni desktop! :-)

Vypnuti HT je ostatne take prvni vec, kterou na Intel based pocitacich delam.

No kdo by to byl řekl, že pokud sdílím funkcionalitu s ukládáním stavu, sdílím i ten stav...

Pokud už něco sdílet (bez ohledu na to, jestli HW nebo SW) , tak samostatnou instanci, nebo bezstavovovu variantu, která nic nikam neukládá. Za předpokladu, že nechci sdílet ty data.

Můžu sdílet třeba shifter, data protečou v jednom taktu a jsou fuč. Můžu sdílet ALU, data protečou a jsou pryč. Ale koho sakra napadlo sdílet branch prediktor (který se učí = pamatuje si předchozí stavy) a cache???

I při psaní programu v blbým Cčku, pokud mám několik vláken, musím přece přemýšlet, jestli ta vnitřní stavová proměnná ve funkci má být statická, nebo jí to dávat zvenčí argumentem. První možnost je rychlá, druhá bezpečná.

Koho napadlo sdílet cache nevím, ale pokud bylo cílem maximalizovat výkon multithreadové aplikace, která něco počítá, tedy vlákna přistupujou ke stejným datům a provadí stejný kód, pak je ta volba celkem logická!
Blbé je samozřejmě tohle všechno, když na procesoru mohou běžet nepřátelské procesy, které využijou každé slabiny, aby se dostali k informacím, ke kterým normálně nemůžou.

Těžko říct, zda tohle dřív nikoho nenapadlo nebo to ignorovali, ale předpokládám, že spekulativní provádění, cache a další principy vznikaly v době, kdy se na bezpečnost hledělo dost jinak. Vůbec bych se nedivil, kdyby před lety vývojáři dostali zadání, že klíčový jen výsledný výkon (skóre v benchmarcích) a teoretickými blbostmi, které "nikdy" nenastanou, se nemají zdržovat... nějaké roky vše hezky fungovalo, začalo se to používat všude... hups a najednou je všechno špatně. :-)

"Koho napadlo sdílet cache nevím, ale pokud bylo cílem maximalizovat výkon multithreadové aplikace, která něco počítá, tedy vlákna přistupujou ke stejným datům a provadí stejný kód, pak je ta volba celkem logická!"

Není. Nastuduj si "Race Condition"! Nemůžeš pustit dvě vlákna na stejný data, pokud minimálně jedno z nich zapisuje. A pokud se data liší, liší se automaticky i obsah D-cache, registrů,... Shoda branch prediktoru je i v tomhle případě spíš sakra velká náhoda, protože skoky vyhodnocují obecně nějaký různý data. A to i v případě, že nějakou náhodou je shodná I-cache.

Nemyslím, že by mělo cenu hádat se o drobnosti, určitě existujou situace, kde to výhodnější bude. Třeba tím, že se data a kód načtou z RAM, když je potřebuje první vlákno, druhému mohou aspoň z části přijít vhod.
Pochopitelně vlákna nemusí hrabat přímo na stejný byte, aby cache byla přínosem, navíc spousta dat se opravdu jen čte, o těch skocích by se taky dalo diskutovat... ono je to jedno, prostě se na začátku tohle řešení mohlo jevit tak, že v určitých situacích bude výhodnější a ničemu neškodí... zatímco teď už víme, že škodí velmi. :-)

Může, většinou na umělé zátěži v benchmarku.

V praxi stačí splnit jenom několik "triviálních" podmínek:
1) Musí to být dvě vlákna v rámci jednoho procesu. Jiný proces = jinak mapovaná "velká RAM" = CPU neví, že je tam to samý.
2) Vzhledem k velikosti I cache musí být vlákna hodně přesně synchronizována.
3) Nesmí do toho kecat kernel a přehazovat vlákna, zastavovat je,...
4) Musí se jednat o zpracování (= kompletní řetězec read - modify - write). Vstupní operace, výstupní operace a přesuny přes CPU jsou výkonový nesmysl, to si řídí DMA efektivněj.

Takže v praxi - překódování videa (na GPU je na to víc jader a HW akcelerace), počítání dlouhé řady hashů (věc, kterou na HT opravdu nechceš dělat kvůli bezpečnosti) a podobný opičárny.

"Vůbec bych se nedivil, kdyby před lety vývojáři dostali zadání, že klíčový jen výsledný výkon (skóre v benchmarcích) a teoretickými blbostmi, které "nikdy" nenastanou, se nemají zdržovat... "

A já myslel, že varianta "obchodní rozhodnutí maximalizovat výkon a minimalizovat cenu" výměnou za tehdy pouze spekulativní snížení bezpečnosti bylo jako správná hypotéza dávno potvrzeno.

tak muzes pouzit treba 2.4 jadro... ;)

Ať dělám co dělám tak Windows jede stále rychle, bezpečně a stabilně. Momentálně tedy opět rychleji než na tom samém železe s Linuxem. Jen se za to platí a má to použitelný desktop.

a Docker tam uz funguje normalne? :-P

Nevím, nepoužívám podobné frikulínské nesmysly.

data porad jeste mas nebo uz ti je smazali?

Svá data nikomu nedávám, takže děkuji za optání, ale nikdo mi je nesmazal.

Pravdu neumlčíš, i když bolí.

... a trolla taky

"Netroluj. Nudně."

Kdyby Linuxaci takhle rychle, jasne a vtipne reagovali i na politicky troly v diskusich pod clankama, tak by to bylo fajn. U toho by ale museli vic premejslet, plivat na windows je prece tak snadne....

@Unknown

Nejvtipnější na tom je to, že pod těmi články často často politicky trolíš taky ...

"Nejvtipnější na tom je to, že pod těmi články často často politicky trolíš taky"

Ja se snazim dodrzovat zasady konstruktivni diskuse. Prosim o pripadne ukazky meho troleni v politickych tematech.

rychle, bezpecne, stabilne v jedny vete s Windows? :D

Chápu že tohle spojení je pro linuxáře sci-fi, ale my to tak prostě máme.

A běhají tam i jednorožci?

Widle jsou jako ženská. Ideál je hezká a chytrá panna, ale buďto je ošklivá, nebo blbá, nebo už není panna.

Widle jedou rychle a stabilně, pokud vypneš update. Pak ale nejedou bezpečně, protože mají děr víc jak cedník na těstoviny a ty je nezalepuješ.
Widle jedou bezpečně a rychle, když zapneš automatický update. Pak ale nejsou moc stabilní, přijdeš z oběda a nejenom že systém ukončil programy, ale máš i jinou verzi Widlí a s jiným nastavením.
Widle jedou bezpečně a stabilně, pokud děláš ruční update a ruční nastavování všeho, co ti rozdrbou. Pak je ti rychlost houby platná, protože na hodinu práce potřebuješ tři hodiny tunění...

Ale houby su rychlejsie. Nechce sa mi googlit ale existuje nejaky test kde zistili ze prakticky kazda operacia jadra sa na windows robi niekolko nasobnym mnozstvom instrukcii nez na linux-e. Od spustenia noveho procesu, az po otvorenie suboru a kontroly privilegii. Takze nech robis co robis, na rovnakom zeleze to rychlejsie behat ani nemoze.
Nezabudajme pri tom na to ze mnohe optimalizacie ktore su Linux-e na windows ani neexistuju, filesystemy, memory, threading, ... . Preco asi vsetky superpocitace uz bezia vyhradne na Linuxe (teda myslim okolo 99%) a na samotnom Azure od microsoftu je uz viac ako 50% virtualov Linuxovych. Iste preto ze windows je rychlejsie :-D.

Což ovšem pro BWU není argument. Já ale oceňuju, že mláděti stačí na pohádky 12 let starý Celeron bez HT, kde i W7Home původně startovaly 10 minut...

Navíc těch 10 minut nebylo vinou toho celeru.

Pokial ide o superpocitace v top500 je to uz 100% linux. Tolko k vykonnym windwsom. :-)

K vykonu asi toliko, ze pokud si pamatuju Londynska burza by mohla vypravet ...

A potom si tam musis dat antivir ktory ti to spomali 3nasobne.

Divný, na routeru mě windows nejede, ale v linuxu jsem tam rozběhal i libreofficy :-P

Nemozes predsa porovnavat ozajstny operacny system urceny na beh roznych serverov potrebnych pre beh sveta s nejakym game launcherom pouzivanym prevazne v kancelarii a na xboxe... Vo windowse sa predsa nebudu hrat na security. Alebo sa bojis o svoje savy z hier?

Přesně. Za úspěchem Windows nestojí jejich dokonalost, nýbrž jejich faktická dostupnost za akceptovatelnou cenu a kvalita DOSTAČUJÍCÍ pro požadovaný účel. Nic víc, ale taky nic míň. Anglicky se to řekne "good-enough". A sice to nikdy nikdo nepřizná, ale troufnu si tvrdit že to je jeden z faktických důvodů, proč v EULA Microsoft (ale nejen oni) prohlašují, že neručí za vhodnost ke konkrétnímu účelu. BTW tohle prohlášení je už léta zcela standardní součástí provozní dokumentace prakticky všech západních výrobků a produktů.

Pro drtivou většinu lidí je linux, ač z hlediska principů bezpečnosti lepší, zbytečnej overkill; asi jako kdyby sis kvůli měsíčním nákupům kupoval nákladní vlak nebo kontejnerovou loď.

Přiznám se, že úplně nechápu toho červeňáka. Že linuxové systémy mají (až na naprosté výjimky) distribuční model neslučující se s pozicí mainstreamového desktopového systému, je prostě fakt. Můžete s tím nesouhlasit, můžete si proti tomu protestovat, můžete o tom i diskutovat, ale to je v podstatě všechno, co s tím můžete dělat. Přitom pro drtivou většinu uživatelů není důležitá konkrétní platforma; zajímá je to, aby došli do krámu a řekli / naklikali na eshopu, že chtějí dělat kancelářskou práci, chtějí tisknout / skenovat / hrát xy, a pustit si občas film, a nechtějí kvůli tomu nic studovat, stahovat, stavět, nebo se nedejbože dokonce učit něco, co budou potřebovat jednou při instalaci. Chtějí, aby to bylo pochopitelné a použitelné na první dobrou, a linux jim nenabízí žádnou game-changing výhodu, která by ospravedlnila úsilí navíc, které by na jeho získání museli proti Windows vynaložit. PROTO se proti Windows prosadil iOS a Android, a proto se na školních strojích slušně prosazuje ChromeOS, i když zatím hraje druhé až čtvrté (podle regionu) housle. Linux se na desktopu prosadil v podstatě výhradně na vysokých školách TECHNICKÝCH směrů a ve firmách, kde jej potřebují. Všude jinde jsou to Windows a na uměleckých směrech má významný podíl MacOS.

Tvůj názor ale stojí na předpokladech, že
1) Na widlích nemusí nic vědět a studovat. Jenomže v okamžiku, kdy si připojí mobil, foťák, tiskárnu,.... to začne řvát něco o ovladačích a už musí studovat, co ta hláška "Driver not found" znamená, jak to vyřešit, kde ten ovladač roste,...
2) Že widle fungují bez toho, aby musel uživatel něco řešit. Toto ale neplatí, furt řeší nějaký problémy s updatem, s padáním, se změnama UI pod rukama,...
3) Pokud uživatel dostane dražší a horší řešení, upřednostní je. Proč by to ale dělal, pokud před ním někdo to levnější a lepší řešení nezatají?
4) Že jsou widle použitelný "na první dobrou" po vybalení z krabice. Sorry, ale tam je tolik sr*ček od výrobce, že jediná možnost je sehnat si instalačku widlí a před prvním použitím se vrhnout na disk, smazat včetně systémové partition a čistá instalace. Setnat instalačku Linuxu je o stažení image, sehnat instalačku widlí znamená warez fórum, kontrolu antivirem (nebo raděj třema různýma) a řešit licenci a nějaký registrace u Mrkvošrotu.

Přešel jsem na laptopech a desktopu na OpenBSD. Ten má defaultně HT vypnutý. Měl jsem trochu obavy z výkonu, ale zatím nic nepozoruji.
Jednoduché, smysluplné a bezpečné defaulty. Vše funguje jak má, žádné Lennartovy nesmysly...

Na serverech (soukromých) totéž, OpenBSD vyjma NASu, tam je FreeBSD.

Ja som radsej zostal na Linux-e iba som si ten HT vypol v BIOSe. Jednoduché, smysluplné a bezpečné.

Ta já jsem nepřešel na OpenBSD jen kvůli HT. Důvodů bylo víc... a zatím fakt nelituju...

No ale v tom bola moja narazka ktoru si asi nepochopil. Koli tomu aby si si vypol HT nemusis prechadzat na ziadny iny system. Proste vypnes v BIOSe.

Ne na každé desce to jde. Pak se OS s možností volby hodí.

To je ale blabol

"Společnost Intel radí uživatelům většiny operačních systémů, aby v BIOSu počítače vypnuli podporu technologie HyperThreading u procesorů, které tuto technologii nabízejí."

sprava z 10. září 2004

uz tehdy se to nedoporucovalo pouzivat ... tak na co si to ti lidi stezuji? :-D

ale pro takovou 'hloupost' snizovat vykon procesoru?
(/ironie)

posledni dobou je to opravdu pruser kolem problemu s procesory - soft se jeste jaktz-takz da ohakovat, ale hw?

Nech byt, už jsem řešil i problémy s dotykovým displejem při ESD výbojích pomocí SW. HW řešení a dva měsíce laborování nepomohly. Tak to hodili po mě. Nakonec jsem se naštval, přidal dva řádky do ovladače po Indech a najednou to nemělo problém... :D Jenom chvilku trvalo přijít na to, co ti zmetci pohnojili.

to chces rict, ze indove neco pohnojili?!
tomu neverim ... vzdyt s nima spolupracuji den co den! jsou to naslovovzati odbornici - dokazou slibit vsechno! :-D

BTW: jsem zvedav, kdy a kdo prvne vyda knizku: Moje zazitky s indickym IT
podle mne to bude ta nejprodavanejsi knizka, jaka kdy uzrela svetlo sveta, protoze to bude komedie, drama, sci-fi, detektivka ... a vsechno v jednom ;)

2kantor: Na to nemas dost papiru nebo bajtu na disku.

Jo, hnojí furt něco... Teda nevím jak IT, ale vývoj v Indii je jedna velká kontinuální katastrofa.

V tomto konkrétním případě implementovali SPI tak, že hodili při initu SS do nuly a už na to nesahali. Při ESD výboji do touchscreenu komunikace o bit poskočila a už se to nechytlo. Takže to testovali a pokud se jim výsledek nezdál, vypli a zapli napájení touchscreenu. samozřejmě tam někdo musel udělat ovládání toho napájení a další revizi desky.

Jenom tím, že jsem SS hodil do nuly před komunikací a do 1 po komunikaci, odpadla celá ta opičárna s testováním, protože komunikace se prostě restartovala bez řadiče. Daly se odpárat součástky kolem pro vypínání napájení touchscreeny a i pár transilů se ukázalo, že jsou tam už jenom na ozdobu. Takže o $3,5/kus levnější...

Řešit HW problémy v software?
To mi něco připomíná... když bylo potřeba, aby ten krám prošel EMC zkouškami, nařídili nám nezobrazovat žádný chyby, srazit frekvence všeho na minimum, upravit kernel a klíčové drivery tak, že by autoři plakali, do zblbnutí resetovat USB hub, všechna spojení neustále znovu navazovat... a zacvičit obsluhu, aby přesně věděla, co kdy může mačkat...
Ale podařilo se, zkušebna na nic nepřišla a zkouškama to prošlo... :-D

To zní jako něco od Hitchcocka ... :-O

Nebudu jmenovat firmu nebo výrobek, ale prý naši obchodníci slíbili zákazníkovi papír, aniž by se zajímali o to, zda je to vůbec možné. Nevím už rozsah frekvencí, ale výrobek měl fungovat v poli 20KV/m. Zkoušelo se to velikou anténou z metru. Když jsme to zapli poprvé, během čtvrt hodiny nám nařidili to vypnout, protože v okolních kancelářích popadali všechny PCčka a síťaři nechápali co se děje... :-D