Diskussion:FireWire

"Hot unplug"

bei der sache mit dem "hot unplug" muss es sich um einen witz handeln. zum mindesten apple betriebssysteme erlauben das schlichtweg nicht. der verlust einer firewireverbindung von einem PC zu einem massenspeichermedium führt augenblicklich zu einer fehlermeldung am host, die nicht umgangen werden kann. firewire volumes sind grundsätzlich zu unmounten bevor die verbindung unterbrochen werden darf. datenverlust auf firewirevolumes bei nichtbeachtung ist der regelfall. [-IIO]

---

Im Großen und Ganzen ist der Artikel OK. Was noch fehlt sind die Übertragungsarten Asynchron und Isochrone.

Der Abschnitt Sicherheit ist etwas unglücklich formuliert, hoffe es bald mal überarbeiten zu können. Fakt ist: es ist kein FW-, sondern ein OHCI-Problem und diese Lücke besteht, weil die Access control lists nicht entsprechend initialisiert werden. D.h. Windows ist sehr wohl betroffen, nur das bei Windows relativ schnell nach beim Booten dieser Filter gesetzt wird - was aber immer noch genügend Platz für eine Race Condition bietet.

Adressierung

32-16-8-4-2-1 = 63 da 6 Bit Adressierung (nicht 64) [Buschl]

6 Bit ergeben aber 64 Zustände bzw. Adressen: 0d bzw. 000000b bis 63d oder 111111b einschließlich. Nur ist AFAIR eine davon (die 0?) für Broadcasts reserviert. Womit ein „unter dem Strich 50% korrekt“ übrig bleiben würde. Genau.

Datum

ist eine 1986 von Apple entwickelte Schnittstelle. Kann das stimmen? Wenn ja sollte kurz behandelt werden, was von '86 bis '95 damit passiert ist -- Emil 'nobs' Obermayr 16:03, 16. Sep 2006 (CEST) Wann Sony Ilink eingeführt hat, weiß ich nicht. Der DCR-VX 1000 von 1995 hatte aber schon die Mini 4 Pol Buchse

meines Wissens stimmt das nicht. wie weiter unten erwähnt schreibt auch die englischsparichige wikipedia nur davon, dass apple den "anstoß" zur entwicklung -durch andere!!- gegeben hat. (nicht signierter Beitrag von 193.171.244.61 (Diskussion) 23:08, 22. Mai 2010 (CEST))

Adressierung

Es fehlen weitere Informationen zur Adressierung der einzelnen Geräte. Zyklen, Adressverwaltung etc.

Foto

Kann man nicht einfach die Bilder der englischen Webseite übernehmen? Der Holztisch lenkt sehr ab vom Wesentlichen (sieht ein wenig komisch aus) und die Mac-Frontblende entält nur wenig Bildinformation zum Thema Firewire

Also ich find die Bilder jetzt auch net unbedingt den Bringer, aber nur weil es mir wie eine Apple-Propagandaseite vorkommt... Aber die Bilder von der Englischen Seite sind ja richtig mies. Da dann lieber die Bilder behalten. Gut aussehen tun sie ja... mfg ichdertom

Auf dem Bild ist doch FireWire 800 abgebildet und nicht FireWire 400 oder?

ich finde auch, dass usb und g5 hier keine rolle spielen sollte; das lässt den artikel wirken wie ein hochruf für advertisment

Audio

Ich vermisse im Artikel Informationen zur Verbreitung von externen Audio-Interfaces (z.B. von Motu oder das RME Fireface). Firewire scheint sich hier wachsender Beliebtheit zu erfreuen. Leider habe ich zu wenig Überblick über das Thema um eine fundierte Ergänzung einfügen zu können. DrNI 2007-09-18, 00:30

IEEE 1394

Kann die Kontaktbelegung der Steckverbindung (4 und 6-pol.)aufgezeigt werden? Besten Dank für eine Ergänzung!

• Belegung von Partsdata

IP over 1394

