How FireWire came to market and ultimately fell out of favor
arstechnica.com
arstechnica.com
For all of you who embrace the "fail fast" mindset, keep this story close as a reminder that some mistakes are irrevocable. This was one decision, reversed after 30 days.
A read-through on some paperwork, a couple of curt refusals, double check to confirm and get clarification, maybe a phone call or two, and call it a day.
Apple can be aggressive about its tech today (such as Lightning and Thunderbolt; anyone know what they charge for those?), but back then they were much more of a niche player.
My guess is Intel probably would have backed USB over Firewire regardless since it had a stake in USB.
The irony is, USB would probably have failed without Apple.
The fact is that Intel has repeatedly chosen its own technology to promote, and until recently it had the market power to force everyone else to follow suit.
This doesn't seem to be correct. While I can't find anything with a simple search, the thunderbolt technology website is copyrighted by Intel, and Wikipedia directly attributes the development to Intel.
Iirc apple was mostly a first adapter to thunderbolt.
https://www.engadget.com/2009/09/26/exclusive-apple-dictated...
Did anyone say that Jobs never made any blunders? Does anyone think that there it any person alive that didn't make blunders?
I was always curious if some manufacturers were not implementing the full spec here (maybe because by this time according to the article FireWire was already on its last legs), or if this was due to flaws in the spec that left certain things optional or something and that ruined interoperability.
Note the recent problems where the Macbook Pro refuses to use Thunderbolt 3 devices with a TPS65982 chipset, and requires TI's TPS65983 chipset.
You didn't run into trouble with USB because by that time all your USB ports were coming straight from the Intel southbridge. Even if Intel's host controller implementation had issues, it would have been the device maker's problem to work around them since Intel's market share was so large.
No modern peripheral interconnect is simple enough for host interfaces to be judged on a mere pass/fail basis. The cheap chips almost always find a way to suck, whether it's obscure like FireWire or ubiquitous like gigabit Ethernet.
I'm not sure if Apple was the first company to do this; today everyone has wall chargers that output a single USB port, but I don't remember it existing before then. Hell, I'm not sure if there were any devices TO charge over USB when the iPod first came out -- those little SanDisk flash MP3 players, and I'm sure the bigger Archos hard-disk based MP3 players must have had their own chargers, there's no way they charged over USB.
I'm so happy that the world has gone in this direction, where I can use your Samsung USB charger to charge my Sony phone, or whatever. And Apple has still stick with the same charging brick style where you can flip out the prongs or use a longer cable. (not sure how it is now with USB C though).
But that firewire power brick still makes me nostalgic, a simple design that felt so elegant 15 years ago, and still does to this day.
But then, I only visit the states every once in a while, and usually run British-style or Australian connectors.
* https://qmart.pk/image/cache/Accessories/AppleAccessories%20...
FW800 gets close to 80MB/sec, which is really as much as I need for my backup/archiving needs. And the daisy-chaining is just awesome.
For use cases where reliable low-latency transport is required (i.e., Firewire's main strength), what could possibly be meant by "packets arrive way before it's needed"?
I deal with upgrading a lot of industrial electronics, and have to answer this question frequently: people are concerned about replacing Modbus RTU and similar setups with modern protocols: "But it's not real time!", "It's too high-level!" "Consumer or office network gear can't possibly work here!"
No, it can. It's freaking gigabit Ethernet. You had 9600 baud before and were happy to read out a few tags a second, now we can stream multiple sensors at a multiple kilohertz each, or transfer the entire image of your old PLC in a couple packets.
There was a brief time when Firewire was way faster than everything else, but it didn't keep iterating like USB did. Honestly, that's probably a more accurate reason why it died. Plus the decision to use separate connectors for 400 and 800: if they had done like USB and allowed Firewire mice at 50 Mbps to connect to the same port as 800 Mbps camcorders, and built Firewire 1600 and 3200, it might still be around.
From the article:
> And FireWire had its own micro-controller, so it was unaffected by fluctuations in CPU load.
This is still an important distinction for, say, an USB soundcard vs. a Firewire soundcard.
But now the machine has much more intelligence, so it shuts itself off quicker. And where they needed to check the "low latency" and "realtime" boxes in the 90s to get adequate performance, now any bus (like Ethernet, or you can stick Ethercat or Powerlink on top if you need realtime) is so much faster that it doesn't matter.
It's like someone saying they need their Enterprise-grade 15k RPM SCSI drives in their server...when they just need an ordinary consumer SATAIII SSD.
Economies of scale are huge in tech. Stuff that reaches billions of people is often more performant than specialized gear.
But at the end of the day, cable internet ended up being so damn fast it didn't matter. DSL providers couldn't bump the speed fast enough, telcos have to run FTTH to compete with cable, the infrastructure takes too long to arrive, and even with guaranteed bandwidth to the CO, your uplink will be oversubscribed anyway.
I type on gigabit xfinity docsis3.1 that speedtests at 250Mbps.....
That sounds like a not-necessarily-low-latency-yet-still-realtime problem for which the original low latency solution was replaced with a non-low-latency solution that still hit the realtime scheduling deadlines.
It seems as more and more big players put money into such solutions, the bonefide low-latency realtime problem space shrinks to a smaller mindshare. I'm not sure if that mindshare is fitting or insufficiently small, but the shift is palpable and does have drawbacks.
So if you know about the problem of receiving and sending audio fast enough so that the human on the other end doesn't hear the result as an echo, you read this article between the lines and go, "oh, that's what the microcontroller and isochrony are doing in there." If you're not, however, there's nothing explicitly stated in the article that informs the reader that this problem space still exists and can't be solved by throwing AI/4G/The Cloud at it.
https://en.wikipedia.org/wiki/Time-Sensitive_Networking
This is a real-time standard for ethernet that lets you reserve slots for time sensitive information.
It's primarily being driven by the automotive guys who want to be able to wire up 4 displays, 12 speakers, and a video player for an in-car entertainment system.
Before TSN, it was AVB (audio-video bridging) and, while people networking things like gigantic stadium shows loved it, it didn't have enough volume to be popular.
With automotive behind it, it's going to get cheap and ubiquitous really quickly.
I had a nice chat with a customer rep from a big microcontroller company at a trade show where we talked about how in a couple years the 3 rows of "vendor-specific" industrial networking companies are going to be GONE.
And they don't even realize they're about to get run over.
Apparently Harman-Kardon: http://www.semiwiki.com/forum/content/4947-4-design-tips-avb...
Now imagine the platform was poorly designed so it fires off that IRQ once for each track. You're re-tracking the drums since the drummer you're recording couldn't work with a click track. Let's say conservatively, you've got 2 overhead condensers, some ambient mic, and an SM57 at the kick. He's working against the guitarist and bass tracks along with some scratch vox. Depending on how you're patching and tracks are configured, you could easily have 12 tracks all firing a "hey I've got data for you! CONSUME IT!".
Each one of those interrupts is expensive, mind you. I mean not so much now, where we can shield processes on 16-core HT Xeons and basically dedicate a whole core to solely dealing with the interrupts. But imagine the early 2000s where you had P3 single-core's running at 600 MHzs. Each IRQ will context switch, which means whatever active process that was scheduled now gets bumped. The first IRQ is serviced and that process gets back to work and maybe it doesn't even have time to restore it's execution context before ANOTHER dang IRQ comes in. Like I say, not really a problem these days, but not so long ago....
When you say "platform", are you talking about the Firewire device driver?
57 resonant peak is at 200 Hz with steep rolloff below. It will sound like a bedroom recording no matter what you do with IRQs and DMAs.
Naturally this extra speed and solidness made for a better experience when booting from external media. One my favorite features of my 4th gen 20GB iPod was the ability to keep an OS X partition on it that I could boot from via FireWire. It worked great — well enough to get work done with, even on low power machines like 400Mhz G3 iMacs — and it saved me several times.
Also, I always loved that little click when plugging in FW400 connectors (can't remember if 800 had this feature). That little bit of tactile confirmation that you've plugged your device in properly is something I wish USB had.
They were commonly used back then to add modems, network adapters and even hard drives.
Plus, I always thought the logo was cooler. :)
The major problem with FireWire, shared with Thunderbolt, is that it offers DMA to external devices: https://en.wikipedia.org/wiki/DMA_attack
Did eSATA also lose to USB? I don't think it has the DMA problem.
USB 3.0 is what you actually meant, since it finally added Firewire-like device-initiated DMA.
People that specifically needed their drives to be both fast and external moved to internal drives? I don't understand.
It's interesting to see an article that explains why it died.
Is USB-C by all measures now superior to FireWire? Or are we still paying for Jobs' mistake?
But on video I Remember the different names being bing used being confusing. And while all macs had it some pcs didn't. With USB being ubiquitous and USB 2 being good enough when it finally showed up.
Somewhat oddly mac was a big pusher of USB as that's what the original iMac used.
Had intel put it in its chipsets...
It looks like it was about the same time
Let's also hear your whines about how the C64 didn't have protected memory and the Apple ][ was so easy to hack because you could open the lid and poke around with a logic probe.