802.1Q is not TSN. And TSN is not just 802.1Qbv. And TSN 802.1Qbu is a nice backwards compatible QoS mechanism without any disadvantages. And mixing IT traffic with OT in the same network is not a TSN issue: You can mix IT with OT without TSN, and you can use TSN without mixing IT with OT. Video is getting a lot of things fundamentally wrong.
This answer should be voted up. I could not see any point in his list that shows that this is "dangerous". I would agree that TSN might not make sense in a lot of use-cases, but at least in vehicles it really helps!
So I come from the audio industry, and I'm happy to see what other uses TSN has besides audio. I agree with some of your points, that in industrial automation, there might be cases that will not have a benefit from the added complexity that TSN brings, but also TSN has so *many* uses (eg realtime audio and video) that it won't be going away, it's going to be a fact of life. also IEEE802.1CB specifies redundancy, ring networks are supported, multiple paths are supported
The scheduler will be some AI like Bard in cooperation with quamtum computing; it´s beeing build, it just takes time! But yes, I agree in one point with you - linking IT to OT - I don´t see the reason why either to risk OT to hacker!
The argumentation is different if someone wants to have a virtualized embedded cloud hosting many hard RT, real-time and soft-time functions on few computers. Yes, the methodology, design tools and SW/HW components are important for safety-/mission-/time-critical functions. TSN standard makes more sense in cars (Nx100M of switches, >1Billions endpoints), eventually in the edge computing/factory automation. In the fieldbus domain it can add value to some of the existing industrial Ethernet standards by providing real-time capabilities.
802.1Q is not TSN.
And TSN is not just 802.1Qbv.
And TSN 802.1Qbu is a nice backwards compatible QoS mechanism without any disadvantages.
And mixing IT traffic with OT in the same network is not a TSN issue: You can mix IT with OT without TSN, and you can use TSN without mixing IT with OT.
Video is getting a lot of things fundamentally wrong.
This answer should be voted up. I could not see any point in his list that shows that this is "dangerous".
I would agree that TSN might not make sense in a lot of use-cases, but at least in vehicles it really helps!
Agreed!
John has forgotten more than most people have ever known, I think he gets the benefit of the doubt
Agree with you John.
Custom machines with networks that change constantly is not the place for rigid semi fancy silliness.
So I come from the audio industry, and I'm happy to see what other uses TSN has besides audio. I agree with some of your points, that in industrial automation, there might be cases that will not have a benefit from the added complexity that TSN brings, but also TSN has so *many* uses (eg realtime audio and video) that it won't be going away, it's going to be a fact of life. also IEEE802.1CB specifies redundancy, ring networks are supported, multiple paths are supported
I like the way you critic, thank you, you gave much information!
The scheduler will be some AI like Bard in cooperation with quamtum computing; it´s beeing build, it just takes time! But yes, I agree in one point with you - linking IT to OT - I don´t see the reason why either to risk OT to hacker!
The argumentation is different if someone wants to have a virtualized embedded cloud hosting many hard RT, real-time and soft-time functions on few computers. Yes, the methodology, design tools and SW/HW components are important for safety-/mission-/time-critical functions.
TSN standard makes more sense in cars (Nx100M of switches, >1Billions endpoints), eventually in the edge computing/factory automation. In the fieldbus domain it can add value to some of the existing industrial Ethernet standards by providing real-time capabilities.
Sitting on the fence again I see John! 🤣
Great! Totally agreed!
Good points
Listen to this man.