* https://news.ycombinator.com/item?id=41374663
* https://chipsandcheese.com/2024/08/27/teslas-ttpoe-at-hot-ch...
If Tesla were really seeking to shake things up they wouldnt have picked IPv4 to do it when the newest release has been around for nearly 30 years and has latency reduction baked in.
this smacks of a pandersome attempt from a company that sees the quite mandarin writing on the walls and has decided (in true Muskovite fashion) they too are just a misunderstood font of futurism.
TCP has the wrong abstraction for truly high performance.
I wouldn't necessarily standardize what Tesla does here, but most of the big companies have their own layer 3 transport protocol for things that need truly high speed and are operating within a datacenter.
Cray/HPE has their own Ethernet-based protocol (Slingshot was an earlier version of it - not sure what its name is now) which seems to be better than whatever Tesla has, but is not necessarily published.
- looks dead simple
- no IP layer (there's a ttpip folder in that repo though)
- distributed congestion control (TCP has a "window" field + a bunch of tentative RFCs, this has a purposeful "congestion")
- 100% implementable in hardware (TCP can, but it's complex)
Not a general TCP replacement, but the README properly highlights a "many endpoints local link" use case:
> the protocol executed entirely in hardware and deployed to a very large multi-ExaFlops (fp16) supercomputer with over 10s of thousands of concurrent endpoints. This protocol does not need a CPU or OS to be involved in any way to link and execute.
It's of no interest on the internet or any small scale netwwork.
Apart from FC is is explicitly lossless and ordered
Infiniband instead makes the sides bargain to avoid packet loss, while the medium is supposed to be reliable.
As mentioned in README, this was submitted to the larger Ultra Ethernet consortium for consideration:
> Deliver an Ethernet based open, interoperable, high performance, full-communications stack architecture to meet the growing network demands of AI & HPC at scale
This reaks of NIH.
You can always beat general purpose solutions like the TCP/IP/UDP stack if you try. For most it isn’t worth it.
- TTPoE is designed to be implemented at hardware level unlike UDP
- UDP cannot guarantee transmission whereas this does
- TTPoE is built for distributed resilience
I hope they're not hoping for mass adoption with an attitude like that. Not exactly inspiring confidence in the longevity and maintainability.
Every engineering company releases stuff like this. It’s not meant to change the world. It’s marketing to recruit other engineers who would find that problem interesting.
I'm not so sure about that.. FRom the repo :
> Tesla also announced joining the Ultra Ethernet Consortium (UEC) to share this protocol and work to standardize a new high-speed/low-latency fabric (be that TTPoE or otherwise) for AI/ML/Datacenters
Also it's a protocol, personally I will only use a protocol that's fully spec'd. It's a pain sometimes to have consensus among all contributors but it's valuable.
> edit : I will only use a protocol that's fully spec'd IN PROD
This is currently the state of much modern documentation from huge tech companies.
..which also does not inspire confidence.
Why does it have to be perfectly documented in a public github? Are all other car companies "properly" publically documenting things in github?
Does it inspire more confidence in VW's software stack if they don't share it? Is VW's confidential stack some big competitive advantage? I've used a VW ID electric vehicle. I did not come away that impressed.
CAN (or one of its more modern variants) are historically more common in automotive. However with 2-wire Ethernet connections becoming more commonplace I do think you're right that more and more cars will be moving to ethernet fieldbus.
EtherNet/IP is not as robust for many applications as its competitors (PROFINET, EtherCAT) since it is not fully deterministic. EtherCAT is my personal favorite.
Its only advantage is that it can coexist with other TCP traffic and run over standard switches, but that just results in unreliable fieldbus performance.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