In Win Me / XP / 2003 sind IEEE1394 Verbindungen automatisch als Netzwerkkarte konfiguriert. Nun habe ich folgendes gefunden:

I http://www.microsoft.com/whdc/system/bus/1394/IP_1394.mspx

es gibt von der firma unibrain einen treiber für Ethernet over Firewire --Moritzgedig 11:55, 23. Sep 2006 (CEST)

Mechanische Spezifikation fehlt

Mir fehlt jeder Hinweis auf die mechanischen Spezifikationen der Steckverbinder für Fire Wire. Kann jemand Auskunft geben, wo diese beschrieben sind?

Ja, hier z.B.: 1394 Steckverbinder von Molex

Sicherheit

Es fehlen weitere, ausführlichere Informationen und Spezifikationen zum Thema Sicherheit bei Firewire/IEEE1394. --Philipp Grunwald 23:55, 29. Aug 2006 (CEST)

Sicherheit, die Zweite:

Ich habe zwar nur ein paar Informationen aus einer für mich zwar bedeutsamen, hier aber kaum relevanten Quelle (es fehlen einfach zu viele Belege usw.), aber ich habe „gehört“, daß das geschilderte Sicherheitsproblem so oder in ähnlicher Form keines von FW/IEEE1394 alleine sein soll. Prinzipiell, so scheint es mir, können davon alle IO-Schnittstellen mit vergleichbarer Konstruktion (Anbindung über PHY mit DMA-Fähigkeit an passende Systemkomponenten) betroffen sein.
Sogar USB scheint davon betroffen zu sein (trotz des Polling). Zumindest konnte ich bei meinen bisherigen Recherchen ein paar Lücken in der Dokumentation bzgl. des Zusammenschaltens von Controllern nicht soweit klären, als daß es da keinen passenden Interpretationsspielraum mehr gäbe.
Irrelevant? Nun, wenn an dieser Spekulation etwas dran ist, dann könnte ein üblicher x86-Rechner, der bis zum BIOS-Setup hochgefahren wird, bereits über USB via DMA … (schließlich wird für die Tastatur heute ja das USB-System üblicherweise schon früh genug aktiviert!)
--87.163.120.4

Da USB kein DMA kann und das USB-Gerät dem USB-Hostcontroller auch keinerlei Speicheradressen und ähnliches vorgeben kann, wo dieser hinschreiben soll, wüsste ich nicht, wie ein USB-Gerät beliebige Speicherbereiche auslesen oder überschreiben können soll. --RokerHRO 13:41, 9. Feb. 2008 (CET)

USB kann also kein DMA? Dann wird es aber schwierig mit dem SCSI-Protokoll, das da (teilweise) drüber laufen soll: http://t10.org/scsi-3.htm. Und rein physisch? Der Chipsatz besteht heute aus einem Chip, in dem das ganze Bussystem zusammenläuft. Und in dem der gesamte Zugriff auf die Systemkomponenten reguliert wird. Und dann meint intel noch dazu “Support for 32 and 64-bit Addressing. Over the implementation lifetime … The EHCI includes optional interface extensions that support up to 64-bits of addressing“. 64 Bit sind wohl kaum mehr optional. Die Frage, wofür aber so ein nicht DMA-fähiger „Chip“ davon was wissen müßte – schließlich muß so ja die CPU all die Daten abholen und abliefern und nur sie müßte das Ding adressieren können – könnte ich mir schon beantworten. — Hoppla, jetzt hätte ich doch fast die Quelle vergessen: http://www.intel.com/technology/usb/ehcispec.htm, “Enhanced Host Controller Interface Specification for Universal Serial Bus, Version 1.0” (eigentlich also http://www.intel.com/technology/usb/download/ehci-r10.pdf), Seite iii, Introduction, erste Liste, letzter Punkt. Und, oh, USB wird nur gepollt? “Interrupt On Complete (ioc). 0 = Do not interrupt when transaction is complete. 1 = Do interrupt when transaction is complete. When the host controller determines that the split transaction has completed it will assert a hardware interrupt at the next interrupt threshold.“ (S. 38). Der Chip entscheidet also ggf., ob und wann er dem System mitteilt, daß er mit seinen Aktivitäten fertig ist. Ja wird denn der nicht fortlaufend von der CPU gesteuert?

