USB3 tötet Firewire 800

[verstaerker]

meine beobachtung war bisher, dass firewire 400 unter WIN XP auch bei großen kopieraktionen zwischen externen festplatten vergleichsweise wenig CPU beansprucht hat, USB 2.0 hingegen deutlich mehr.

Das ist nicht normal. USB sollte auch bei voller Auslastung die CPU nicht wesentlich belasten.

doch es ist normal - deckt sich nämlich absolut mit meinen Beobachtungen

 

[Jens Groh]

[...] ist USB nur schneller aber die HW nicht intelligenter geworden, an den Protokollen hat sich afaik nix geaendert.

So sehe ich das auch. Das asynchrone Prinzip "Immer schön der Reihe nach" von USB wird sich immer durch die Treiber bis in die Anwendungssoftware ziehen. Die Anwendung kann also vom System weder eine Bandbreitenreservierung noch eine Antwortzeitgarantie bekommen. Die Folge: Puffern ist Pflicht.
Meine Einschätzung: Umstieg auf USB3 ist für Audio völlig sinnlos.
Aber andere nette Sachen kann man damit machen. Z. B. unkomprimiertes HD-Video drüberschicken. Schon cool das.

 

[marv42dp]

Hat da bitte mal jemand konkrete Zahlen? Ich kann hier unter 7-64 nämlich keinen Unterschied zwischen FW und USB bei der CPU-Belastung ausmachen.

Wie hast du das getestet?

Daten kopiert von
- SATA nach USB
- SATA nach FW
- USB nach USB
- FW nach USB
Im zweiten Durchgang auch mal praxisfremd jeweils nach einem Reboot.
In allen Fällen gibt es kurzzeitige (200-300ms) Peaks bis zu 60%, die von der explorer.exe kommen. Während der restlichen Zeit dümpelt die Last schnittstellenunabhängig bei 1-2% rum.
Es macht auch keinen Unterschied, ob ich die USB-Ports der Firewire-Karte (PCI) verwende, oder die auf dem Mainboard (PCIe). Auch am Notebook, wo der FW-Port am PCIe hängt, ist das Ergebnis identisch.

 

[Summa]

Ach so, ich dachte schon du haettest ein Benchmark Tool fuer Festplatten etc. verwendet...

 

[marv42dp]

Das asynchrone Prinzip "Immer schön der Reihe nach" von USB wird sich immer durch die Treiber bis in die Anwendungssoftware ziehen.

Und bei FW heisst es "gerne alle gleichzeitig"? Will sehen!

 

[marv42dp]

Ach so, ich dachte schon du haettest ein Benchmark Tool fuer Festplatten etc. verwendet...

Das wäre natürlich das falsche Werkzeug für den Zweck. Mich interessieren da ja nicht Transferraten, sondern die CPU-Last im Praxisbetrieb.

 

[Summa]

Du denkst das kopieren von Daten ist man naeher an der Praxis als ein Benchmark? Du hast sicher peinlichst darauf geachtet dass es jedesmal andere Daten sind, die oder deren Position auf der Platte nicht noch irgendwo im OS/HD gecached sind alle mit dem selben File-System arbeiten.

 

[marv42dp]

Du denkst das kopieren von Daten ist man naeher an der Praxis als ein Benchmark?

Ja. Benchmarks (außer der BapCo Sysmark) sind i.d.R. synthetisch, und damit zwar für akademische Messdaten interessant, für die Praxis aber eher wenig aussagekräftig. Insbesondere Festplattenbenchmarks sind für Schnittstellentests wenig brauchbar, denn die dabei entstehende CPU-Last ist das Produkt aus des zum generieren der Zufallsdaten nötigen Rechenaufwandes und des Prokolloverheads (von Schnittstelle und Dateisystem). Tests von Schnittstelle A zu Schnittstelle B sind nicht möglich (mir ist jedenfalls kein Benchmarkprogramm bekannt, das diese Option anbietet).
Wenn ich einen Plattenbenchmark verwende, um Caching-Einfluss zu vermeiden, kann ich gleich einen Reboot machen, dann habe ich auch keine Fehlerquelle durch den Zufallsdatengenerator.

