[802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
Hi Lennart, Hi Young, Hi all,
You are right "roughly same latency" is not too bad, but we have to consider:
- For Ethernet we need ~10x more data rate to achieve this and therefore we can expect {more EMC, more power consumption, more RF bandwidth (wiring harness requirements), ...}
- In real networks latency of switched network will go up with architectural complexity, while CAN is a shared medium and therefore latency will be somehow fixed (as long as other high priority messages are not generating too much bus load/arbitration issues),
so I don't expect it to be competitive to CAN for small control data payloads (which is probably not the goal, yes...).
But to repeat Young Kim's words:
Ethernet however has another aim (flexibility/packetized traffic) then CAN, which inherently needs more header and therefore is somehow more inefficient on this special approach (control data).
What we have seen (and calculated) is, that we can achieve similar control traffic latency if needed (If CAN falls short on a link which is carrying control traffic as well, we can switch to 10Mbps, before using 100Mbps)
So we are in line on this topic.
To take up a summary:
- 10Mbps Ethernet is matching perfectly in between CAN/CAN-FD and 100BASE-T1.
- 10Mbps can achieve similar latency for control data as CAN/CANfd.
- 10Mbps will gain advantage over CAN/CAN-FD in payload efficiency and latency for bigger data packets.
- Eliminating Padding is not useful, as we will not gain significant advantage
- 10Mbps MAC interface is a concern, I don't have an answer yet...
- Probably for lower speeds then 10Mbps we cannot tolerate the overhead of Ethernet for control data
- A 1Mbps Ethernet project is not a good idea (as long as we do not shorten the header;-)
Regards
Stefan
-----Ursprüngliche Nachricht-----
Von: Yseboodt, Lennart [mailto:lennart.yseboodt@xxxxxxxxxxx]
Gesendet: Mittwoch, 24. August 2016 13:25
An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: Re: [802.3_10SPE] draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
Hi,
Given that 10BASE-T1 would have similar latency as high-speed CAN, that does not seem too bad.
If lower latency is really needed, 100BASE-T1 can be used.
For larger payloads, the efficiency/latency of 10BASE-T1 only increases compared to eg. CAN.
As devices transition from the simple buses (which necessitated small payloads to meet latency or bandwidth requirements) to 10BASE-T1, we will likely also see larger, more useful, payloads become more common.
Kind regards,
Lennart Yseboodt
Philips Lighting - Research
________________________________________
From: Stefan Buntz <stefan.buntz@xxxxxxxxxxx>
Sent: Wednesday, August 24, 2016 12:21
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Subject: [802.3_10SPE] AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
Hi David,
Thanks for the feedback.
Looking on your example it is quite clear that eliminating the padding fields is not really as beneficial even for 10Mbps, especially if you look into real architectures, where multiple hops, disturbing traffic and pre-emption/TSN will have much more influence on the overall latency then 300bits shorter messages - so maybe not worth the work to do.
so I agree: probably for the 10Mbps project not an needed point - eliminating the padding field alone is not gaining much efficiency.
I think on a short term perspective there are other points which are more relevant, e.g. what kind of MAC Interface should be used for 10Mbps on Single Pair, I don't know a clever sleek and simple solution for that?
however on the long term and very general perspective:
CAN has been so successful because it is much more efficient for control traffic. This is simply due to the fact that the headers are much simpler and shorter.
If I look on our communication structure/frame it will took 92µs (1Mbps CAN) to transmit 1byte of application data with a data rate of 1Mbps (or ~90µs for CANfd[500k/2M]).
If I take the same 1byte of data and transmit it via Ethernet/IP on a 10Mbps network (if I have a network I will have one switch at least) it will take minimum:
- 83µs (16µs for the cut-through switch and 67µs transmission delay for the 2nd link) or
- 134µs (if you have a stor'n'forward switch: 2 x transmission delay = 2 x 67µs) So 10x the data rate but nearly same transmission time...
But to define a new (and compatible) MAC frame format with high efficiency for control data with low payload I think this is quite another story then what we are intend to do...
Regards,
Stefan Buntz
------------------------------------------
Stefan Buntz
Mercedes-Benz Cars Development, Daimler AG Group Research & Advanced Engineering Safeguarding Hard & Software
HPC: U059 - Dep.: RD/EEQ
Phone: +49 731 505-2089
Mobil: +49 176 30 90 51 44
Fax: +49 711 305 216 45 95
E-Mail: stefan.buntz@xxxxxxxxxxx<mailto:stefan.buntz@xxxxxxxxxxx>
Address for visitors:
Buildung 10
Room 3.2.022
Wilhelm-Runge-Str. 11
D-89081 Ulm
Germany
------------------------------------------
Von: David D. Brandt [mailto:ddbrandt@xxxxxxxxxxxxxxx]
Gesendet: Montag, 22. August 2016 23:34
An: Buntz, Stefan (059)
Cc: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx
Betreff: RE: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
Stefan,
The effect of reduced latency is an application question requiring knowledge of the architecture. As my slides showed, you can't estimate the improvement from the PHY alone. Likely it is not 2x, but some smaller gain.
Some thoughts:
For an individual control message, you could reduce the entire transmission from 84 octets (672 bits or 67.2 us @ 10 M) to 39 octets (312 bits or 31.2 us @ 10 M), saving 36 us.
In a braking example:
120 km/hr, 33 m/s, 33 um/us
33 um/us * 36 us = 1188 um = 1.2 mm (reduced travel before brake command is applied)
Of course, real architectures are more complex.
If you had cut-through, then the forwarding decisions along the path would be made before we reached the pad field in the frame. So the 36 us would only be saved at the last receiver. Cut-through should know the destination before forwarding (20 octets or 16us).
Store and forward time would increase latency based on the number of hops multiplied by the packet size.
If there were packets in progress along the path, you could be delayed by the maximum packet time at each hop. Maybe your brake packet could have the highest priority, but the lower priority transmission may already have begun.
You could have pre-emption to limit the effect of the lower priority traffic. Then you'd have up to 127 octets / 102 us on each hop before preemption (minimum fragment is 64 octets).
The network could be scheduled, but unless the brake command is the only traffic, it will have to wait for its turn in the schedule. Maybe there are 4 brake command (one to each wheel) that are sent in a periodic schedule, then one of them has to be last in the schedule.
Possibly the brakes should all be applied at once or the vehicle twists. Maybe this is more important than absolute lowest latency. You might then consider accurate time synchronization to each wheel and also bounding the latency of the commands. Various methods are possible to gain this determinism.
Regards,
David D. Brandt
Senior Principal Engineer
Rockwell Automation - Advanced Technology
1201 South Second Street
Milwaukee, WI 53204-2496
414.382.4309
From: stefan.buntz@xxxxxxxxxxx<mailto:stefan.buntz@xxxxxxxxxxx> [mailto:stefan.buntz@xxxxxxxxxxx]
Sent: Monday, August 22, 2016 5:23 AM
To: David D. Brandt <ddbrandt@xxxxxxxxxxxxxxx<mailto:ddbrandt@xxxxxxxxxxxxxxx>>; STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx>
Subject: AW: draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
Hi David,
thanks for your presentations.
Especially the discussion of the reduced frame size is very interesting.
some points/remarks/question:
- I think for (at least) some of the applications the overall transmission delay of the message is as well very important (control applications).
Any additional input on how reduced frame size would influence this would be interesting as well.
- For the control applications as well we have to consider that the overall latency of the network is
bigger than the individual transmission time (number of hops or better number of switches)
- For calculating this overall latency: Can anyone (maybe of the semiconductor suppliers) give an assumption of the time a 10/100/1000Mbps store'n'forward switch would
need for a frame (only the switching from MAC to MAC)? Is this significantly different between the speed grades? Is this different for a cut-through switch?
(Or is the dominant factor the "store" part of the frame (which is nearly equal to the individual transmission time per link) and switching is negligible?)
Regards,
Stefan
PS: unfortunately I am not sure if I can join this evening...
------------------------------------------
Stefan Buntz
Mercedes-Benz Cars Development, Daimler AG Group Research & Advanced Engineering Safeguarding Hard & Software
HPC: U059 - Dep.: RD/EEQ
Phone: +49 731 505-2089
Mobil: +49 176 30 90 51 44
Fax: +49 711 305 216 45 95
E-Mail: stefan.buntz@xxxxxxxxxxx<mailto:stefan.buntz@xxxxxxxxxxx>
Address for visitors:
Buildung 10
Room 3.2.022
Wilhelm-Runge-Str. 11
D-89081 Ulm
Germany
------------------------------------------
Von: David D. Brandt [mailto:ddbrandt@xxxxxxxxxxxxxxx]
Gesendet: Montag, 22. August 2016 07:05
An: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx>
Betreff: Re: [802.3_10SPE] draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
George,
Here are the following:
Industrial Automation Bit Error Rate
brandt_082216_10SPE_01_adhoc
Reduced Minimum Frame Size
brandt_082216_10SPE_02_adhoc
I am also enclosing a third submission, updated from the 802.24 version as requested.
Industrial Automation and Emerging Single-pair Ethernet brandt_082216_10SPE_03_adhoc
Regards,
David D. Brandt
Senior Principal Engineer
Rockwell Automation - Advanced Technology
1201 South Second Street
Milwaukee, WI 53204-2496
414.382.4309
From: George Zimmerman [mailto:george@xxxxxxxxxxxxxxxxxxxx]
Sent: Sunday, August 21, 2016 9:56 PM
To: STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-10SPE@xxxxxxxxxxxxxxxxx>
Subject: [802.3_10SPE] draft contributions for the 10Mbps Single Pair ad hoc Monday 8/22
The IEEE website administration isn't set up yet, so for right now, the presentations will have to go via the reflector.
The attached two contributions are offered to help guide and focus our work - one with acting chair's comments on par, CSDs and the process, and one on draft objectives for tomorrow.
Peter Jones will be chairing our ad hoc, and I believe that we have presentation requests from David Brandt:
Industrial Automation Bit Error Rate
brandt_082216_10SPE_01_adhoc
Reduced Minimum Frame Size
brandt_082216_10SPE_02_adhoc
David - if you can forward these to the reflector, it will make the distribution easier.
See you all tomorrow morning.
-george
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxx>
310-920-3860
George Zimmerman, Ph.D.
President & Principal
CME Consulting, Inc.
Experts in Advanced PHYsical Communications george@xxxxxxxxxxxxxxxxxxxx<mailto:george@xxxxxxxxxxxxxxxxxxxx>
310-920-3860
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.
If you are not the addressee, please inform us immediately that you have received this e-mail by mistake, and delete it. We thank you for your support.