Danke für die EHCI-Spec. Ich finde dort nirgends etwas von "DMA" oder "direct memory access". Man findet dort nur, dass stets der USB-Hostcontroller das USB-Gerät anweist, Daten zu schicken oder in Empfang zu nehmen. Das USB-Gerät hat keinerlei Möglichkeiten, von sich aus Daten an den Host zu senden oder zu lesen, es kann nur einen Interrupt-Request auslösen, und dann ist es Sache des Hostcontrollers bzw. der Systemsoftware, auf den IRQ zu reagieren. Die Speicherbereiche, in die der Hostcontroller die Daten vom USB-Gerät schreibt, bzw. von denen er liest, werden allein von der Systemsoftware festgelegt, das USB-Gerät hat keine Möglichkeit, den Hostcontroller umzuprogrammieren und so eigene Speicherbereiche festzulegen, es kennt die Adressen dieser Speicherbereiche nichteinmal, wozu auch.

Warum du 64-Bit-Adressierung und SCSI erwähnt hast, ist mir auch nicht klar. Beides hat nichts mit DMA zu tun. Da das USB-Gerät die Speicheradressen, in die der Hostcontroller schreibt, nicht kennt, weiß es auch nicht, ob der Hostcontroller in einem 64-Bit-System arbeitet. Der Hostcontroller weiß das natürlich, der darf ja auch in den Speicher schreiben und von dort lesen. Und für SCSI-over-USB (oder "USB-attached SCSI") braucht man auch kein DMA.

--RokerHRO 01:49, 10. Feb. 2008 (CET)

Daß ich nur wenig an konkretem Material – jedenfalls welchem, das veröffentlicht werden kann und als glaubwürdig anerkannt würde – habe, wurde ja bereits erwähnt. Also gibt es nur Indizien (und verlangt nach Leuten, die weiter stöbern):

http://www.freepatentsonline.com/EP1627312.html “… Description: … However, it is becoming recognised that it would be useful to allow other devices, for example such as mobile phones, to act as USB hosts …”

http://www.patentstorm.us/patents/7035948-claims.html “… A method for transferring information between a host system and a Universal Bus System (USB) device via a USB Host Controller …“ (gerade eben hatten wir “mobile phones” als USB-Host) “… writing data packets in the second memory buffer, while data packets are being read from the first memory buffer; wherein during a direct memory access (DMA) mode …”

und http://www.projectblackdog.com/3rdParty/kernel-doc-2.6.10.msw1/Documentation/DocBook/usb/r2561.html belegt natürlich nur, daß DMA da prinzipiell schon mitspielt.

Spannung

Ist schon komisch, dass überall im Netz 8-40W, 1,5A steht - allerdings fast immer im gleichen (abgeschriebenenen) Zusammenhang bzw. Textlaut. In den (nicht freien und daher nicht verlinkbaren) Specs steht 8V-33V, was ich nur mit folgendem Link einer Firewire-Schutzbeschaltungs-Applikation-Note verlinken kann: http://www.circuitprotection.com/04Databook/C08_1394_(115-117).pdf

Topologie BUS oder Netzwerk?

im artikel werden die begriffe netzwerk und bus benutzt.
handelt es sich nicht mehr um ein netzwerk? --Moritzgedig 11:57, 23. Sep 2006 (CEST)

Übertragungsrate

Bei Übertragungsrate und Einsatzgebiete sind unterschiedliche Übertragungsraten angegeben.

nochmals Datum

Ich habe das Datum von 1950 auf 1986 geändert. Dies wurde wieder rückgängig gemacht, mit dem Hinweis auf fehlende Begründung.

Die Idee kann nicht auf 1950 zurückgehen, da es Apple zu diesem Zeitpunkt noch nicht gab. Außerdem war das Datum auch in früheren Versionen 1986, bis es zu 1950 geändert wurde. Der folgende Satz "es dauerte fast ein Jahrzehnt..." deutet ebenfalls darauf hin, dass 1986 richtiger ist.

