Aranyozott USB kábel esete

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.

Következő jelentkezőnk újabb kínai USB csúcstermék. Kici, occó, USB-soros adapter, ch341-es driverrel. Amelyikkel engem megvert a sors, az speciel rendszeresen leszakadt a portról. Ilyenkor az eszközt használó program megállt mint a féltégla. Miért is ne? Miért is kéne programnak figyelnie, hogy a file amit oly lelkesen ír és olvas az már nem elérhető?
Mivel hibás forrasztásra gyanakodtam, szétszedtem a dongle-t és a elég meredek látvány fogadott. A kábelvégek és az alkatrészek forrasztása olyan volt, amiért egy átlag szakközépiskolából kivágták volna az embert. Az órajelet egy filléres kerámia rezonátor biztosította, olyan tokban, amit valamikor a 90-es években láttam FM vevők szűrőinél. Átforrasztottam az alkatrészeket, de a hiba maradt. Arra gyanakodtam, hogy a hiba oka, a rezonátor frekvenciadriftje. Fogtam és D+ vezetékre kötött felhúzó ellenállást átkötöttem a D--ra. Így lett a full-speed eszközből low-speed eszköz. A leszakadás hiba eltűnt. Ha majd egyszer jobban ráérek kiutálom a valami minőségibb kvarcra.

Végül legyen szó a Broadcom wifi driver támogatottságról. Ugyebár a default kernel driver a b43, ami a BCM4312 chipsettel vicces dolgokat művel. Pl. 2-3 másodperces válaszidőket úgy, hogy a laptop mellé van letéve a router. A hálózati sebesség 30-40kB/s-en megáll. Magyarán, használhatatlan az egész.
És ugye adott a Broadcom gyári wl drivere, ami pöcc-röffre megy.
Kérdés ott áll, hogy miért küzdenek a open-source, kernel developer huszárok ahelyett, hogy dobnák a b43-at és átemelnék a Broadcom gyári driverét? Igen, biztos van benne binary blob és társai, de ne szopassák már ideológiai alapon a usereket.

Hozzászólások

" ne szopassák már ideológiai alapon a usereket."
A userek ideológiai alapon boldogan szopnak, és mikor sikerül valamit beállítaniuk véletlenül egy adott verzión, onnnatól kezdve ők a hatalmas hackerek.

Tanulságos, tetszik, amit írtál.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha nekem ennyi problémám lenne az elektronikai eszközökkel, mint neked, már rég egy barlangban ülnék könyveket olvasva.

Elismerésre méltó, hogy így értesz az elektronikához (én pl. egyáltalán nem), de szerintem több energiád megy el a szopással, mintha kicsit drágábban, de normális cuccokat vennél ;-)

+1.

Bar ha ert az elektronikahoz az ember az hatarozottan nem baj. Par napja egy kategoriajaban high-end usb-uart illeszto"t (gyari FTDI) kellett "javitani" mert sehol sem irta a dokumentacio hogy az usb e's az rs485 ground-ja egy 22R-es ellenallassal van osszekotve. Igy viszont a sajat gyari specifikaciojat (max 250mA) se tudta tartani az eszkoz...

"Miért is ne? Miért is kéne programnak figyelnie, hogy a file amit oly lelkesen ír és olvas az már nem elérhető?"

(/me nem ert hozza)
a kernel nem aze' van tobbek kozt, hogy a program szamara biztositsa a filemuveleteket? Vagy azok kozvetlen tortennek, a kernel kikerulesevel?

Szerintem arra gondolt, hogy ha valami hibakód a visszatérési érték, akkor azt kezelni kellene, nem pedig figyelmen kívül hagyva írni a következő blokkot. A kernel szokta ezeket kezelni, de többet nem tehet, mint elmondja, mi baja van. Alkalmazás rétegig nem nyúlhat, hiszen az az alkalmazáson múlik, mi a teendő. Például dob egy ablakot, hogy baj van kisgazdám, vagy csökkenti a sebességet, esetleg csökkenti a sebességet, és kiírja, hogy vegyél normális USB kábelt.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem, szerintem itt kicsit mas a helyzet. A kernel valoszinuleg jo darabig blokkol a hibazo muveleten, amig az osszes belso timeoutja es retry countja le nem jar. Ilyenkor eleg korulmenyes dolog timeoutot megvalositani userspace programban. Neha meg kill -9-cel sem sikerul kiloni az eppen rendszerhivasba beleragadt processt. Bar az is igaz, hogy nem mostanaban lattam utoljara ilyet Linuxon. Valamint device file-okon szoktak lenni ioctl-ek, amikkel a kernel belso timeoutjait be lehet allitani, igy hiba eseten nem fog az idok vegezeteig blokkolva varni.
---
Régóta vágyok én, az androidok mezonkincsére már!

Ha már itt tartunk, ezért egyszerűbb ott, ahol van exception: nem azzal kell baszakodni, hogy minden egyes függvényhívás visszatérési értékét ellenőrzöm (mert a tapasztalat az, hogy az esetek 90%-ában szarnak rá), ha meg jön egy exception, az valahol úgy is el lesz kapva.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Istenem de rég röhögtem ilyen jót, hogy aranyozott utp kábel...

Bár másodszorra ha jobban végiggondolom, és nem tcp/ip vagy udp megy át rajta akkor még akár létjogosultsága is lehet.

Ez kicsit hasonlít ahhoz, mint amikor valamelyik nagyon hifi magazinban olvastam a ~2MHuf / 1-2 méter hosszú HDMI kábelről. Ott a tesztelő valami panasonic plazmába dugta bele a kábelt és írta, hogy megjöttek a színek, a fekete feketébb lett, a vörös meg vörösebb. Én meg gondoltam, hogy ha már ennyit kiadnék egy ilyenért akkor és is azt látnám :). Jó, hogy azt nem írta le, hogy ennyiért még a mpeg-ben lévő blokkosodást is eltünteti :D

Banyek 2M forintert en rakok a kabel egyik csatlakozojaba egy kis video processzort, ami megcsinalja neki az elenkebb szineket, es az mpeg deblocking-ot. Csak nehogy kalibratorral ramenjen a kepernyore, mert akkor kiderul a csalas. Bar ebben a kulturkorben a muszeres meresnek nem szoktak hinni, ugyhogy mindegy is :)
---
Régóta vágyok én, az androidok mezonkincsére már!

Ezzel az okfejtéssel csak a konzumidióta audiofileket (a félreértések elkerülése végett: nem mindegyik az) eteted azt ugye tudod? :) Igazad van mindenben, csak a iromány elején az audio átvitel kapcsán azt felejtetted el, hogy ezek nem abban hisznek hogy szar kábel esetén nem lesz hang, recseg, jitter és sync problémák lesznek, hanem abban, hogy csúnyábban szól a hegedű, eltűnnek a "színek" az énekhangból, meg ilyenek :) Szóval elolvassák ezt az írást, és azt fogják mondani, hogy "na ugye, mi megmondtuk" :)

Egyébként ha igazán jól akartok mulatni akkor itt érdemes körülnézni:

http://www.audioland.hu/tesztek/csoport-tesztek/214-alap-pc-zene-atvite…