Du hast sicher peinlichst darauf geachtet dass es jedesmal andere Daten sind, die oder deren Position auf der Platte nicht noch irgendwo im OS/HD gecached sind alle mit dem selben File-System arbeiten.

Cache-Einfluss wurde (wie erwähnt) durch Reboot eliminiert. Dateisystem ist hier immer NTFS, FAT benutze ich nur noch für Flash-Wechselmedien.

 

[Summa]

Die beim Musiker typische Anwendung waere doch eher die vom Speicher/Audio <--> HD oder und nicht das kopieren von Files. Da Windows 7 auch nix an den USB Protokollen veraendern kann, schaetze ich einfach mal, dass die Last auf der Treiberschicht oder kurze Spitzen vom Taskmanager nicht immer richtig abgebildet werden. Meine Erfahrung mit mobilen USB DVD Geraeten unter XP auf 'nem Dual Core Rechner sieht da ein klein wenig anders aus, die Belastung beim Nero DVD Speed Test lag bei etwa 16-76%, ein S-ATA Laufwerk erreichte nicht mal die Haelfte der Auslastung...

 

[marv42dp]

Die beim Musiker typische Anwendung waere doch eher die vom Speicher/Audio <--> HD oder und nicht das kopieren von Files.

Prima, dann entfällt sogar noch ein Teil des Dateisystemoverheads. Ob ich 30MB/s Audiodaten streame, oder Dateien, ist der Schnittstelle und der CPU latte - beides wird im isochronen Transfermodus gemacht.

Da Windows 7 auch nix an den USB Protokollen veraendern kann, schaetze ich einfach mal, dass die Last auf der Treiberschicht oder kurze Spitzen vom Taskmanager nicht immer richtig abgebildet werden. Meine Erfahrung mit mobilen USB DVD Geraeten unter XP auf 'nem Dual Core Rechner sieht da ein klein wenig anders aus, die Belastung beim Nero DVD Speed Test lag bei etwa 16-76%, ein S-ATA Laufwerk erreichte nicht mal die Haelfte der Auslastung...

Und wie sieht es bei Firewire aus?
Ich sage ja nicht, dass es keine Probleme gibt, aber meiner Erfahrung mit einer dreistelligen Anzahl von Systemen nach, ist höhere CPU-Last durch USB _kein_ Normalfall.

 

[Summa]

Was denkst du wie die Daten von der USB-Schnittstelle ohne Busmaster/DMA Mode den Speicher erreichen?

 

[marv42dp]

Was denkst du wie die Daten von der USB-Schnittstelle ohne Busmaster/DMA Mode den Speicher erreichen?

Äh, natürlich macht der USB-Controller DMA! Wo kommt denn das Gerücht her, dass er das nicht macht? Dass auf dem USB gepollt wird, hat nichts mit dem Transfer der Daten ins RAM zu tun!

 

[Summa]

Waer mir ehrlich gesagt neu, afaik ist die CPU fuer die Uebertragung zwischen Puffer und Speicher zustaendig.

 

[marv42dp]

Es gibt kein PCI-Gerät mehr, das kein DMA macht! Auf dem US-Bus wird gepollt (das braucht minimal CPU), der USB-Controller streamt die Daten aber via DMA ins RAM.

 

[Summa]

Ich lasse mich gern von geeigneter Quelle ueberzeugen, aber bitte nicht den USB Host mit 'nem USB Host-Adapter verwechseln...

 

[marv42dp]

Janu, nur der Host-Adapter kann DMA machen - er ist das PCI-Gerät. Das ist übrigens sehr Wowereit, denn DMA vom Device aus, wie bei Firewire möglich, ist eine fiese Sicherheitslücke.
Das zusätzliche Layer durch die Host-Struktur bei USB darf aber keine signifikante CPU-Last erzeugen, sonst ist halt was Faul im System. Man sollte das auch nicht mit Programmed I/O verwechseln, wo sich die CPU um den kompletten Datentransfer kümmern muss.

 

[Summa]

Ich denke der Fehler wird gerne gemacht, es gibt ja auch noch einen Host-Adapter der im USB Geraet die Verbindung mit der Festplatte herstellt...

 