Spannung

Die Spannung auf dem BUS ist min. 8V DC und max. 30V DC. Quelle: IEEE1394a/b Standard. Ursprünglich waren es 8V-40V Quelle: IEEE1394-1995 Standard. Bei der Steckerbelegung sollte anstelle 12V die 8V-30V angegeben werden.

Spannung

Die Spannung auf dem BUS ist min. 8V DC und max. 30V DC. Quelle: IEEE1394a/b Standard Ursprünglich waren es 8V-40V. Quelle: IEEE1394-1995 Standard. Bei der Steckerbelegung sollte anstelle der 12V ebenfalls 8V-30V angegeben werden.

Konkurrenz zu USB??

Seit wann denn das? FireWire zielt eindeutig auf andere Segmente ab, als USB. USB mit niedrigen Übertragungsraten ist für Mouse, Keyboard etc. interessant. Aber jeder wird wohl zustimmen, dass FireWire für HDDs und extrem große Datentransferraten einsame spitze ist und diesen Markt beherrscht.

Dir ist schon bewusst, dass USB 2.0 bei Markteinführung das Schnellste war, was es für die externe Anbindung gab (480zu 400 MBit)? Und warum werden bloß die meisten externen Festplatten immer noch mit USB ausgeliefert... --Andreas 06 - Sprich mit mir 21:13, 2. Okt. 2007 (CEST)

Das ist Unsinn. Die nominellen Datenraten werden bei USB eher noch weniger erreicht. Insofern ist auch der im Artikel vorhandene Hinweis auf die magere Performance von Firewire unzutreffend. Der Protokoll-Overhead ist in beiden Fällen so groß, dass am Ende nur knapp über 30 MByte/s durch's Kabel wandern. Gegen FW 800 sieht USB 2.0 dann allerdings tatsächlich alt aus.

Quellen wären auch nicht schlecht, wenn man solche Behauptungen aufstellt. ;-)

c't 15/01, S.128 [1]

Tests von externen Gehäusen mit Firewire und USB 2.0 sind in c't 9/02 und c't 15/05 drin. Letztere zeigt, dass die Datenraten vergleichbar sind und um die 30 MByte/s liegen.

Ansonsten kann Firewire 1,5 A bereit stellen, ich habe noch von keiner externen 2,5"-Firewire-Platte gehört, wo der Controller abgeraucht ist. USB liefert nur 0,5 A, da ist das schon häufig vorgekommen. --LeSpocky 16:28, 10. Jan. 2008 (CET)

Ich hab heut extra nochmal in der Bibliothek in c't 9/02 geschau. Bei den dort getesteten Gehäusen liegen die Übertragungsraten von USB 2.0 noch so um die 18 MByte/s während FireWire dort auch schon über 30 MByte/s erreicht bzw. die volle Transferrate der Platten von 2002. --LeSpocky 15:08, 11. Jan. 2008 (CET)

Serieller Bus

Meiner Meinung nach sollte in der Einleitung erwähnt werden, dass FireWire ein serieller Bus ist.

Gründe, die dafür sprechen:

• Es wird nirgendwo im Artikel explizit erwähnt
• FireWire wird auf der Seite Bus (Datenverarbeitung) als Beispiel für einen seriellen, externen Bus angeführt
• Es entspricht dem englischen Artikel

--217.224.206.203 11:43, 29. Okt. 2007 (CET)

Mbit/s != Mbit/s

im Text wird folgendes geschrieben: 3.145,728 Mbit/s bzw. 3.000 Mbit/s - das widerspricht sich selbst!

entweder 3.145,728 Mbit/s bzw. 3.000 Mibit/s oder 3.145,728 Mbit/s bzw. 3 kMibit/s (wenn SI-Präfixe und Binärpräfixe kombiniert werden)

Kombinierte Präfixe gibt es nicht und diese sind ausdrücklich laut BIPM verboten. (nicht signierter Beitrag von 84.190.186.191 (Diskussion) 14:15, 29. Jan. 2011 (CET))

