6 ms·

> 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,

> 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's needed"?

LeifCarrotson 9y ago
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!" 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.
- jancsika 9y ago
  I'm not sure I understand. Are you replacing hardware for clients who think they need low-latency realtime delivery of data, or for clients who actually need to hit low-latency delivery deadlines? 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.
  - LeifCarrotson 9y ago
    They need to get data in like... 3 seconds... So the operators can shut the machine down if something goes wrong. 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.
    - rconti 9y ago
      This reminds me of cable internet vs DSL. I was such a DSL partisan. Cable's bullshit, you're sharing speeds with your whole neighborhood, no guaranteed bandwidth, yadda yadda yadda. 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.....
    - jancsika 9y ago
      > They need to get data in like... 3 seconds... So the operators can shut the machine down if something goes wrong. 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.
- bsder 9y ago
  You might want to look into Time Sensitive Networking. https://en.wikipedia.org/wiki/Time-Sensitive_Networking 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.
  - LeifCarrotson 9y ago
    That sounds a lot like Ethercat, honestly. And I am more in automotive industrial stuff than the protocols on the car, which - while technically standardized - are usually a bit vendor-specific.
    - bsder 9y ago
      TSN works excellently for industrial networking. 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.
  - jancsika 9y ago
    Does anyone use it at the moment?
    - bsder 9y ago
      Define "anyone". Apparently Harman-Kardon: http://www.semiwiki.com/forum/content/4947-4-design-tips-avb-car-infotainment.html http://www.semiwiki.com/forum/content/4947-4-design-tips-avb...
  - lukeh 9y ago
    Amusingly enough, the audio data packing in AVB/TSN comes from FireWire via IEC 61883-6. AVB seems to be on its way to irrelevance in the pro audio/video world in favor of AES67/SMPTE 2110, which are Layer 3. Requiring switch support didn't help its adoption as it created the classic chicken/egg vendor adoption problem.
iheartmemcache 9y ago
At least on Linux, you can easily be barraged by tons of IRQs from your FireWire device. Every time some data comes in from your device (let's say some music production platform) it's going to DMA that data right on over via a PCI lane or 4 then fire off an interrupt to inform your OS "hey hey got some new information for ya!". 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....
- jancsika 9y ago
  This is really interesting. When you say "platform", are you talking about the Firewire device driver?
- crmd 9y ago
  >SM57 at the kick 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.

LeifCarrotson 9y ago

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!" 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.

jancsika 9y ago
I'm not sure I understand. Are you replacing hardware for clients who think they need low-latency realtime delivery of data, or for clients who actually need to hit low-latency delivery deadlines? 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.
- LeifCarrotson 9y ago
  They need to get data in like... 3 seconds... So the operators can shut the machine down if something goes wrong. 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.
  - rconti 9y ago
    This reminds me of cable internet vs DSL. I was such a DSL partisan. Cable's bullshit, you're sharing speeds with your whole neighborhood, no guaranteed bandwidth, yadda yadda yadda. 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.....
  - jancsika 9y ago
    > They need to get data in like... 3 seconds... So the operators can shut the machine down if something goes wrong. 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.
bsder 9y ago
You might want to look into Time Sensitive Networking. https://en.wikipedia.org/wiki/Time-Sensitive_Networking 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.
- LeifCarrotson 9y ago
  That sounds a lot like Ethercat, honestly. And I am more in automotive industrial stuff than the protocols on the car, which - while technically standardized - are usually a bit vendor-specific.
  - bsder 9y ago
    TSN works excellently for industrial networking. 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.
- jancsika 9y ago
  Does anyone use it at the moment?
  - bsder 9y ago
    Define "anyone". Apparently Harman-Kardon: http://www.semiwiki.com/forum/content/4947-4-design-tips-avb-car-infotainment.html http://www.semiwiki.com/forum/content/4947-4-design-tips-avb...
- lukeh 9y ago
  Amusingly enough, the audio data packing in AVB/TSN comes from FireWire via IEC 61883-6. AVB seems to be on its way to irrelevance in the pro audio/video world in favor of AES67/SMPTE 2110, which are Layer 3. Requiring switch support didn't help its adoption as it created the classic chicken/egg vendor adoption problem.

iheartmemcache 9y ago

At least on Linux, you can easily be barraged by tons of IRQs from your FireWire device. Every time some data comes in from your device (let's say some music production platform) it's going to DMA that data right on over via a PCI lane or 4 then fire off an interrupt to inform your OS "hey hey got some new information for ya!". 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....

jancsika 9y ago
This is really interesting. When you say "platform", are you talking about the Firewire device driver?
crmd 9y ago
>SM57 at the kick 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.