Slashdot Mirror
Ethernet Consortia Wants To Unlock a More Time-Sensitive Network (networkworld.com)
Does Ethernet need new features like "stream reservation" and time synchronization to make sure time-sensitive data isn't delayed on the network? coondoggie quotes Network World: The demand from Internet of Things, automotive networking and video applications are driving changes to Ethernet technology that will make it more time-sensitive. Key to those changes are a number of developing standards but also a push this week from the University of New Hampshire InterOperability Laboratory to set up three new industry specific Ethernet Time-Sensitive Networking consortiums -- Automotive Networking, Industrial Networking, and ProAV Networking aimed at developing deterministic performance within standard Ethernet for real-time, mission critical applications. "Standards-based precise time, guaranteed bandwidth, and guaranteed worst-case latency in a converged Ethernet network is a game-changer to many industries," said Bob Noseworthy, Chief Engineer, UNH-IOL.
The article also acknowledges the work of the Avnu Alliance, which is also trying to build an ecosystem of "low-latency, time-synchronized, highly reliable synchronized networked devices using open standards through certification."
The article also acknowledges the work of the Avnu Alliance, which is also trying to build an ecosystem of "low-latency, time-synchronized, highly reliable synchronized networked devices using open standards through certification."
> > We need fixed-bandwidth, low-latency
> so ... UDP
UDP provides neither fixed bandwidth nor low latency.
UDP, as opposed to TCP, simply says that a packet is processed whether or not some previous packet went missing, and no mechanism is provided for recovering lost packets. It's useful when you don't want to resend lost packets because they'll be outdated anyway, such as VoIP.
Referring to TFS:
--
Standards-based precise time, guaranteed bandwidth, and guaranteed worst-case latency
--
UDP doesn't do any of that either.
First of all, please define "we"... I'd love to identify an industry where this makes sense ... I'm not seeing it.
I developed real-time low latency, low jitter broadcast video codec hardware for years. The codecs I developed were layer 1-7 codecs meaning that I counted clock cycles inside the FPGA implementation of the Ethernet MAC as I was designing the compression mechanism to reduce encoding and decoding latency to ridiculously low amounts. I also worked as a protocol developer at one of the largest video conferencing companies in the world where I spent a year on clock synchronization through RTP and RTCP. I currently am a network engineer (I sold out for the money) where I regularly am called in for designing end-to-end real-time QoS from app, through nic to switch etc... I focus on all layers, not just the network or app.
I have never imagined a scenario where this technology would be useful.
You don't need NTP or PTP for clock synchronization in two way communication. Only when there is a single streaming device. If an industry thinks they need this, they probably are trying to solve a problem with the algorithms at the physical layer. That said, Ethernet is absolutely the dumbest technology to use for these things.
1) Ethernet is attractive because of cheap cable and you can buy it anywhere.
2) Ethernet won the network war because it was cheap and because.... nope that's it. It was cheap but mostly crappy. To this day, with the exception of things like TRILL and ACI type networking, we treat all Ethernet networking as a bunch of coax cabled plugged in together. And even then, the clients generally don't talk to the switches. It's a spray and pray protocol.
3) Real-time standards on Ethernet requiring upgrades to the networking switches are extremely expensive. This is contrary to the "keep it cheap" mentality of Ethernet. Everything that makes this idea attractive goes to hell the moment you realize that deterministic latency within an Ethernet ASIC requires a whole new ASIC to achieve TDM like behavior. Also consider the logic required to design time-slots into something like Ethernet. Every packet before being sent will have to be calculated for "streaming time" and possibly delayed because the TDM packet may have to transmit in the middle of it's "slot".
4) Ethernet is layer-2, it's local premises only and has almost no possible value because even on local premise, layer-2 doesn't scale. If you add it to TRILL, what in the name of hell are you really trying to accomplish?
Let's consider automotive applications...
Fix the f-ing problem don't perpetuate CANBUS nonsense for no reason. There is absolutely not a single clock in the entire vehicle that requires better resolution than can be had from NTP. In addition, industrial ethernet has to be the dumbest frigging idea in the history of man. CANBUS was great when there were a handful of systems in the car and SoCs were not practical. These days, Atmel, Microchip, etc... can ship $2 automotive grade chips with pretty much any physical interface on them. CANBUS is basically crap by modern standards. Consider BMW whose entire in car experience is buggier than all shit because they insist on sticking with CANBUS bullshit. Make a new CANBUS alternative... quit trying to use Ethernet in the car... it is now and always will be the wrong choice. Automotive must be the absolute last place Ethernet has application.
Industrial networking...
This one is easy. From lots of experience in this case... Industrial Ethernet is absolutely shit. If you're looking for a replacement for RS-485 networking, this isn't it. In addition, this kinky CANBUS over Ethernet thing is just a disaster waiting to happen. I was working in a paper mill and asking "Why are you replacing RS-485 with Ethernet?" and the answer was simple... "Cisco told us it was better". There are cases like bottle inspection plants where higher speed could be useful but if you're de