Re: [Linuxptp-users] Hardware PTP clock synchronization
PTP IEEE 1588 stack for Linux
Brought to you by:
rcochran
From: Keller, J. E <jac...@in...> - 2013-08-01 20:54:35
|
On Thu, 2013-08-01 at 19:58 +0200, Richard Cochran wrote: > On Thu, Aug 01, 2013 at 05:44:37PM +0000, Keller, Jacob E wrote: > > > > I encountered a problem while obtaining the time from the adapter Intel > > > pro1000 (82576). > > ... > > > > ptp4l[3704.267]: selected /dev/ptp0 as PTP clock > > > ptp4l[3704.278]: port 1: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3704.278]: port 0: INITIALIZING to LISTENING on INITIALIZE > > > ptp4l[3705.077]: port 1: new foreign master ece555.fffe.2de639-2 > > > ptp4l[3709.401]: selected best master clock ece555.fffe.2de639 > > > ptp4l[3709.401]: port 1: LISTENING to UNCALIBRATED on RS_SLAVE > > > ptp4l[3710.039]: recvmsg tx timestamp failed: Resource temporarily > > > unavailable > > > > This means your tx timestamp is not being properly detected. I don't > > know for sure why this is, but there are a few reasons. I will > > forward this to the intel engineer who designed the driver for this > > part. > > I wrote the original igb ptp code, but I never tested the 82576 > because I don't have one. I am not sure if Intel tested this either. > > How about just increasing the tx_timestamp_timeout configuration > option to 100 or 1000? > > Thanks, > Richard I believe this is actually physical hardware dropping the timestamps, not an issue of not returning them fast enough. I know that Matthew Vick has done some testing of the 82576 but not that much. I also believe the use of poll has since removed any of the issues due to timing (we poll for an entire second if it isn't there!) You could try increasing the poll time just in case to see if it helps.. Basically, the 82576 is not a very reliable part for timestamping... - Jake |