Jump to content

Talk:IEEE 1394/Archive 2006

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia


Transport protocol(s)

The [www.t10.org T10] architecture model shows that Serial Bus Protocol (SBP) is transport protocol for IEEE 1394 buses in the SCSI-3 framework. There is mention of its use for disk drives in the "Security issues" along with a bit about OHCI. Here are some of the questions on my mind:

  • Is OHCI a transport protocol that is a peer of SBP?
  • Are there other transport protocols?
  • Can we get more info on the transport protocol(s) before jumping into a discussion about their security issues?
  • How much information about the transport protocols are included in the IEEE 1394 specifications?

Cy jvb 15:20, 6 March 2006 (UTC)

The camcorder article implies that all camcorders (except those rarities that don't even have a FireWire interface) send video over FireWire in DV format. So ... does DV describe everything, or is it layered on top of some other protocol? ( SBP ?) I'd like more details on video over FireWire -- or a link to more details ? --65.70.89.241 16:38, 1 August 2006 (UTC)

I tried searching for "Fire Wire" and got nothing in the search result that matched this article. I then tried IEEE 1394 - and again got nothing that matched what I was searching for. [firewire]

Is it possible to put in a dis-ambiguation page of some sort that forwards 'Fire wire', and 'IEEE 1394' and 'IEEE1394' to this 'Fire Wire' page ?

Have done. Njál 23:45, 6 April 2006 (UTC)

Firewire 800

IIRC, loops of devices are allowed with Firewire 800.

Perhaps "Firewire 800" should be in its own little sub-section. It has a different connector, different allowable topology, different allowable medium ... basically it's different from (normal) Firewire in a number of ways. Also, it's not nearly as common. If I was coming here for information about Firewire, I'd find it easier if I saw all the Firewire 800 stuff in its own section, could tell that that's not what I'm interested in, and could ignore that section.

Curious about the 1394b speeds... what's the fastest speed I can expect with a qualified 1394b cable? Article only mentions optical mode.

With 1394b, you can, get at tops, of course, 800 Mbits a second, which is just arround 100 MB/sec, which is faster than standard Ethernet, but not as fast as Gigabit. This is of course at best circumstance, in real life, I have been able to get an average of 70 MB/sec, which is more than fast enough for external harddrives and whatnot. CoolFox 05:25, July 20, 2005 (UTC)

The 1394b cable (9-pin) supports (and has been actually tested) up to "S3200" speeds. No shipping silicon support this, however. Some prototype silicon has been demonstrated at "S1600" (roughly 1.6Gbit/sec). There is activity in the 1394 Trade Association to finalize the spec for S1600 and S3200 silicon.--Teener 20:40, 31 July 2006 (UTC)

RDMA

Anyone have an idea if Firewire is a reasonable approach to software RDMA, as compared with ethernet? It looks like it could have lower latency than ethernet, from bypassing the TCP stack, yet it's commodity hardware much cheaper than (e.g.) Infiniband. Is there a complex transaction setup? How does it deal with multiple nodes on the same bus--collision detection or what? Phr 07:23, 8 Jan 2005 (UTC)

FireWire "remote DMA" isn't a high-data-rate mechanism, because you can only send one 32-bit word (called a "quadlet") per transaction, and a transaction requires a packet in each direction. Bulk data, like data from cameras, is sent in longer packets. The "DMA" functions are used mostly to store into "device registers". In practice, what usually happens is that the sending end makes up a packet to store value X into address A, and on the receiving end, software notes that address A is being "stored into", and the appropriate code is called to take whatever action value X indicates. There's hardware support in OHCI controllers for storing into memory directly, but it is little used and can be turned off, so that software processes all such requests.

In retrospect, the whole "remote DMA" device register emulation thing was a bad idea; "functions" and "statuses", like SCSI, would have been simpler. A big problem with the "register" approach is that you must know the detailed "register" layout of something to talk to it. This replicates the driver problems of ISA and PCI bus devices. Fortunately, there are generic "register" layouts for many devices, like cameras, so there's some interoperability. Then, manufacturers like to add extra "registers" and make you load their custom drivers, limiting interoperability.

FireWire is really a local area network, like Ethernet, not a "bus". FireWire controllers look and work much like Ethernet controllers, with chains of incoming and outgoing buffers. On top of FireWire are other protocols; Ethernet, IP, SCSI, DCCAM (for still cameras), and iLink (for video). FireWire support code looks very much like LAN support code, with buffer queues and protocol stacks. It's called a "bus" for political reasons. But under the hood, it's a LAN.

Contention and discovery are handled by an amusingly complicated system designed to let smart and dumb devices play together. There's a "root node", a "cycle master", a "bus manager", and an "isochronous resource manager". Some nodes know how to do some of these functions, and some don't. At startup, or after any hot-plugging, all these roles are assigned. The end result is a tree, leading up to the root node, which is chosen somewhat randomly.

Unlike Ethernet, FireWire runs on somewhat fixed timetables. It's not TDMA or CDMA, though; all the nodes are active and help with arbitration. The basic cycle is 125 microseconds. Part of the cycle is reserved for "isochronous" traffic, which gets a fixed amount of time each cycle. Isochronous data is broadcast to all interested nodes. Asychronous data is sent to a specific device. Isochronous channels are reserved by using compare-and-swap operations on some data words in the "isochronous resource manager". In addition, isochronous senders are supposed to reserve bandwidth by updating the "bandwidth available" register at the "isochronous resource manager", again using compare and swap operations. The reservation system isn't enforced, and some implementations send isochronous traffic without actually reserving time for it, which means that the bus can be overscheduled.

One interesting omission from FireWire is shared device arbitration. You can plug two computers together with FireWire, and put, say, a camera or a disk drive on the same FireWire. But there's no defined way for the two computers to agree on who gets to talk to the device.

--Nagle 03:51, 10 March 2006 (UTC)


Re "one quadlet per transaction": Wrong. A transaction may transfer of up to 4096 bytes payload (1024 quadlets), depending on the datarate. Ste.Ri 13:36, 11 December 2006 (UTC)


I can't answer your question directly or authoritatively, here's what the FreeBSD firewire(4) manual page says:
    Up to 63 devices, including the host itself, can be attached to a
    firewire bus.  The root node is dynamically assigned with PHY device
    function.  Also, the other firewire bus specific parameters, e.g., node
    ID, cycle master, isochronous resource manager and bus manager, are
    dynamically assigned, after bus reset is initiated.  On firewire bus,
    every device is identified with EUI 64 address.
...so it seems to be some sort of centralized scheduling model. From looking at the driver, there appear to be hardware limitations on the number of simultaneous isochronous transfers that may be set up, but the driver is very difficult to understand without having the standard to compare. 18.26.0.18 23:06, 29 Jan 2005 (UTC)
    It sounds like a very good use of FireWire; but you'd have to do some timing 
    measurements to be sure. (I don't know what advantage ethernet would have 
    over FireWire in this case? Does Ethernet already support RDMA?) 

    Devices on the FireWire bus arbitrate for access to it. Each packet sent is repeated 
    to all nodes, but ignored by those to which it is not addressed. You can do RDMA 
    (as described in the article) with asynchronous transfers, similarly to a FireWire hard 
    drive--these types of transfers are acknowledged. 

    Configuration would be done by creating entries in each machine's configuration ROM. 
    The configuration ROM (not really a ROM, since it can be updated at any time) is a 
    reserved section of FireWire address space on each connected device used to advertise 
    it's services to other devices on the bus. On Mac OS X, you can do this from an application 
    without writing any kernel code.

Bus Power values

Can someone please look up what power is supplied on the FireWire bus ? How much can a FW device take, without violating the standard ? What voltage? What current ?

I tried myself to find this information, but failed.

Thanks, xerces8@butn.net (please notify me when this is added)

Apple's FireWire documentation says 24-25 volts, but this article says 45W and 30 volts! Which is correct? I'll try to dig in on this issue. The article needs a citation on that fact. --Charles Gaudette 23:49, 28 September 2006 (UTC)

USB 2.0

"Although USB2 claims to be capable of higher speeds (480Mbit/s), FireWire is, in practice, faster." sounds like a speculation of a FireWire fan. This piece needs to be expanded, as it sounds like personal opinion not like a fact. Given pure facts FireWire 400 at 400 Mbit/s and USB 2.0 at 480 Mbit/s (up to of course), using plain calculation it doesn't seem or give reasons why in practive FireWire 400 should be faster. This needs to be expanded

It's true, but yes, an explanation would be good. Njál 23:48, 6 April 2006 (UTC)

In any interconnect the raw data rate is only a first approximation of the useful data moved. Since USB is a master/slave bus, it requires the CPU to poll the drive and send read commands as data is available. None of this bandwidth is "useful" to the application. On the other hand, FW is a peer-to-peer bus with a direct mapped memory space, so the CPU can send a command to the disk drive that contains not only the read command, but also a list of buffer addresses. The drive can then move the data directly into the user buffers, only interrupting the CPU when the whole operation is complete ... furthermore, FW disk read commands can be chained together so that the drive can fetch its next command directly from CPU memory without an interruption for that, either. The result is that a decent FW400 disk drive sustains a good 37+ MByte/sec read rate, while you are lucky to get more than 25Mbyte/sec on USB2 High Speed. See a recent review at the Bare Feats site.--Michael Johas Teener 22:59, 31 July 2006 (UTC)

Honestly, why does so much of this page, which is about firewire, talk incessantly about USB? How about putting all this USB information on the USB page? Is this a reference site or a firewire evangelism nook?

I think that addressing the comparison of the two is perfectly suited for this page. Its a commonly asked question and the reason I visited this page in the first place. Please ingnore the comment above and keep up the good work.

OCHI

There's nothing about Open Host Controller Interface in this article seems like a bad thing to leave out. Dawhitfield 15:52, 3 April 2006 (UTC)dawhitfield

9-pin image

I see the image of a 9-pin connector was removed on the 14th Feb. Could someone upload a new version with all the appropriate GNU info? Having images of 4-pin and 6-pin connectors and not 9-pin gives the impression that the 9-pin's somehow less important. And I've always thought that that was a really useful set of images for users trying to figure out what was on their PC. Njál 23:43, 6 April 2006 (UTC)

booting from FireWire

I suggest a subsection: 

===Booting from FireWire===

under the section 

==Operating system support==

detailing which OSs will boot from a FireWire drive. OS X will. Can Windows? Njál 23:53, 6 April 2006 (UTC)


Come on now.. Wouldn't the advances of Firewire and its family 1394, 1394b, and 1394Ta be a real truth to its effectiveness?

I see no references to HDMI, and mostly fluff on usbs performance being better then firewire but no real proof.. No tests, no explaination of technology. All fluff. Seems like the article was a way to downplay the technology before even really giving its just due.

FireWire 400 devices bringing down the speed of FireWire 800 devices on a single FireWire 800 bus

This section of the "USB" article states the following:

"However unlike USB Hi-Speed systems which can change the speeds on each branch a 1394a device on a 1394b system requires all devices to fall to 1394a speeds."

The FireWire article, however, makes no mention of this. Can somebody qualified to address this please do so? If the above statement is true, I believe the FireWire article should mention it. However, if the above statement is fales, the USB article should be amended.

corrected by http://en.wikipedia.org/w/index.php?title=Universal_Serial_Bus&diff=93572479&oldid=93447728 Ste.Ri 13:27, 11 December 2006 (UTC)

Ethernet over Firewire

Windows and Linux CANNOT connect to each other as windows does NOT support ethernet over firewire. Windows supports TCP/IP over Firewire, without the Ethernet encapsulation. The Linux kernel driver eth1394 supports Ethernet over Firewire, which is TCP/IP encapsulated in ethernet.

Under section FireWire#Networking over FireWire, it states: "Due to unpopularity, Microsoft Windows Vista has removed support for networking over FireWire (source)", but farther down it's: "Microsoft Windows Vista will initially support 1394a, with 1394b support coming later in a service pack (source)". The microsoft.com link was updated in 2004, the news article was dated in 2006. Which is correct? - Democritus the Minor 23:02, 5 September 2006 (UTC)

Um, the second statement isn't about networking. So they're both correct. --Imroy 23:56, 5 September 2006 (UTC)
Linux' current eth1394 driver is—despite its name—an IPv4 over FireWire implementation. It is interoperable with Windows and OS X and has been so for a while, although not initially. Ste.Ri 13:05, 11 December 2006 (UTC)

Firewire Pinout

Does anybody feel up to the task of putting together a section on the firewire pinout? I'd suggest something along the lines of the DVI article. I've already made the Pinout diagram for illustration (Image:Image-FireWire-46_Connector_Pinout.svg). — Mobius 22:28, 5 August 2006 (UTC)

where is it?

Where is this terminal located on a CPU?--StitchPedia 23:07, 8 September 2006 (UTC)

No firewire in Windows Vista?

I've just reverted an anonymous user's changes[1] which claim that Windows Vista RC2 removed support for FireWire. The only source is a blog with absolutely no information. Is there anything to this claim, or just the bleating of clueless bloggers? --Imroy 10:27, 9 October 2006 (UTC)

Requested move

The following is a closed discussion of the proposal. Please do not modify it. Subsequent comments should be made in a new section on the talk page. No further edits should be made to this section.

The result of the proposal was no consensus to move, proposal withdrawn. FiggyBee 22:20, 10 December 2006 (UTC)

FireWire → IEEE 1394 interface — FireWire is Apple's proprietary name for the interface. While this is what I call it personally, it may just as well be under i.Link. It makes sense to put this article under the name of the standard. A parallel example here would be if IEEE 802.11 redirected to AirPort. I am listing it here because it is a fairly high-visibility article, and I want to get some discussion before I make the move. —INTRIGUEBLUE (talk|contribs) 21:23, 4 December 2006 (UTC)

Retracted. —INTRIGUEBLUE (talk|contribs) 22:08, 10 December 2006 (UTC)

Survey

Add  * '''Support'''  or  * '''Oppose'''  on a new line followed by a brief explanation, then sign your opinion using ~~~~.
  • Strongly Oppose- The article really should use the common name for something, regardless of whether or not it's technically correct. Your average Wiki reader isn't going to have any idea with IEEE 1394 is, but most people have at least heard of FireWire. --Commander Zulu 11:14, 5 December 2006 (UTC)
  • Support - The proper name is IEEE 1394, and FireWire will still redirect to it. --Maelwys 13:02, 6 December 2006 (UTC)
  • Oppose, Apple released usage of FireWire. And FW is the common name, unlike AirPort, which in any case is better known as WiFi. It'd be like renaming this i.Link if you want to compare it to AirPort. 132.205.93.204 04:42, 8 December 2006 (UTC)
Your "common name" argument stands, but I don't see that this article is in any way related to Apple beyond the role they played in its development and popularization. —INTRIGUEBLUE (talk|contribs) 05:04, 8 December 2006 (UTC)

My source for all of this is an article written in the late eighties, written by Teener. If this is not the case then it would be nice to have it acknowledged (by MT) and the name of this Apple employee who invented IEEE 1394 be made public. FrancisXBacon 15:13, 18 December 2006 (UTC)

Discussion

Add any additional comments:

I just noticed that the article refers to the interface almost exclusively as FireWire. I'm not sure if this should be changed in the event of a successful move vote - after all, IEEE 1394 is obviously a bit cumbersome. Gotta love the IEEE for their wild, original names for things. —INTRIGUEBLUE (talk|contribs) 20:43, 6 December 2006 (UTC)

The above discussion is preserved as an archive of the proposal. Please do not modify it. Subsequent comments should be made in a new section on this talk page. No further edits should be made to this section.

Origins of FW

I notice that this entry now has a revised description of how FireWire came to pass. My entry, which has been dropped, says that the first signs of this was the creation of a IEEE 1394 working party around 1987. Michael Teener was chair of this and AFAIK, Apple was not a member. A draft spec of a very lowspeed 1394 protocol was created, but industry support was not forthcoming. Teener tried to get his employer, Nat Semi, to develop it but they didn't. Around 1990 he went to work for Apple and after some on-again off-again attitudes they decided to develop it, and did the bulk of the work (though apparently Intel holds a patent). —Preceding unsigned comment added by FrancisXBacon (talk • contribs)

There is a print of presentation slides (presumably given by Teener) at [2] where the first page lists an IEEE Study group of 1986 at the first step toward IEEE 1394, and Apple is not mentioned until slide 5, or the 1998-1991 period. 68.163.237.124 04:28, 22 December 2006 (UTC)


is this an encyclopedia or an advertisement?

"all Apple, Dell and Sony laptop computers currently produced..." So WHAT?

How about: "most if not all laptop computers currently produced..."

How many Acer, HP/Compaq, Lenovo, Toshiba, Fujitsu models CURRENTLY produced do NOT have a 1394 port?? Why shill for A/D/S? —Preceding unsigned comment added by 66.245.32.197 (talk • contribs) 12:14, 7 November 2006

I just purchased a brand new Dell laptop, and there is no Firewire port...sooooo, yeah, incorrect info. —Preceding unsigned comment added by 70.41.46.139 (talk • contribs)

I agree.

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:IEEE_1394/Archive_2006&oldid=441909382"