Comments (4)
Let's first clarify what this issue is about:
- Limit UDP datagram size to system maximum
- Limit UDP datagram size to MTU
Those 2 things are different. Or is this meant to be a discussion?
from ecal.
This is part of #1165.
The current default (which seems to be configurable via ecal.ini), causes problems on MacOS.
So I guess this is somewhat of a discussion, if we should limit to system maximum (however we want to find out which is the system maximum), or try and limit to MTU size, and see where this leads us performance wise.
Also we need to evaluate anyways, if eCAL differentiates betwwen application (payload) and registration samples.
The problems on MacOS suggested that there is already a problem with registration samples.
from ecal.
-
Actual MTU:
- Very difficult to detect
- can change when the route changes
- Will always result in the most efficient datagram size
- there is no such thing as the route for multicast, so one would probably have to detect the smallest MTU of all routes
-
Estimated MTU (hardcoded)
- Will probably be 1500byte - a couple of headers, that we expect
- Easy to implement
- Probably sufficient for almost all use cases
- Our chosen size will rarely be the optimum:
- We cannot make use use of jumbo frames
- We either always substract all headers (like VLAN, IPSec etc.) that we know of and therefore usually not fill the entire ethernet frame
- ... or we don't substract those, but that will lead to IP fragmentation in cases when they are present
- I think localhost traffic isn't bound to 1500byte MTU (but not sure)
-
System maximum
- Probably harder to implement than a hardcoded estimated MTU
- Will be different from OS to OS at least (see the reason why this ticket exists)
- Can systems with smaller Datagram Size Maximums still read big UDP datagrams?
- If not, we would have to implement a Max-UDP-Datagram-Size-Announcement-Service
- We still get low-efficiency IP fragmentation
I already hate solution 1 and 3 and thus vote for 2 😊
from ecal.
Entire Ethernet Frame size: max 1518 bytes
Here is what I think we should actually consider:
- Ethernet header + trailer: 18 bytes.
- VLAN tag (if present): 4 bytes
- IPv6 header (if used): 40 bytes (fixed)
- IPv4 header (if used): Typically 20 bytes for a simple IPv4 header. Can be blown up to 60 bytes with Options
- UDP header: 8 bytes.
There may be other protocols involved, like IPsec or other tunnel protocols.
So we have:
- 1448 bytes (considering IPv6 and everything else, but ignoring that you actually can make the IPv4 header even bigger)
- 1428 bytes (considering a fully populated IPv4 header)
from ecal.
Related Issues (20)
- Disscussion: Rework eCAL Logging concept / API.
- [play] ecal play (gui) chrashes on empty measurements
- Make sure Qt Versions of eCAL Mon GUI and Signal Plotting QWT plugin match
- Backport fixes from master to 5.12 / 5.13
- Rename python binding from pyhton3-ecal5 to eclipse-ecal
- Create 5.13 deprecation documentation
- Wrong mutex definitions in ecal C API implementation module
- Cherry-pick more commits to 5.12 / 5.13
- Frequency column in eCAL Monitor is showing weird values for slow publishers HOT 3
- ecal.core.core.mon_monitoring() and mon_pubmonitoring() improperly parsing binary data HOT 7
- Add Qt6 support again
- How to solve inter process communication timeout in ecal HOT 1
- Issues with Thread Waiting on Mac OS HOT 6
- Possible race condition in CLog
- Possible race in CGlobals
- Possible race condition in CDataWriterSHM
- how ecal services switch to udp? HOT 4
- Doc: Outdated links to eCAL Samples
- eCAL Monitor, "Error getting Monitoring Information" HOT 1
- Auto approve action incorrectly marking files as public API. HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ecal.