oder 3.145,728 Mbit/s bzw. 3 Gibit/s (wenn nicht kombinert)

Maximale Groesse von FW-Massenspeichern?

Hallo, im Text steht nichts zu diesem Thema: gibt es für Massenspeicher (Festplatten oder RAIDs), die über FW an einen Rechner angeschlossen werden, eine obere Grenze, welche Grösse adressiert werden kann? --Binninger 08:57, 24. Dez. 2007 (CET)

Da scheint es von dieser Seite her kaum noch nennenswerte Unterschiede zu geben: http://t10.org/scsi-3.htm — die „sprechen“ mittlerweile alle (mehr oder weniger) SCSI.

Hallo,

danke, nur verstehe ich nichts von dem, das da steht. Kann mir da jemand weiterhelfen?

Wenn es zwischen SCSI und Firewire keine Unterschiede mehr gibt ist meine naechste Frage: was ist die obere Grenze fuer SCSI? --Binninger 14:14, 3. Mär. 2008 (CET)

Zuminndestens USB-HDDs werden intern meist über PATA oder SATA angesprochen, ich glaube nicht, dass das bei Firewire anders ist (viele externe HDDs unterstützen ja auch beides). Damit wärte die Kapazitätsgrenze bei 28bit-Addressiergung 128GB (in dem Fall 1 GB = 1024^3 Bytes), bei 48bit-Addressierung 128 Petabytes (1 PB = 1024 GB). --MrBurns 00:25, 28. Apr. 2009 (CEST)

Neuer FireWire-Standard?

In den IT-News wurde breit über den neuen Standard berichtet - und das schon vor einer ganzen Weile!

• http://www.tomshardware.com/de/FireWire-USB-3-0-GBit,news-241407.html
• http://www.heise.de/ix/Firewire-mit-3-2-GBit-s-in-Sicht--/news/meldung/113774
• http://www.heise.de/newsticker/FireWire-S3200-mit-3-2-GBit-s-Update--/meldung/100678

Ich finde dies sollte -zumindest am Rande- mit erwähnt werden.

Da hast du vollkommen Recht. Aber dann bitte z. B. mit einer Referenz in den Artikel einbauen. — Regi51 (Disk.) 14:35, 5. Aug. 2008 (CEST)

Steht ja jetzt hier. Als Referenz im Hauptartikel finde ich solche kurzen wenig ins Detail gehende Quellen nicht für zweckmäßig.

Stromversorgung

Die meisten externen 2,5-Zoll-Festplatten werden ja per USB mit Strom versorgt. Nun ist jedoch hier im Artikel folgendes zu lesen.

„Im Gegensatz zu USB mit lediglich 0,5 A ist die Stromversorgung über FireWire mit 1,5 A spezifiziert. 2,5″-Festplatten benötigen zum Anlaufen knapp über 1 A, weshalb vom sogenannten „bus-powered“-Betrieb von USB-Festplatten abgeraten wird.“

Dies suggeriert, dass diese doch weit verbreiten Platten technisch mangelhaft bzw nur außerhalb der Spezifikationen funktionieren. Eingefügt wurde die Information von Benutzer:LeSpocky in dieser Version - ursprünglich war hier nur von der Stromversorgung von 3,5-Zoll-Festplatten über USB die Rede.Hat irgendjemand mehr Informationen/Wissen zu diesem Thema? --Sai 15:35, 5. Aug. 2008 (CEST)

Es ist in der Tat so. 3,5-Zoll-USB-Festplatten haben meines Wissens stets ein eigenes Netzteil, da diese selbst im Idle-Betrieb die erlaubten 500 mA überschreiten. 2,5-Zoll-Platten können dies jedoch schaffen. Auch die Stromspitze beim Einschalten der Platte lässt sich durch eine geeignete elektonische Schaltung abfangen (Darauf verzichten die preiswerten USB-Plattengehäuse aber anscheinend oft).

