Potentielles Speedup f. L4M132C (und andere usb2.0 full speed devices) -> bitte um Erfahrungswerte

    im zuge des debuggings eines neuen displaymodules sind wir (ich und digital devices) auf ein komisches verhalten von linux gestossen, welches mir in dieser tragweite bis jetzt wohl nicht aufgefallen ist:


    wird ein usb 2.0 full speed device (und darunter faellt auch das l4m132 (und auch das l4me5i)) direkt ohne hub angeschlossen, wird es via uhci bzw ohci angesteuert (log eintrag: 'new full speed USB device using ohci_hcd').
    wird dasselbe device via usb2.0-hub angeschlossen, wird es ploetzlich korrekt via ehci angesteuert (log eintrag: 'new high speed USB device using ehci_hcd' bzw 'new full speed USB device using ehci_hcd').


    (das 'high speed' duerfte eine falsche ausgabe sein, da es sich auch lt. datasheet um ein full speed device handelt).


    das interessante kommt aber jetzt:
    wenn das l4m132c ueber einen hub angeschlossen wird, ist es um einiges schneller als wenn es direkt angeschlossen ist.


    beim testpattern 'p 6' von testserdisp bei mir: 13 sec (via hub) vs. 30 sec (direkt angeschlossen).


    das einbinden mit ohci/uhci vs. ehci erfolgt direkt von linux. ueber libusb habe ich keine (mir bekannte) moeglichkeit, dies zu umgehen.auch waere mir nichts bekannt, dies irgendwie direkt unter linux umgehen zu koennen (via konfiguration, udev-rules, ...).


    interessant waere jetzt, wie hier die erfahrungswerte anderer displaybesitzer sind (interessant sind: wie ist das display angehaengt (mit/ohne hub), wie wird es von linux erkannt (logeintrag 'new [full|high] speed device using [ohci|uhci|ehci]_hcd'), wie unterscheidet sich die performance (performancemessung mit testserdisp und pattern 'p 6', vor abruf des patterns 'ts=1' eingeben, da wird dann eine zeitmessung durchgefuehrt und ausgegeben).


    falls jemandem diese problematik bekannt ist (unter windows gibt es diese anscheinend nicht - hier werden die devices mit und ohne hub gleich schnell angesteuert): mir bitte mitteilen / links auf infomaterial / ...


    /wastl

    wastl


    Interessanter Gedanke, wenn ich einen USB Hub zum Test habe werde ich Deiner Bitte folgen leisten. Mein "l4m132" wird auch per "ohci_hcd" erkannt und als USB 1.1 Full Speed Device betrieben.


    Das Problem wird aber sein, das "ohci_hcd" dummerweise bei den Standard-Kernel immer von "ehci_hcd" geladen wird, sei es als Modul, sei es fest im Kernel einkompiliert, z.B. Ubuntu. Leider läßt das Display diesen alternativen USB 1.1 Betrieb zu, während der USB 2.0 Hub "ehci_hcd" vorgibt.


    Wenn "ohci_hcd" und "ehci_hcd" als Module vorliegen würden, könnte man das was steuern. Das Problem beschäftigt auch anderen mir anderen Geräten, siehe z.B. hier.


    Gruß
    Frank

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

    fnu
    weiss nicht, ob das problem vergleichbar ist. es ist ja kein problem mit der reihenfolge, wie module geladen werden oder nicht.
    sondern, dass es abhaengig zu sein scheint, ob das device via hub oder direkt betrieben wird.


    und zwar egal, ob bei kernel mit modul-support (bei meinem fc5 mit aelterem vanilla-kernel) oder direkt hineinkompiliert (fedora 12). bzw. im embedded bereich (ist mir gemeldet wordn - weiss aber nicht, welche distro da verwendet wird).


    darum eben die bitte, das auch auf anderen systemen nachzustellen. vielleicht weiss da ja wer eine generelle abhilfe/loesung/workaround.


    /wastl

    wastl


    Wie gesagt werde ich tun, sobald ich einen USB Hub zum Testen habe ;)


    IMHO hat das wohl etwas mit der Lade-Reihenfolge der Module zu tun. Ich hatte ein ähnliches Problem vor Jahren mit einem WLAN USB Stick. Der vorgeschaltete Hub erzwingt quasi die primäre Nutzung von "ehci_hcd" ...


    Wenn Du ein System hast, bei welchem die ohci_hcd etc. als Module vorliegen, warum blacklist'st Du nicht zum Test mal "ohci_hcd"? Du hast nix zu verlieren dabei, oder?


    Gruß
    Frank

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    wie ichs mir gedacht habe:
    sobald ich uhci_hcd auf die blacklist setze, funktioniert weder das sdc-megtron, welches auch gerade am VDR haengt, noch das digital devices modul - kein mucks im /var/log/messages. (werden beide, wenn nicht an einem hub haengen, via uhci eingehaengt. ohci_hcd blacklisten ist egal, da es sowieso nicht verwendet wird (obwohl (altes) intel-board ....).
    wenn ich dann uhci_hcd wieder zulasse: alles wie gehabt.


    /wastl

    wastl


    Ich werde das mit den Modulen bei mir mal testen, wenn ich Zeit habe einen anderen Kernel zu bauen ...


    Aber hier für Dich die Ergebnisse, mein Sohn mußt mal kurz [s|m]einen USB Hub zur Verfügung stellen ;)


    Das Mainboard ist das MSI 760GTM-P33 mit AMD 760G Chipsatz & AMD 710 Southbridge.


    Und was sagt uns das jetzt? DEPTH=1 ist nicht mehr nötig, wenn wir einen kleinen Hub in den VDR bauen?


    Gruß
    Frank

    HowTo: APT pinning

    3 Mal editiert, zuletzt von fnu ()

    Zitat

    Und was sagt uns das jetzt? DEPTH=1 ist nicht mehr nötig, wenn wir einen kleinen Hub in den VDR bauen?


    so sieht's aus. ich weiss zumindest zur zeit keine bessere loesung, wenn jmd. eine schnellere darstellung benoetigt. darum ja auch dieser thread: vielleicht kennt jmd. eine 'saubere' abhilfe.


    aber depth=1 kann man ja trotzdem lassen, solange graphlcd nur monochrom kann. aber an einer version mit farbunterstuetzung wird ja gerade gearbeitet, da waere dann wieder eine schnellere ansteuerung durchaus wuenschenswert :)


    /wastl

    wastl


    Im praktischen Betrieb kann ich die Beschleunigung auch bestätigen, mit 0.1.6 & 1.98.x, siehe anderer Thread.


    Die Display-Aktualisierung ist immer noch "sichtbar", erfolgt aber richtig schnell. Die Information wird in etwa innerhalb der VDPAU Umschaltzeit aktualisiert, ohne "DEPTH=1"!


    Was aber bei mir einen starken Eindruck hinterlassen hat, ist, das ich meine die Fernbedienung reagiert viel besser, toleranter (Zielverhalten) und fast keinen "Fehltasten" mehr, kann das sein?


    So'n kleiner Hub kostet € 10,-, frisst kein Brot und ist eigentlich aufgrund seiner Größe leicht unterzubekommen. Das größte Problem wird sein, das die meisten die nötigen Kabel nicht haben ...


    Gruß
    Frank

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

    Hi,


    habs auch mal getestet, mit Direktanschluss am Board des Asus M3N78-EM

    Code
    testserdisp -n l4m132c -p /dev/usb/hiddev9 -o RESMODE=0


