[Feature Request] Timestamp support

[go2sh]

Is your feature request related to a problem? Please describe.
For certain protocols and applications its good to know, when a packet arrived in a device. (like PTP) MACs and Phys have HW support to track the time up to a nanosecond level. Software timestamping based on a system timer is also possible. Using HW timestamps allows devices to sync up there time up to nanosecond accuracy, but stack support is needed in order to implement the protocol to pass the timestamps from the MAC/Phy to the requesting socket.

Describe the solution you'd like
Everything is an opt-in solution. The NetworkBuffer would be extended with a timestamp field to allow the HW or SW timestamp to be passed from the MAC to the socket. For RX the timestamp would be passed with the received packet. For TX the timestamp would be passed back with the transmitted packet. A way to receive the timestamp from the socket would be needed. I would go for the linux way and implement a recvmsg handler, which would allow to receive packets with the timestamp attached.

Describe alternatives you've considered
None

Additional context
This is part of a series of extensions, I created for FreeRTOS-TCP-Plus to enhance time sensitive networking support. A working prototype is on the way. The last enhancement I would like to add I VLAN support. But this is way more difficult, then time stamping or priority queues.

[jasonpcarroll]

Hi @go2sh,

I will let the team know of your request.

Best,

Jason Carroll

[htibosch]

The last enhancement I would like to add I VLAN support. But this is way more difficult, then time stamping or priority queues.

Yes I think so too.

In the beginning ( 10 years ago ), FreeRTOS+TCP had a simple support for time-stamps. But as we made the source code safer, and as time-stamps were rarely used, we decided to remove the support.

Also: none of the platforms that I used had hardware support for timestamps at that time. I could not find two CPU's with a clock / osc that would agree about the time, the differences were too big.

Now that FreeRTOS+TCP dev/IPv6_integration is getting in a stable state, it is good to think about this extension.

Everything is an opt-in solution.

Very good. The option should not change the existing behaviour, or the size of code when the option is not selected.

@jasonpcarroll wrote:

I will let the team know of your request.

Let's wait for that. I am enthusiastic and looking forward to the new options.

PS. One of my specialties (beside +TCP) is audio distribution and audio limiting. That is also why I looked at timestamping.

[evpopov]

Nowadays there are plenty of MCUs that provide timestamps one way or another and since we are working with Realtime OS, I think it makes sense to support them. 1588 has been around for decades, TSN ( as in time sensitive networking ) is on the horizon ( which I'm not very familiar with ), IIOT is pushing deeper and deeper into the low level stuff like sensors and actuators. In my humble opinion, all these factors will continue to increase the need for timestamp support.
What I am very unclear about is how can we tackle this because it's not as easy as it may sound.
Perhaps we need to look into how different targets implement hardware timestamps so that we can make a smart decision on how they can be incorporated further up the stack. For example, the target I work with ( SAME70 ) can store the nanosecond value of the hardware timer in place of the FCS for every received frame. It can also trigger interrupts for 1588 frames where within the IRQ, one can read registers that hold the entire checksum. Both of these approaches are clunky for reasons I don't want to get into.
I have read here that other targets can maybe append the timestamps of frames to the end of the frame and things like that.
My point is that different targets will do things differently and when design decisions are made for +TCP it would be great to know how different targets work.
I suggest we use this discussing to collect data on from people with different hardware that can chime in how their hardware provides the timestamps. This will provide information that can help figure out at least the following question: Is it JUST the network driver that is responsible for collecting timestamps from hardware and putting them in NetworkInterface_t or maybe the TCP task needs to do some of the work as well.

Just my 2 cents... Great discussion