Das Problem ist jedoch noch ein anderes: Bei USB darf ein Gerät die 500 mA nur dann beanspruchen, wenn es dafür vom Hostcontroller die Freigabe bekommen hat, sonst ist die Stromaufnahme auf 100 mA begrenzt. Viele 2,5-Zoll-USB-Platten ziehen die volle Leistung jedoch bereits beim Einschalten, noch bevor der USB-Controller der Platte vom USB-Hostcontroller die Freigabe dafür bekommen hat. Dies kann schnell zu Überlastung des Hostcontrollers (bzw. dessen Spannungsversorgung) führen, insbesondere, wenn er mehrere leistungshungrige USB-Geräte (2,5-Zoll-Platten, netzteillose USB-Scanner usw.) zu versorgen hat. Firewire-Controller sind dagegen für höhere Speisespannungen und -ströme ausgelegt und haben daher in der Regel genügend Reserven, auch für Stromspitzen usw. --RokerHRO 19:08, 5. Aug. 2008 (CEST)

Überarbeiten (IEEE 1394-2008 (auch FireWire S3200 genannt))

Was ist mit "dieses Jahr" gemeint? 2008, 2007? Aufgrund des Namens lässt sich 2008 vermuten - aber das muss nix heissen? Wer hat das verabschiedet? Welcher Standard und welche Standardisierungsorganisation ist dafür verantwortlich - wieder die IEEE oder heisst das ding nur mehr so? --suit 10:04, 18. Aug. 2008 (CEST)

Ich nehme mal an, dass 2008 gemeint ist, weil in der letzen Version von 2007 des Artikels fehlt dieser Abschnitt noch. --MrBurns 18:24, 17. Okt. 2008 (CEST)

Unter en:FireWire steht auch, dass S3200 2008 eingeführt werden soll. --MrBurns 18:29, 17. Okt. 2008 (CEST)

