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."
I mean ISO 17458-1 to 5.
FlexRay supports high data rates, up to 10 Mbit/s, explicitly supports both star and "party line" bus topologies, and can have two independent data channels for fault-tolerance (communication can continue with reduced bandwidth if one channel is inoperative). The bus operates on a time cycle, divided into two parts: the static segment and the dynamic segment. The static segment is preallocated into slices for individual communication types, providing a stronger real-time guarantee than its predecessor CAN. The dynamic segment operates more like CAN, with nodes taking control of the bus as available, allowing event-triggered behavior.
Dear Internet of Things,
First, fix your damned security problems. Then we'll talk about your "demands".
Sincerely,
The rest of the internet
Irony: Agile development has too much intertia to be abandoned now.
Because of the multitude of fuckers that'll simply abuse it by releasing 'get your internet faster' programs which'll blanket-prioritise every fucking thing.
It's about time - I keep running into issues with my IoT botnets, car overrides, and industrial process control malware where I just can't guarantee that I can get into these hideously insecure systems on a fixed time budget.
This is a serious concern, because when I can only deliver 500,000 insecure baby monitors to my Russian masters instead of the 800,000 they demanded, that's a polonium-210 desert!
(Seriously, this is actually a real issue that needs to be fixed- you want real-time ethernet for some things like you want a real-time kernel, but I can't help picturing this as working on how reliably you can get across a flaming bridge).
Networks aren't deterministic, so any protocol has to handle lost and delayed frames anyway. There is very little benefit to the complexity of low level traffic management, compared to using a simpler design and just adding more bandwidth. The internet is a "dumb network, smart edge" design, and it left "smarter" network designs in the dust for a reason.
It's the wrong layer to do "stream reservations" or any such kind of prioritising. Ethernet is supposed to deliver bits and frames as-is, managing buffers or the order of packets belongs to a higher layer. Such a layering violation results in no end of bloat and complexity. Complexity = errors.
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
"Consortia" is plural. So Consortia agrees with "want", not "wants".
Even worse, the original submission was correct, so you went out of your way to make it incorrect. That takes dedication to bad English.
The real "Libtards" are the Libertarians!
Yes, but they aren't reinventing it. It's doing things like providing minimum jitter for PTP packets.
Ethernet works well if you have over-provisioning. It is simple, almost zero-configuration, robust and reliable. This really bad idea would destroy all these characteristics. Why some (really bad) engineers cannot stay the hell away from things that work well is beyond me.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
But this is a better wheel, honest.
We need fixed latency low overhead transfers. Open a pipe and just feed data into it. If the network has the bandwidth it will open a channel through the network, all the switches and routers along the route would dedicate a time slice to that exact pipe.
If you want token ring, you know where to find it. Ethernet is not that. If you want that, you're far better off just reinvigorating a token ring standard and having at it.
I think there's a Van Jacobsen article about that (;-))
davecb@spamcop.net
Why re-invent the wheel? Dump ethernet and convert everything over to token ring.
btw. Give me a ring when you finally dump token ring and convert everything over to ethernet.
Essentially it means your socket is guaranteed at least 1 packet every n time units. Back in '01 I worked for a startup that had a wireless chip with isochronous features. I wrote the device driver and trust me, when you have more than 1 isochronous stream it can get pretty hairy to ensure both stream's needs are met.
The hardware worked, but pulled too much power. They ran out of money before they could so another chip spin. Kinda sad, it was pretty impressive for the time.
Let me get this straight. the ultimate destruction of the net is to be accellerated by giving the Internet of Things top priority? I realize that the world has gone batshit insane, but this is like giving Pedophiles guaranteed and first access to your children. Sorry honey, but Jerry Sandusky need to see little Timmy for personal hygeine lessons before we can give him breakfast.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
The IETF has done this before. ST-II, documented in RFC1190. Technically it is IPv5. I documented an even better protocol, at the link layer, in RFC2549.
I recall a quote that is perhaps falsely attributed to Henry Ford and it's something like, "If I had asked people what they wanted they would have said a faster horse." Ethernet does what it does because of it was made within the confines of the needs of a particular base of users. This is a different need and instead of creating a "faster horse" that might break the standard, cause incompatibilities, and other problems I believe they should simply start over with something new, a spec that wouldn't try to fit in the confines that may no longer apply.
I think that if they want to extend a standard to get a time sensitive network then they should look at something besides Ethernet. Firewire comes to mind, it's a standard that had time sensitivity from the start. Other possible standards could be USB-C, PCIe/ThunderBolt, or even extending some A/V protocol like DisplayPort or HDMI. I recall a certain protocol used in aircraft for sending critical data but the name escapes me at the moment, use that.
Maybe "faster horse" isn't the right analogy but instead call it a "camel", a horse designed by committee.
I am armed because I am free. I am free because I am armed.
There already are packet switching tech with ability to "handle both traditional high-throughput data traffic, and real-time, low-latency content such as voice and video." call ATM.
To fix Ethernet's high jitter delivery, the frame size need to be small and fixed. Doing so it will not longer be Ethernet.
If we keep the 64-1500byte Ethernet frame, frame delay will be variable and long, real time traffic cannot be guaranteed.
Why reinvent a square wheel if all problems has been tackled by ATM?
More like TDMA
> > 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.
> No it is not enough.
> Some application need absolute guaranteed (provable) latency,
> use static bandwidth allocations, make the switches ensure that
> the endpoints respect that allocation even in case of failures, etc.
> For SAFETY.
In that case, they need their own dedicated network. The public internet cannot guarantee a packet gets from Point A to Point B, let alone gets there in a specified time. All this does is provide an excuse to throttle "less important traffic", i.e. any website that doesn't pay greedy ISPs for higher priority.
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Dear EditorDavid:
If you're going to claim to be an actual editor, it would behoove you to learn the basics of English grammar. The rule is: one actor wants, multiple actors want.
In this case, the word "consortia" is plural in form, so they "want." It's subtle, I know ... but, if you'd prefer that people who care about language and communications (you know - writers, professional editors, and educated readers) not laugh and point when your byline appears as the editor of stories posted to slushdot, you really should learn and apply that rule.
Just as importantly, your headline claims that it's " Ethernet consortia" that are expressing this desire, whereas the body of the article makes it clear that it's actually the New Hampshire InterOperability Laboratory that wants this, since it's the party that's trying to push for it. So, the headline is not only grammatically incorrect, it's factually challenged, as well.
Welcome to Slashdot ...
Check out my novel.
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
Jeez, and I was just clicking into this article to post a sarcastic remark that ethernet was finally coming full circle from beatng out ATM, to becoming ATM, just like IDE/ATA became SCSI and USB is becoming firewire. Now I find I've been totally out-bus-protocol-geeked. Thanks for the interesting read.
Someone had to do it.
The problem is you can't just add more bandwidth.Cheap networking is 1Gbit now, but if your streaming needs are starting to chew up a significant proportion of that, it's no longer an option. This is especially so when your devices may be embedded and can't actually handle full Gbit networking.
So you may be able to do a couple of 100Mbit streams (not hard - Blu-Ray disc streams average 25-40Mbps and peak to 100Mbps, UHD Blu-Ray is closer to twice that). But if your device can only do day, 300Mbps then you can do one stream, two streams is pushing it. And if you have extra traffic on the network then your hardware no longer can process the video stream it's supposed to because it's now busy handling the other traffic, so what you end up with is a stuttery mess.
And yes, it has happened, the only solution being to VLAN or isolate the affected network components
And this happens because the device has to process every packet.
Well, not that some of that doesn't go on, but that's a bit too paranoid... the larger portion is due to money... selling big data repositories for market analysis, and the fact that companies want their products on the market before they actually work, and need to make it all cloud-based so they can try to put the toothpaste back into the tube afterwards.
Someone had to do it.
If you need all that, use ATM. Ethernet is meant to be a low cost technology for the vast majority who don't need those features.
Sounds like you're trying to reinvent Asynchronous Transfer Mode (ATM).
Does it have rounded corners? Apple's lawyers will be after you!
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The problem is you can't just add more bandwidth.
Mod up! You could have stopped right there.
Sweet Jeebuz, so many people think that bandwidth is somehow infinite.
And every techno-zealot seems to want to dump everything else for their pet projects. I mean who wouldn't want an app for their smartphone that controls their window blinds? https://www.hunterdouglas.com/... I like how the woman is standing right in front of the window.
Its kinda scary that someone somewhere thinks that is the priority use of teh intertoobz.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
First thanks for that first line of text. I like many often use Slashdot as a place to be a jerk and when I do take the time to "say something productive" it's nice to have it noticed.
HDBase-T is almost exactly what I was talking about. Before I sold my soul and left computer science for the more lucrative world of IT, it hadn't evolved yet and looked to be purely a consumer standard. Cat-5e has some hard limitations. It has a rated frequency bandwidth of 100Mhz while Cat6 is rated for 250Mhz. Standard definition video for SDI transmits as 270Mhz and HD-SDI at 1.485Ghz, and then it doubles for each step including 3GSDI, 6GSDI and 12GSDI. Even considering low balancing of TDM cells across 4 pairs, LVDS (the preferred modulation of twisted pair), only about 2/3 of the HD-SDI signal can cross a Cat6 link.
This means that to achieve better performance OFDM, QAM and other modulation must be considered to carry more bandwidth on this links. I'I not a physics expert, but purely through speculating I would imagine at least a theoretical SNR loss over distance.
It appears that HDBase-T is supposed to transmit at 10.2Gbit/sec which would suggest 4 parallel 2.55 Gbit/sec links through common Cat5e or Cat6. To be conservative, this could be 16QAM with some error checking but I haven't read the spec close enough to do more than speculate.
Either way, the modulation is less interesting than using Cat5e and Cat6 as a layer-1 medium for carrying HDMI.
This means :
A) the modulation is not compatible with Ethernet transceivers.
B) It'a probably a huge step in the right direction but not quite perfect.
The 2.0 spec appears to have been designed to carry 4k30p video. Ideally, we would go 8k60p which will require 8 times the bandwidth. This is realistic using 100Gbit SFPs in the future.
4k30p can be done reliably today using 10Gbit SFP+ modules. They cost approximately $30 each from the right vendor. An FPGA capable of converting HDMI or 6G-SDI to function on the SFP+ PHY probably costs another $20-$50. This would allow bidirectional studio quality video at 2K60p or 4K30p.
I feel like I'm writing a book. HDBase-T is probably the best current standard for carrying studio video without "Ethernet MAC problems". It's still a few generations off from being a real replacement for SDI and TDM oriented technologies.
This doesn't sound very Net Neutrality-ish.
Burn it with fire!
There's no time like the present. Well, the past used to be.
Modern Ethernet is really Ethernet in name only.
The multipoint coaxial segments are gone, replaced by point to point twisted pair. CSMA/CD is pretty much gone*. replaced by switching. The simple wire-level "manchester encoding" is pretty much gone repalced by a highly complex multilevel encodings with echo cancellation
All that is really left is the frame formats and the addressing scheme.
Just because a design descision made sense at a particular time and in a particular context does not mean it will make sense for all time and in all contexts.
* By pretty much gone, I mean that the hardware still supports it, but it's only used when connecting to legacy equipment.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
Besides being cheap which is always nice, ethernet has the advantage of being galvanically isolated at both ends making it suitable for industrial and building to building applications. I love it for test instrumentation for the same reason. Yes, you can always add galvanic isolation to other interfaces (although this can be very difficult in some cases) but ethernet has it built in.
Blame that nonsense on the old science and technology propaganda from the 1950's/60's/70's and even into the 80's. They promised everything from flying cars to controlling absolutely everything in your home at the touch of a button. These ideas have ingrained themselves into the proceeding generations, and the result is utterly useless shit like Phillips Hue, Nest, and this nonsense.
@Mindless Drivel: 100% of Twitter posts ever Tweeted.
Blame that nonsense on the old science and technology propaganda from the 1950's/60's/70's and even into the 80's. They promised everything from flying cars to controlling absolutely everything in your home at the touch of a button. These ideas have ingrained themselves into the proceeding generations, and the result is utterly useless shit like Phillips Hue, Nest, and this nonsense.
I rather think it is/was just the search for the "next big thing". Smartwatches didn't work. The Internet of Things is an unfolding disaster.
We are in between the big things, and I'm curious what it will be.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
THIS is classic, Old-Skool /. - I was surprised to see your 7-digit UID, because this is, like, back in the 5-digit-days-good. Reading the summary, I thought it smelled like they were trying to use a hammer to drive a screw, and I'm not even a low-level protocol geek. Your response genuinely made my afternoon, and you deserve the points they don't give out enough anymore. +1.
Physics is nothing like religion. If it was, we'd have an easier time trying to raise money!
It's genuinely weird being out-slashdotted by someone with a UID that has more digits than you. Gives me hope for the future.
Physics is nothing like religion. If it was, we'd have an easier time trying to raise money!
I'm seriously having ATM flashbacks from the 90s.
You younger folks might not remember this, but the segway hype was a weak echo compared to the ATM hype. ATM was going to transform the way we built our networks. Nothing was ever going to be the same after ATM. ATM was going to make all previous data and voice networking obsolete. People would kill to get ATM to the desktop.
If I'm reading this article right, someone went through the ATM specs and came up with a brand new set of names for the same old crap. It must be hell working in telecom. Their elegant circuit-switched networks are slowly being purged from the earth, replaced by vulgar packet-switched networks.
See that "Preview" button?