[marv42dp]

Ich denke der Fehler wird gerne gemacht, es gibt ja auch noch einen Host-Adapter der im USB Geraet die Verbindung mit der Festplatte herstellt...

Nee, das ist ne Bridge.
Die betreibt die Schnittstelle zur Platte aber auch nicht im PIO-Mode (kann sie gar nicht). Host-Adapter stellen Host-Funktionen bereit, das macht der Bridge-Chip nicht, der kann nur Client.

 

[Summa]

Eine USB Bridge ist jetzt wieder was ganz anderes, die verbindet zwei USB Clients...

http://www.everythingusb.com/hardware/USB_Bridges/

Du hast sicher recht was PCI betrifft, dass es die Daten zwischen USB Chipsatz und Speicher uebertraegt, aber halt nicht selbststaendig sondern nur Frame also Haeppchen weise, d.h. ohne Steuerung der Software findet kein Datenaustausch statt...

Selbststaendig 'ne Platte steuern, dazu fehlt USB die noetige Intelligenz, da geht nur mit 'nem entspechenden Controller, 'ne "Bridge" alleine reicht da nicht...

 

[marv42dp]

Selbststaendig 'ne Platte steuern, dazu fehlt USB die noetige Intelligenz, da geht nur mit 'nem entspechenden Controller, 'ne "Bridge" alleine reicht da nicht...

Die Dinger werden halt Bridge-Chips genannt, technisch mag das nicht ganz korrekt sein. Nichtsdestoweniger machen die vor allem bei SATA nichts Rechenintensives, das schraubt nur ein wenig an der Latenz - für Massenspeicher eher egal. Die CPU des Hosts hat damit aber erst recht nichts am Hut. Die bekommt bei fehlerfreier Anbindung des Host-Adapters nur gelegentlich einen Interrupt von eben diesem, den Rest regelt der Kerl via DMA.

 

[Summa]

Klar hat die CPU des Host mit dem S-ATA transfer im USB Geraet nix zu tun, hat auch keiner behaupted, schliesslich steckt ein vollstaendiger Controller im Gehause, der die Platte hosted.

Folgender Link erklaert ein klein wenig wie das mit dem USB Transfere funktioniert, wenn auch im Hinblick auf den Energieverbrauch...

http://www.intel.com/technology/itj/200 ... -intro.htm

Zitat:

a USB device is incapable of transferring data or generating an interrupt without being polled by the host. The best it can do is indicate the rate at which it wants to be polled in the event that activity occurs. This rate is typically assigned statically when the device is first configured and tuned for highly active phases (e.g., to maximize throughput).

PCI:

USB:

In addition, many USB host controllers rely on main memory for their schedule information. Data structures within the USB schedules inform the host controller of the (active) synchronous and asynchronous endpoints that need to be serviced, the polling frequency for synchronous endpoints, memory locations for data transfers, etc. The host controller must access these structures frequently, both to understand when endpoints need to be serviced (polled) and to initiate each transfer request—regardless of whether data are actually transferred.

USB transfers are inherently less efficient than equivalent PCI transfers, requiring a total of six cycles (three being snoops) versus two cycles (one snoop) on PCI. But the bigger issue is that USB endpoints that have no data to move (constantly NAK) continue to be polled by the host resulting in a fairly active USB subsystem that generates frequent memory accesses, snoop cycles, and USB transfers. This behavior does not occur on PCI or other non-polled interconnects. Thus, USB works quite hard at doing nothing, which translates into poor energy efficiency.

Andere Quelle:

http://www.everythingusb.com/usb2/faq.htm

Additional notes from Alex Esquenet - our engineer friend based in Belgium: "A fast usb host can achieve 40 MBytes/sec. The theorical 60 MB/sec cannot be achieved, because of the margin taken between the sof's (125 us), so if a packet cannot take place before the sof, the packet will be rescheduled after the next sof. On top of that, all the USB transactions are handled by software on the PC. For instance, a USB host on a PCI bus will send or receive the data via the PCI bus; the stack will prepare the next data in memory and receive interrupt from the host."