Auf der IEEE-Website (http://standards.ieee.org/announcements/ieee1394.html) steht auch "The standard is expected to be available this October." -WeißNix 10:48, 18. Nov. 2008 (CET)

Hab's gefunden und im Artikel eingearbeitet: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=4659232&arnumber=4659233&punumber=4659231 -WeißNix 11:19, 18. Nov. 2008 (CET)

Dann kann wohl auch der Überarbeiten-Baustein langsam mal raus, oder? Hab das zumindest mal getan. --YMS 21:35, 9. Mär. 2009 (CET)

Tausch Abschnitt Entwicklung mit Architektur

Der Abschnitt „Architektur“ kommt vor „Entwicklung“, nur werden dort bereits die Bezeichnungen S200, S400, IEEE 1394b eingeführt, die eigentlich erst im nächsten Absatz erklärt werden. Für Leute, die sich informieren wollen ist dies erst mal etwas verwirrend. Ich mußte gerade selbst überlegen „was ist eigentlich S200?“, bevor ich durch den nächsten Abschnitt draufkam. Hatte bis dato mit „S200“ noch nichts zu tun, „S400“ und „IEEE 1394b“ sagten mir aber etwas. Andere mag das aber, wie gesagt, ein wenig „erschlagen“.

Wäre es nicht besser, die Abschnitte einfach zu tauschen? Immerhin sind beide recht kurz, in „Entwicklung“ können alle bisherigen (und zukünftigen) Ausprägungen von Firewire, und damit die wichtigen Begriffe/Bezeichnungen, kurz angerissen werden, wie jetzt schon gemacht. Eigentlich keine Arbeit. Es muß nichts umgeschrieben werden und der Lesefluß bleibt erhalten. Gute Idee? -- Andi; 18:42, 7. Feb. 2009 (CET)

48W max.?

Mir kommen die im Artikel erwähnten 48W max. unlogisch vor, wiel dort eine Spannung von 8V-33V und eine Stromstärlke von 1,5A erwähnt wird und 33V*1,5A=49,5W. --MrBurns 01:16, 26. Apr. 2009 (CEST)

Vielleicht ist bei maximaler Spannung nicht die maximale Stromstärke erlaubt? Oder die 48 Watt sind ein absichtlich etwas abgerundeter Wert, um das Limit nicht auszureizen. *wild rumrate* --RokerHRO 23:18, 27. Apr. 2009 (CEST)

Geschwindigkeit von Festplatten?

In dem Artikel ist die Rede von 70 MB/s. Woher soll denn dieser Wert kommen?

Zu IDE finde ich 133 MB/s und zu S-Ata sogar 300 MB/s. (nicht signierter Beitrag von Yatsura (Diskussion | Beiträge) 12:32, 24. Sep. 2009 (CEST))

von Aplle entwickelt?? QUELLEN BITTE!!

und selbst die englische wikipedia schreibt von " and developed by the IEEE P1394 Working Group" was soviel heißt wie "und entwickelt von der IEEE P1394 Working Group".

FireWire is Apple's name for the IEEE 1394 High Speed Serial Bus. It was initiated by Apple (in 1986[2]) and developed by the IEEE P1394 Working Group, largely driven by contributions from Apple, although major contributions were also made by engineers from Texas Instruments, Sony, Digital Equipment Corporation, IBM, and INMOS/SGS Thomson (now STMicroelectronics). (nicht signierter Beitrag von 193.171.244.61 (Diskussion) 23:08, 22. Mai 2010 (CEST))

zurückgesetzt?

ich finde die Art wie Krd agiert eine bodenlose frechheit. ohne eine einzige quelle zu nennen setzt er sich über die änderungen hinweg und stellt sie zurück? fachliteratur als auch die englischsprachige wikipedia meinen etwas anderes, aber Nutzer Krd weiß es besser. Ein tolles Beispiel für Wissensverlust durch die unwissende Masse wie sie bereits auf der Hauptseite von Wikipedia beschrieben ist: "Neben dem Problem bewusster Fehleintragungen besteht das weit komplexere Problem, dass sich statt Wissen Halbwissen in der Wikipedia durchsetzen könnte. In einer durch Arbeitsteilung ausgezeichneten Gesellschaft verfügt immer nur eine Minderheit über Fachwissen. Diese Minderheit läuft jedoch stets Gefahr, von der Mehrheit „korrigiert“ zu werden." siehe http://de.wikipedia.org/wiki/Wikipedia#Probleme (nicht signierter Beitrag von 193.171.240.88 (Diskussion) 22:51, 24. Mai 2010 (CEST))

Der Punkt ist, dass das Lemma hier "FireWire" heisst, und dann im Artikel auch FireWire beschrieben werden soll. Falls es hier um IEEE 1394 gehen soll, müsste der Artikel dahin verschoben werden. --Krd 07:15, 25. Mai 2010 (CEST)

In der englischen Version heißt der Artikel geschickterweise ieee 1394 und man wird von firewire weitergeleitet! (nicht signierter Beitrag von 193.171.240.119 (Diskussion) 15:57, 30. Mai 2010 (CEST))

Vollduplex?? Und andere Macken …

Zumindest ist IEEE1394 (ohne "a") nur halbduplex, und ich würde mich wundern, wenn das bei IEEE1394a nicht auch so wäre. Richtig ist nur, IEEE1394b ist vollduplex und verwendet eine andere Leitungskodierung (8B/10B) für die Taktrückgewinnung.

Womit ich gleich beim nächsten Irrtum bin: Die meisten glauben, IEEE1394b bedeutet 800 MBit/s. Nein! Es bedeutet nur andere Signalisierung. Eine Reihe 1394b-Geräte kann trotzdem nur 400 MBit/s, namentlich HBM QuantumX MX-840. Das bekommt man heraus, indem man das wahnsinnig teure Gerät öffnet und die Datenblätter der Chips durchliest. Es ist also genauso wie bei der Bezeichnung „USB 2.0“: High-Speed ist's deswegen nicht zwangsweise.

Womit ich gleich beim nächsten Irrtum bin: Die meisten glauben, FireWire bedeutet 400 MBit/s. Nein! Garantiert sind nur 100 MBit/s (S100). Eine ganze Reihe FireWire-Kameras kann nur S100. Ist billiger, ausreichend und spart etwas Strom. Da ist der Unterschied zu USB High-Speed (480 MBit/s) schon beachtlich.

Ich habe den Artikel bezüglich der nicht-standardkonformen Rundstecker ergänzt. Denn sowohl MicroEpsilon als auch HBM setzen 8-polige Push-Pull-Stecker der Firma ODU (vergleichbar LEMO, steckkompatibel aber Innenteile nicht austauschbar) ein. Nur ist deren Anschlussbelegung verschieden ausgelegt!! Hat man Geräte von beiden Herstellern und vertauscht irrtümlich die Anschlusskabel (die äußerlich völlig gleich aussehen), kann man umgehend sein teures Messequipment grillen, da die hohe Speisespannung an den empfindlichen Datenleitungen anliegt. Soviel zum Thema Plug'n'Play, das mutiert hier zu Plug'n'Fire. Wieder andere Firmen setzen 6-polige LEMO-Stecker ein (namentlich InfraTec).

Was summa sumarum nur ein weiteres Manko von FireWire deutlich macht: Für das (für FireWire letztlich verbliebene) Hochpreissegment fehlt im Standard einfach ein entsprechend teurer und hochwertiger Steckverbinder. Immerhin gibt's von LEMO/ODU auch (druck)wasserdichte, öldichte, ex-geschützte und werweißwas für Ausführungen jener Stecker.

Kritik am Standard-Steckverbinder (IEEE1394 und IEEE1394a): Auch wenn der Stecker verpolungssicher aussieht, mit genügend Gewalt (im Maschinen-Bauern-Bereich reichlich vorhanden) bekommt man den Stecker auch 180° verdreht in die Buchse. Das führt schließlich zu Plug'n'Fire, da wieder die Speisespannung an die Datenleitungen kommt. Die undurchdachte Anschlussbelegung ist hier Mitverursacher des Problems. Ist bei IEEE1394b behoben, aber wacklig ist der Stecker trotzdem geblieben.

Vergleich USB High-Speed und FireWire IEEE1394a S400: Hier werden sehr gern praktische Messungen ins Feld geführt, die belegen, dass USB langsamer (etwa halb so schnell) ist wie FireWire. Daran gibt's prinzipiell nichts auszusetzen, vergleicht aber nicht zwei Standards, sondern zwei Implementierungen. Nach Standard sollten beide etwa gleich schnell laufen. Die 80 MBit/s mehr bei USB werden durch folgende Maßnahmen bei FireWire „kompensiert“:

• Kein Bit-Stuffing
• Größere verfügbare Bandbreite bei isochronen Transfers (80% statt 3 Pakete à 1024 Bytes pro Mikroframe)
• Größere Paketgröße bei asynchronen Transfers (2048 Bytes) als bei USB Bulk-Transfers (512 Bytes)
• Zeitlich variable Start-Of-Frame-Kennung (wenn ich den Standard richtig interpretiert habe; ist bei USB unverrückbar bei 8 kHz respektive 125 µs)
• Durchdachte Busarbitrierung

Interessant beim Vergleich ist, dass die Frame-Rate (8 kHz) identisch ist. --Henrik Haftmann (Diskussion) 11:21, 23. Mär. 2012 (CET)

der wesentliche unterschied ist, dass USB devices auch dann bandbreite "belegen", wenn sie gerade nichts transferieren. für mehrere massenspeicher ist firewire S400 daher stets "schneller" als USB, ohne dass das irgendetwas mit den 40 vs 48 mb/s zu tun hätte.

deswegen gibt es auch für firewire S400 aktive hubs mit bis zu 48 anschlüssen.[-IIO] 2019

Es fehlt: Fernsteuerung von Videogeräten

Es fehlt in der Beschreibung, daß man über die Firewire 400 auch Videogeräte fernsteuern kann.Das ist besonders praktisch, wenn man Filme von Cassetten(Mini-DV, VHS) auf den PC kopieren will.