21–30 of 102 posts
Earlier quoted context omitted.
USB-C is just a connector. Some of the devices using that connector only support USB 2.0 signaling over that connector, so USB-C does not imply complete superiority over FireWire.
What protocols are commonly implemented by Intel host chipsets which support the USB-C connector, e.g. on a 2017 laptop?
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.
Earlier quoted context omitted.
USB-C is just a connector. Some of the devices using that connector only support USB 2.0 signaling over that connector, so USB-C does not imply complete superiority over FireWire.
What protocols are commonly implemented by Intel host chipsets which support the USB-C connector, e.g. on a 2017 laptop?
> Speeds across networks of all sizes are now so high that there's also little need for something like FireWire. "The packets can arrive way before it's needed, because it's so fast," Sirkin noted. "So you don't need to worry about being synchronous any more." 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'…
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.
Earlier quoted context omitted.
What protocols are commonly implemented by Intel host chipsets which support the USB-C connector, e.g. on a 2017 laptop?
Thunderbolt 3, DisplayPort, USB 1.1-3.1, FireWire, HDMI, MHL, analog audio, power delivery
> Speeds across networks of all sizes are now so high that there's also little need for something like FireWire. "The packets can arrive way before it's needed, because it's so fast," Sirkin noted. "So you don't need to worry about being synchronous any more." 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'…
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....
I've used FireWire to connect external disks (verdict: as stable as eSATA, much better than USB2) and to pull video from a cable set-top-box (verdict: the cable box was crappy; no problems directly attributable to the FireWire connection.) The major problem with FireWire, shared with Thunderbolt, is that it offers DMA to external devices: https://en.wikipedia.org/wiki/DMA_attack
Offering DMA to devices can be good actually if you care about performance, and the security issues can be eliminated with a properly set up IOMMU in the mix.
> Speeds across networks of all sizes are now so high that there's also little need for something like FireWire. "The packets can arrive way before it's needed, because it's so fast," Sirkin noted. "So you don't need to worry about being synchronous any more." 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'…
I think it's being compared to something like 12 Mbps USB 1.1: Firewire is just so much faster that it doesn't matter. 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!" N…
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.
> After being informed of IBM's hundreds of millions in yearly patent revenue, CEO Steve Jobs authorized a change in FireWire's licensing policy. Apple would now charge a fee of $1 per port. (So if a device has two ports, that's $2 per unit.)...Intel sent its CTO to talk to Jobs about the change, but the meeting went badly. Intel decided to withdraw its support for FireWire—to pull the plug on efforts to build FireWi…