Hi! Can someone then explain me why PTP does not recover itself after its interrupt due to the tx_timestamp_timeout error? And why is it that from that point on I do not see any delay_req and delay_resp messages anymore through Wireshark?
Jord > On 27 Jul 2018, at 23:03, Keller, Jacob E <jacob.e.kel...@intel.com> wrote: > >> -----Original Message----- >> From: Jord Pool [mailto:jord.p...@outlook.com] >> Sent: Friday, July 27, 2018 1:55 PM >> To: Keller, Jacob E <jacob.e.kel...@intel.com>; Richard Cochran >> <richardcoch...@gmail.com>; Cliff Spradlin via Linuxptp-users <linuxptp- >> us...@lists.sourceforge.net> >> Subject: Re: [Linuxptp-users] PXE Boot >> >> The driver in the PTP slave machine is the e1000e driver version 3.2.6k. I >> have >> updated this to version 3.4.2 but then it wouldn't even work anymore at all. >> > > Ok. Yea. I assume you used the sourceforge driver? Hmmm, yea, the 3.2.6-k has > all the fixes I'm aware of for PTP. > >> I don't know for sure, but is it safe to assume this is due to heavy network >> load or >> would the problem be somewhere else? >> > > Network load makes sense, since that could cause the device to take longer to > transmit. I'm not sure if something like traffic classes could work to help > ensure that PTP packets get higher priority or not.. (I don't even know if > e1000e supports traffic classes offhand). > >> Could there be any possibility of prioritising PTP traffic at kernel level >> to ensure >> the PTP packets will be timestamped within the default of 1ms (or at least a >> value >> at which I can safely boot multiple other servers without interruption). >> > > Maybe, but I'm not aware of how to do this. My best guess would be some sort > of traffic class setup which puts the ptp4l socket at a higher priority than > other traffic. > > I'm not really sure how to go about setting that up though. It likely needs > hardware support so that the hardware knows to prioritise sending the PTP > packets first. > > Thanks, > Jake > >> Jord Pool >> IT Service Management >> >> >> ________________________________ >> >> From: Keller, Jacob E <jacob.e.kel...@intel.com> >> Sent: Friday, July 27, 2018 10:25:06 PM >> To: Jord Pool; Richard Cochran; Cliff Spradlin via Linuxptp-users >> Subject: RE: [Linuxptp-users] PXE Boot >> >> >> >>> -----Original Message----- >>> From: Jord Pool [mailto:jord.p...@outlook.com] >>> Sent: Thursday, July 26, 2018 11:59 PM >>> To: Richard Cochran <richardcoch...@gmail.com>; Cliff Spradlin via Linuxptp- >>> users <linuxptp-users@lists.sourceforge.net> >>> Subject: Re: [Linuxptp-users] PXE Boot >>> >>> Hi all! >>> >>> As I explained in my previous email, when PXE booting, the PXE boot server >> that >>> runs in slave mode will have it's PTP slave instance interrupted, unless I >>> set the >>> tx_timestamp_timeout to ~200ms. Now what happens when booting more >> than >>> four server at the same time via PXE boot? Will I then have to increase the >>> tx_timestamp_timeout value again? This is not really the most practical way >>> of >>> being able for the PXE boot server (PTP Slave) to keep synchronised. >>> >>> To solve the problem above, maybe there is a way to prioritise the PTP >>> network >>> traffic so that it will not have any interference with servers booting >>> through >> PXE? >>> >>> Jord >>> >> >> Hi Jord, >> >> The reason you need to increase the Tx timeout is that the driver you're >> using is >> taking too long to report the timestamp. It's almost certainly either a >> driver/hardware limitation, or a bug in the driver. >> >> Basically, ptp4l is sending a Tx packet with a timestmap request, and waits >> up to 1 >> millisecond for a response. But you increased this limit ot have it wait 200 >> milliseconds. This means that the driver is taking longer than 1 millisecond >> to send >> the packet, get the timestamp, and report it back... If it fails when the >> timeout is >> 200 milliseconds, then it's taking over 1/5th of a second to do this... >> >> What driver/hardware are you using? >> >> Thanks, >> Jake >> > ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Linuxptp-users mailing list Linuxptp-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-users
