Pár hete ment ismerősökkel a viccelődés az aranyozott audiofil ethernet kábelen. Aki látta már a TCP/IP belső világát, annak a sebességét, és rendelkezik némi alapszintű matematikai képességekkel, az beláthatja, hogy egy dedikált két pont közötti, zenehallgatásra kihegyezett streaming hálózatnál, elég sanszos, hogy a forrás és a DAC között pont a kábel miatt legyen a szűk keresztmetszet. Hiszen, mit is okozhat egy kábel, egy ilyen robusztusan, megtervezett és felépített hálózat adatforgalmában? Vagy esetleg más, kimondottan két, külső eszköz összekötésére szolgáló szabvány esetében?
Nos, elég sokat, különösen ha az adott szabványt marketingesek és nem mérnökök tervezik. Igen az USB-ről van szó. Anno, vegyes érzelmekkel figyeltem a megjelenését, aztán az évek során mindig sikerül újabb és újabb kellemetlen meglepetésekkel szolgálni.
Ugye, az alapelképzelés egy univerzális, csavart érpáron menő, half-duplex, soros kommunikáció volt, ami képes egymástól távolabb lévő eszközöket is összekötni. Az elképzelés jó volt, csak épp egy dologra nem számítottak, hogy bizony, ha egy adat dróton megy messzebbre, az bizony sérülhet. Ezek ellen vannak bevált hardveres és szoftveres védekezési módszerek, mint a jelszintek emelése, az érpáron folyó áram növelése, hibatűrő és hibajavítást segítő elkódolások és a többi, és a többi, csakhogy ezek mind valami kompromisszumot, vagy épp kiadási költséget jelentettek volna. Maradt tehát a mismásolás és a "wishfull thinking".
Ha már a kábelezéseknél tartunk, akkor érdemes megjegyezni, hogy a csavart érpár esetében legtöbbször impedanciát szoktak megadni, amit három tényező befolyásol a vezeték ellenállása, az érpárok közötti kapacitás és az induktivitásuk. Normális kábelgyártók esetében ezen értékek, külön, külön is fel vannak tüntetve. USB specifikációban az impedancia értékekre nem túl szoros specifikáció vonatkozik, differenciális impedancia az adatvezetékek közt 90 Ohm ami 76,5 és 103,5 között lehet, a közös módusban 30 Ohm, ami 21 és 39,5 Ohm között lehet. Viszont szabadon lévő kábelvégeknél a kapacitás értékre 2 pF van megadva.
És ekkor lének be a képbe a kínai kábelgyártók, akik praktikus okokból (csak anyag ne legyen benne) a legolcsóbb alapanyagból ontják a USB2.0-ás kábeleket. Ezen tényezők szerencsés találkozásakor áll elő az a helyzet, hogy az ember vesz egy 1 méteres toldókábelt, amit összedug a scanner 80 cm-es kábelével és scannelni próbál. Hol lehet itt a hiba, hiszen az USB specifikáció 5 méteres maximális hosszt enged?
A kvázi FOSS fejlesztési példaként beállítható, magas minőségű, SANE backend felismeri a scannert, az ember elindítja a scannelést, és csak vár és csak vár, hosszú malmozás után megszületik az előkép, majd mindenestül szénné fagy a front-end (xsane, xscanimage tök mindegy). Frontend újraindítás után, I/O eszköz nem elérhető, a dmesg üres. Scanner újraindítása után, újból megjelenik az eszköz, újból elindul a scannelés, aztán megint beáll az egész.
XP alatt a scanner működik, darálja a biteket. Break-out kábellel a jelre ránézve, kiderül a turpisság, az XP csak full-speeden járatja a buszt.
Nem maradt más hátra, mint a hosszabbító kábelt kitépni a rendszerből és végigmérni. Ellenállások stimmelnek, impedancia stimmel, csakhogy a kapacitása 158pF. Egen, egyes áramkörökben tápszűrésre használok ekkora értékeket. Kábel kuka, hulladékosból keresek egy megfelelő kiskapacitású, 4 eres, csavart érpár kábelt, forrasztás, összedug, örül. Sane megy, XP megy csak épp már Hi-Speed módban.
Tanulság? Az oly megvetett Microsoftos gyerekek, megint tudtak valamit mutatni. Mondjuk olyan nüansznyi dolgot, hogyha sok a hulladék a kommunikációban (retry packet hegyek), akkor megpróbálkoznak kissé lassabban kommunikálni.