enter 'help' to get help


> ts=1
time needed:  0s 000ms 003us
> p 6
time needed: 37s 789ms 124us  write() calls:     442446   avg. time per write: 85.410us


    Laaangsam. Mit USB Hib teste ich erst später, zum einem, weil ich nur wenige habe, zum anderen, muss ich erst ein Kabel basteln...


    MFG
    KRis

    Intel DN2800MT 4GB RAM; 32GB mSata, Ubuntu 15.04, TVHeadend 4.1, Digibit R1 SatIP

    HI,


    so, nachdem mir heute eingefallen ist, das in meinem flachem htpc Gehäuse auch ein USB-CardReader mit USB2 Hub werkelt, habe ich einen USBHeader ab- und anstelle dessen, eine Pinleiste dran gelötet.



    Das ist doch ein Unterschied!


    Ich würde sagen, wastl hat ins schwarze getroffen. Nun kann ich mich doch noch an graphlcd ranwagen ;)


    MFG
    KRis

    Intel DN2800MT 4GB RAM; 32GB mSata, Ubuntu 15.04, TVHeadend 4.1, Digibit R1 SatIP

    Einmal editiert, zuletzt von kris ()

    kris


    In der Tat und wie ist Dein subjektiver Eindruck im Betrieb des Displays? Du hast nicht zufällig die Fernbedienung ausprobiert?


    Hmm, ob es nicht wohl doch eine Lösung gibt ein Device in den ehci-Betrieb zu zwingen ...


    Gruß
    Frank

    HowTo: APT pinning

    HI,


    bei Infrarot merke ich keinerlei unterschied, ist genauso gut/schlecht wie bisher (in Verbindung mit einer Logitech Harmony)


    Ich Nutze das Display seit längerer Zeit als Uhr, da ich ein TFT dranhabe. Ich wollte bei Gelegenheit mittels Graphlcd eine minimalistische Anzeige basteln, aber ich habe eigentlich keine Zeit (hab noch einige Bücher die Gelesen werden müssen ;) )


    MfG
    Kris

    Intel DN2800MT 4GB RAM; 32GB mSata, Ubuntu 15.04, TVHeadend 4.1, Digibit R1 SatIP

    hallo,
    bevor jetzt die leute zum zerschneiden von hubs anfangen:
    ich teste gerade an einem speedup herum, der auch bei uhci/ohci zieml. denselben durchsatz bringt wie im fall, dass das display als ehci erkannt wird. der speedup ist eine contribution, den ich gerade fuer ein anderes display teste und der hier auch sehr nette ergebnisse liefert.


    klitzekleiner nachteil: funktioniert bis jetzt nur mit libusb (nicht mit HID), aber: nicht umsonst habe ich vor einiger zeit libusb fuer das l4m132c/l4me5i unter linux unterbunden:
    bei mir freezed die maschine, wenn das display ueber einen usb2-hub angehaengt ist, sobald ich enter druecke. aber so richtig. dh wenn es so bleibt wie jetzt (entweder die maschine freezed oder es funktioniert alles wunderbar) muss jeder, der den speedup ohne hub haben will, ein define setzen beim kompilieren, der libusb fuer die obengenannten displays wieder aktiviert unter linux.


    das ganze ist noch nicht im SVN. vorher moechte ich noch ein wenig herumexperimentieren.


    /wastl

    wastl


    Der HUB ist als Patch aber einfacher zu implementieren und die passenden Kabel bietet L4M auch an ;D


    Gruß
    Frank

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

    wastl


    Was ist denn eigentlich hier aus diesem Speedup für das L4M132C geworden?


    Mit serdisplib aus dem Branch 1.98.x gibt es ja keinen extra Schalter mehr für libusb, wird ja dynamisch angezogen:


    Code
    ...


