pxi-6683h for timestamping Ethernet packets

[xl600]

Can the PXI-6683H be used to timestamp incoming Ethernet packets when in free-running mode?  For example, I would like to capture the time every UDP packet is received at a high resolution.

This would not be connected to any 1588 capable network, PPS, IRIG, or GPS.  All I desire to do is obtain a very accurate and very low jitter timestamp for each UDP packet received on a specific port or ports with respect to the system clock.

Thanks,

xl600

[JamesB.]

The 6683H doesn't allow you to timestamp arbitrary Ethernet packets. Timestamping for the various synchronization protocols is implemented internally and is not configurable.

The 6683H does allow you to timestamp signals. So, if you could get your hands on a network interface that generates a pulse when it receives a UDP packet, the 6683H could timestamp that pulse. 

I'm guessing you already considered software timestamping. That is, your application could detect the arrival of a UDP packet, then query the current time from the 6683H. With that approach, timestamps will always be later than the packet's actual arrival time, and the exact delay will depend on the operating system's scheduler, performance of your application, etc. The delay is likely on the order of milliseconds.

[xl600]

Software timestamping is my first option, but if it can't get me the accuracy needed, I have to come up with a new approach.  This is running on a PXIe-1082 chassis with an 8135RT controller.  I don't know of any ethernet interface available for that platform that would provide a discrete trigger for specific packets.  I need 500us or better timestamp accuracy, which I think I can get to with software time stamps,, but if I can't, I now don't know where else to turn since the 6683h won't be of any help.  I tried a simple high-resolution timestamp test on the loopback interface and found an average of 17us difference (Which I fully expect to worsen as the application complexity increases).

[JamesB.]

This departs from my area of expertise, but I think you would be able to use a FlexRIO device and implement timestamping in LabVIEW FPGA. That's significantly more complex than software timestamping.

[xl600]

Just so happens I have two FlexRIOs in my system, but these are reserved for Camera Link.  The most I could do with these is timestamping of a discrete signal or signals.

It can't be this hard to get sub ms timestamps out of LabView RT can it?

[JamesB.]

I don't have a different answer for you than what I've previously suggested, but I want to be clear about the capabilities of our products.

The 6683H can timestamp signals with 10 ns resolution and is fully supported by the NI-Sync driver on PXI and PXIe LabVIEW Real-Time systems.

As I see it, the particular detail that makes your application challenging is that you are trying to timestamp messages of a protocol (UDP), which requires knowledge of how to interpret that protocol. Since the 6683H implements hardware timestamping of the Precision Time Protocol (PTP), it isn't unreasonable to assume it is capable of timestamping other types of network traffic. However, this feature is not available with any of NI's current timing and synchronization products. If this is a critical need for you, a next step would be to contact your local sales representative to explore custom engineering options.

[jkerrigan12]

Was a solution ever found to this problem?

I have the exact same need where I would like to get very accurate timestamps on incoming UDP packets but I don't want to purchase the 6683H if it is not capable of doing this.

Thanks

[xl600]

I never did find a solution for high accuracy time stamping of general UDP packets.  What I did was simply generate my own timestamps using a high priority VI for UDP receive on my RT PXI controller.  As soon as LV recognizes the UDP packet, I tack on a timestamp and propagate that in a cluster along with the UDP packet contents.

There's almost nothing else going on with my Ethernet interface so the timestamps are typically within a few 10's of us of where I would expect.  Higher priority tasks within my controller do interfere and cause some jitter in the timestamps.  It's been good enough for my needs but is by no means optimal.

[jkerrigan12]

Thanks,

But how are you able to benchmark your results. Or how can you say they are within 10's of us of where you expect.

My problem is the jitter and we dont know how much that  will be from loop to loop?

[xl600]

I synchronize my clock to the clock of the PC sending me the UDP packets via IRIG and a 6683H (Using NI TimeSync to sync the system clock to the 6683H clock).  That gets me to about 5us between system clocks after stabilization.  The sending PC timestamps its packets and I compare my timestamp to the embedded timestamp.  There's about a 50us delay between the sending timestamp and my UDP receive timestamp +/- about 10-20us.  I'm guessing at the delays in the buffers and such (The sending PC is a vxWorks SBC with the timestamp and UDP send as its highest priority task) so the 10-20us value is also a guess.  But the total delta never exceeds about 70us between the two time stamps.  That's 10 times better than my requirement so I just left it at that and didn't spend more time to improve things.

I looked at jitter using multiple load scenarios on both the LabView and vxWorks machines and still, never worse than 70us delta between timestamps.  The only thing that does cause issues is when the IRIG stability falters and the clock delta goes haywire (Which I've never been able to explain since NI's TimeSync VIs are not visible).  I added code to detect that so at least I know when not to trust my timestamps.  NI needs to either open up TimeSync or do more work to improve it (Like adding better user reset capabilities and merging the Custom sync source into the mainline TimeSync product).