Re: Dell-Desktop USB-Tastaturproblem

On Tue, Aug 26, 2008 at 02:22:15AM +0200, Polytropon wrote:
> Zunächst mal von mir vielen Dank für diese technischen Einsichten,
> einiges gestaltet sich für mich durchaus nachvollziehbarer.
>
> On Mon, 25 Aug 2008 17:22:30 +0200, Bernd Walter <ticso(at)cicely7.cicely.de> wrote:
> > Nahezu jedes USB Gerät auf dem Markt ist buggy und da kann bereits
> > eine harmlos wirkende Änderung ein Auslöser sein.
>
> Tja, das habe ich mir hier von der Mailingliste auch erklären
> lassen müssen, weil ich es merkwürdig fand, daß eine Sun-USB-
> Tastatur und -Maus unter FreeBSD 5 tadellos funktionierte, unter
> FreeBSD 7 aber nicht mehr richtig erkannt wurde, zudem erst relativ
> lange nach Systemanlauf ihren Eintritt ins System fanden.

Nur, dass im Bereich 5 bis 7 nur an Details gedreht wurde.
Ich denke aber, dass die Gesammtsitiation mit dem neuen Stack besser
ist, weil auch der alte Stack reichlich Bugs hat, die selber zu
Kompatibilitätsproblemen führen.

> > Das ist auch der wesentliche Grund für die Änderung im Treiberdesign.
> > Das bisherige Verfahren war für UP vollkommen Ok, aber mit SMP sieht
> > es anders aus.
> > Performanceverbesserungen sind auch in anderen Punkten zu erwarten.
>
> Bezieht sich das eigentlich nur auf SMP-Kisten, oder können auch
> "altmodische" UP-Maschinen darauf hoffen, einen erneuten Geschwin-
> digkeitszuwachs (evtl. nicht nur auf der USB-Strecke) zu verzeichnen?
> (Ich will ja nicht undankbar erscheinen für die Arbeit, die so
> viele Leute in FreeBSD stecken, aber ich habe ehrlich keine Lust,
> laufend hart verdientes Geld auszugeben, um neue Rechentechnik
> anzuschaffen, nur damit geschwindigkeitsmäßig alles beim alten
> bleibt.)

Nun - die SMP Arbeit sorgt im wesentlichen dafür, dass im Kernel
mehrere Aufgaben gleichzeitig bewältigt werden können.
Das sorgt in einigen Fällen auch auf UP Maschinen für bessere Leistung,
aber andererseits auch für mehr Overhead.
Es hängt halt von der Anwendung ab, was nun überwiegt.
Das ist nicht nur bei SMP so - manche Optimierung zielt darauf ab,
dass sich die Geschwindigkeitssteigerungen der unterschiedlichen
Systemkomponenten unterschiedlich entwickelt haben.
Allgemein gesprochen wird aber SMP auch zunehmend in Kleinmaschinen
eingesetzt, vor allem im stromsparenden Lager, weil mehr Leistung
durch mehrere Kerne mitunter weniger Strom braucht, als durch höhere
Taktfrequenz.
Voraussetzung natürlich, dass die Software die Mehrleistung auch nutzen
kann.
Ich sehe die Leistungsverluste durch Software ohnehin kaum beim OS,
sondern in aller erster Linie bei den Anwendungen.
Ohne grafischen Browser kann man nur selten leben und der macht auf
alter Hardware keinen Spaß mehr, während man einen alten Browser auch
nur noch bedingt einsetzen kann.

Was den USB Stack im speziellen angeht - da bringt der neue eindeutig
auch im UP-Bereich mehr Leistung, was aber nicht an den SMP-Fähigkeiten
liegt.

>
>
> > Beim senden ist es einfach, weil man nur Buszeit für tatsächlich zu
> > sendende Daten belegt, aber beim empfangen muss man zum pollen der Daten
> > Buszeit belegen.
>
> Da denkt man manchnal sehnsüchtig an das "rückständige" Interrupt-
> verfahren zurück, wo nur Ressourcen belegt werden mußten, wenn auch
> wirklich was anlag. Zugegeben, der Aufwand der Implementierung ist
> hier oftmals höher und stammt konzeptionell noch aus einer Zeit,
> als Rechnerressourcen knapp und teuer waren.

Tja - USB war halt eher als Ersatz für Tastatur und Maus designed.
Es polled ja auch nicht die Haupt-CPU, sondern der Host-Controller.
Das Problem ist nur, dass das pollen Buszeit für die potentiellen
Nutzdaten belegt.
Wenn man nun von einem Gerät mit maximaler Geschwindigkeit lesen will,
dann muss man alle Frames zu 100% mit Lesetransaktionen für dieses
Gerät auffüllen.
Wenn vom Gerät nichts kommt sind die Frames nutzlos.
Mit einem Gerät kein Problem.
Mit 2 Geräten kann man nun jedes Gerät mit 50% Zeit veranschlagen.
Wenn beide senden ist gut, wenn eines nichts sended, dann bremst
dessen ungenutzte Buszeit das andere Gerät nutzlos aus.
Ob ein Gerät was sended weiß man aber nun mal nicht.
Man weiß, dass eine Maus sicherlich keine hohe Datenrate liefert,
also kann man dort wenig Buszeit veranschlagen.
Bei einer RS232 sieht das anders aus - da bringt eine typische RS232
nur wenige Daten, die sich anhand der bps-rate auch mit einem denkbaren
Maximum veranschlagen lassen.
Dummerweise gibt es auch pseudo-RS232, die volle Datenrate liefern
könnten und bei denen die eingestellte bps-rate keine Funktion hat.
Eine RS232 kann aber theoretisch immer Daten empfangen.
Bei einer Platten hingegen ist nur mit Daten zu rechnen, wenn ein
Lesebefehl aussteht, aber wann kommen die Daten?
Sobald eine Lesetransaktion aussteht muss man Buszeit veranschlagen,
wann auch immer die benutzt wird.
Man könnte jetzt wenig Buszeit veranschlagen und sobald was kommt
macht man viel Buszeit, aber das treibt die Latenz in die höhe,
weil man die 1ms für den nächsten Fram abwarten muss.
So manches Fielsystem reagiert aber in der Gesammtgeschwiindigkeit
sehr empfindlich auf hohe Latenz.

USB "Interrupts" gibt es auch.
Die basieren darauf, dass man wenig Buszeit zum pollen des Status
verbraucht, bevor man große Transaktionen aufsetzt.
Aber letzlich ist es das gleiche, wie oben zuletzt erwähnt - es treibt
die Latenz nach oben.

Es gibt bessere Systeme, als USB, aber wie so oft....
Als Workaround haben heute Boards halt schier unglaublich viele Busse,
damit sich die Geräte nicht behindern.
Ich selber entwickel mit USB nicht mehr viel - Ethernet mit IP ist zwar
sehr viel älter, aber auch um einiges besser.
Zudem ist Ethernet in den letzten paar Jahren auch im Microcontroller-
bereich bezahlbar geworden.
Der Konsumerbereich wird aber wohl noch viele Jahre bei USB bleiben.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message