supported extra libraries
=========================
 * libusb support            ... yes (dynamically added via dlopen())
 * libSDL support            ... yes (dynamically added via dlopen())
 * libpthread support        ... yes (dynamically added via dlopen())
 * libgd >= 2 support        ... yes
...

    Ich hatte das so verstanden, das man das Display dann direkt anspricht, also in der Art:


    Code
    Device=USB:USB:4243/ee08

    Wenn ich das aber mit den aktuelle Versionen ausprobiere:


    scheint das (noch) nicht zu funktionieren.


    Gruß
    Frank

    HowTo: APT pinning

    2 Mal editiert, zuletzt von fnu ()

    hallo frank,


    das hat nix mit dynamisch vs. statisch zu tun. beim ersten wird die libusb zur laufzeit ueber die libdl nachgeladen, beim statisch gelinkten wird es gleich beim kompilieren fix dazugelinkt.


    das problem beim l4m132c war, dass mir (und zwar auf mehreren unterschiedl. motherboards/usb-controllern) das system in verbindung mit dem cypress-chip und libusb einfach eingefroren ist. das wollte ich dann keinem zumuten. darum ist es standardmaessig deaktiviert (ist ein #define im code, den man setzen kann - der dann bei intel/amd-systemen aber auf eigene verantwortung).
    das soll auch die meldung 'support for libusb disabled for this device' ausdruecken.


    /wastl

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden