> -----Original Message----- > From: Timo Korthals [mailto:tkorth...@cit-ec.uni-bielefeld.de] > Sent: Friday, January 11, 2019 1:29 PM > To: Keller, Jacob E <jacob.e.kel...@intel.com>; > linuxptp-users@lists.sourceforge.net > Subject: Re: [Linuxptp-users] How to properly use twoStepFlag=0 > > Dear Jake, > > thanks for the fast reply:
Yep. > > On 11.01.19 18:49, Keller, Jacob E wrote: > > On Fri, 2019-01-11 at 18:03 +0100, Timo Korthals wrote: > >> Dear ptp4l-devs, > >> > > Hi, > > > >> we try to sync embedded devices, which are only capable of > >> PTP_TWO_STEP=FALSE (aka twoStepFlag=0 aka one-way-sync aka > >> PTP_Sync=1) syncing, with our Ubuntu Linux host (System overview > >> below). > >> When we run the self build ptp4l via "./ptp4l -m -l7 -2 -H -i enp0s25 > >> -E -f /etc/ptp4l.conf" (see config etc. below), the execution hangs > >> for all ptp4l versions > 1.7 at "INITIALIZING to LISTENING on > >> INIT_COMPLETE". > >> If we comment the corresponding line [1] where ptp4l hangs, its start > >> sending the SYNC_MESSAGE etc. and the log goes on with: > >> > > It sounds like your device driver (and possibly kernel changes, I don't > > remember offhand) needs to support the one step configurations. We > > can't help you with your device driver, especially if it's not > > public/open-source. > > The Kernel is the vanilla Ubuntu 4.18 Kernel from canonical's ppa for > Ubuntu 18.04: > https://packages.ubuntu.com/bionic/kernel/linux-image-4.18.0-13-generic > All flags should be alright since ptp4l compiles with > -DHAVE_ONESTEP_SYNC: > https://github.com/richardcochran/linuxptp/blob/5219b6417faa5248e6093828732ab > 9fc713b82be/incdefs.sh#L82 > The Linux igb driver for this NIC is pretty open source I guess: > https://github.com/torvalds/linux/tree/master/drivers/net/ethernet/intel/igb > Yea, so your kernel supports this. > > > > Specifically you're looking for HWTSTAMP_TX_ONESTEP_SYNC. Your kernel > > must be new enough to support the field. Additionally, you will need to > > have your driver updated to correctly enable the request for > > HWTSTAMP_TX_ONESTEP_SYNC. > Ok, that's maybe a thing since no intel driver in the Linux Kernel > supports this field: > https://github.com/torvalds/linux/search?q=HWTSTAMP_TX_ONESTEP_SYNC&unsco > ped_q=HWTSTAMP_TX_ONESTEP_SYNC > The two other chips supporting ONESTEP_SYNC are the TI dp83640 and the > Microchip LAN7430/1. > However, I only found chip samples but no buyable networkcards having > these chips. > Does someone know network cards with these chips or at least other > network cards with HWTSTAMP_TX_ONESTEP_SYNC support? Unfortunately I'm not aware of any that does. :( I thought maybe i210 hardware had support, but no one has ever implemented it in the device driver... > > Note that as far as I'm aware this only works for sync packets, and no > > kernel support for one-step of other messages has been written. This is > > primarly because no hardware has been widely available to test such a > > feature. (i.e. one-step syncing of peer delay messages) > Ok, so I only need the SYNC messages. > However, since removing the line [1] starts one-way syncing, wouldn't it > be a feasable way to do it in software (with the lack of precision)? > There is just the copy of the timestamps missing, right? > > You can't really do One Step in software, because you need to insert the software timestamp as the packet is sent. I suppose you could implement this very poorly by modifying the packet buffer with the timestamp before sending the packet to the lower device. I have no idea how much precision you'd lose doing this, but the Tx software timestamps are taken as late as possible in the device drivers, so you would lower accuracy and precision by taking the timestamp earlier at the point of insertion. Thanks, Jake _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
