Slashdot Mirror
Clash of the Titans Over USB 3.0 Specification Process
Ian Lamont writes "Nvidia and other chip designers are accusing Intel of 'illegally restraining trade' in a dispute over the USB 3.0 specification. The dispute has prompted Nvidia, AMD, Via, and SiS to establish a rival standard for the USB 3.0 host controller. An Intel spokesman denies the company is making the USB specification, or that USB 3.0 'borrows technology heavily' from the PCI Special Interests group. He does, however, say that Intel won't release an unfinished Intel host controller spec until it's ready, as it would lead to incompatible hardware."
This is a replay of the OHCI/UHCI host controller interface standards of original USB.
This does NOT at all effect users, only driver writers.
What is being forked is the USB driver interface, and does not effect device compatibility at all.
As mentioned above, there were two driver interfaces for the original USB standard, and the only people who knew were driver writers and nerds compiling their own custom kernel.
This is blown way out of proportion, and doesn't effect 99.999% of us. Nothing to see here, move along....
Blessed are the pessimists, for they have made backups.
You're wrong. You are basically remembering something that's been fixed and settled a decade ago. Good job on being out of date by a decade.
The entire royalty is something like $0.25 per device, Apple only gets a portion of that.
The cost is in the smarts, each device requires a more complicated controller and an additional chip.
This isn't about competing USB 3 standards -- the spec is being designed by a group, and there is only one. This is about the design of the hardware used to implement a host controller that can comply with the spec. This is something that any company can develop if they want to, but since Intel is going to license their design of the host controller for free, most companies will just wait for that design and use it to implement USB 3.
..wayne..
FireWire requires an actual IO controller, where USB 2 relies on the CPU and the driver.
In short -- FireWire is faster and requires far less load on the target machine. The downside is the initial cost is higher. I find it pays for itself pretty quick.
- oZ
// i am here.
Also, the royalties are not in effect any longer...
I'm starting to think GNU is the problem with "GNU/Linux" these days.
But according to the USB spec both behaviours are correct since the device can't make any assumptions about what overheads exist on the host.
I can't find the reference to device visible differences between UHCI and OHIC and in any case it was a very rare case. I did find this presentation by Intel that shows OHCI and UHCI performing almost identically despite the fact that OHCI controllers basically do the USB protocol in software and UHCI is just a bus master DMA engine attached to a serial interface with the protocol is done in software.
http://www.usb.org/developers/presentations/pres0598/bulkperf.ppt
With USB 2.0 there was a push to a unified host controller spec called EHCI. From what I can tell this spat means that there will possibly be two rival host controller specs because Intel haven't published their spec in time for other people to implement it. But I don't think that will fork the wire protocol, I think it just means that OSs will need to have two new host controller like USB 1.0 drivers rather than one like USB 2.0.
You could argue that UHCI was a good thing since it uses less hardware and performs about the same.
Incidentally Wikipedia writes this up based on the "Good open standards vs vile proprietary standards" meme, which seems a bit unfair. Both OHCI and UHCI are based on published specifications which are freely available. I don't know if you need to pay a license fee to implement either or both of them - I actually think you don't since USB was successful because you didn't need to pay a per port fee when it was introduced, unlike Firewire.
http://en.wikipedia.org/wiki/OHCI
The difference seems to me more like a software engineer view (Microsoft want to do it all in hardware like OHCI) of the world vs a hardware engineer view of the world (Intel say do it all in software with UHCI)
echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
How is this modded interesting, all the geeks know that FW 400 is still faster than USB 2.0 because 480mbps is theoretical and not an actual constant transfer speed like with FW400. Firewire is processor independent as well since it has its own controller whereas the main CPU is used to control USB 2, that means its transfer rate is dependent on system performance. Everything else in your post isn't bollocks though.
Jonathanjk.com
Great way to stay on the sidelines of understanding. Yes, USB 2.0 is "faster" than Firewire on paper. However, 2.0's max/burst speed of 480Mbit/s is very different from it's average speed (about 240Mbit/s), and substantially lower than Firewire's sustained speed. It's a side effect of something that relies on the host to do the heavy lifting vs a device that handles it's own heavy lifting. Not looking forward to similar crap with USB 3.0, not to mention the continuance of shitastic driver support I've always seen from USB vs Firewire.
IIRC, Firewire controllers need to be smarter than USB controllers because they might not be hooked up to a PC. For instance, your video camera might go straight to a recording deck, or some other electronic doodad. So the firewire controllers were designed to offload a lot more of the protocol to move stuff around, which made it easier to design systems. Of course this was done back before embedded controllers running Linux (and its USB stack) became cheap as dirt.
Firewire's main advantage now is the fact that it is a point to point mechanism, not a bus. USB suffers because every so often the host must interrupt things to discover new devices. This can slow down large block transfers quite a bit.
Remember, You are unique...just like everyone else.