I agree that there is not "any connection of pmc poll time-out to ptp4l waiting for TX time stamp."
I was just stating that I observed pmc unconditionally waiting for a timeout when using poll() and wondered if ptp4l was also unconditionally waiting on a timeout when using poll(). Based on the feedback from the group it is not waiting on the timeout. Eric Decker -----Original Message----- From: Geva, Erez <erez.geva....@siemens.com> Sent: Friday, July 9, 2021 11:50 AM To: Eric Decker <edec...@oldi.com> Cc: linuxptp-devel@lists.sourceforge.net; Richard Cochran <richardcoch...@gmail.com>; Miroslav Lichvar <mlich...@redhat.com> Subject: RE: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 I do not see any connection of pmc poll time-out to ptp4l waiting for TX time stamp. On my libpmc https://sf.net/p/libpmc I do not use any time out. The libpmc pmc tools works better this way. Erez -----Original Message----- From: Eric Decker <edec...@oldi.com> Sent: Friday, 9 July 2021 00:28 To: Richard Cochran <richardcoch...@gmail.com>; Miroslav Lichvar <mlich...@redhat.com> Cc: linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 If I recall correctly there is an unconditional 150ms delay in PMC which also uses poll(). That I why I asked the question. The delay in PMC may be related to how the firmware is structured, not poll(). I am using Linux 4.xx. Eric Decker -----Original Message----- From: Richard Cochran <richardcoch...@gmail.com> Sent: Thursday, July 8, 2021 1:42 PM To: Miroslav Lichvar <mlich...@redhat.com> Cc: Eric Decker <edec...@oldi.com>; linuxptp-devel@lists.sourceforge.net Subject: Re: [Linuxptp-devel] [PATCH] Increase the default tx_timestamp_timeout to 5 On Thu, Jul 08, 2021 at 01:10:08PM +0200, Miroslav Lichvar wrote: > On Thu, Jul 08, 2021 at 01:37:38AM +0000, Eric Decker wrote: > > If the timestamp is available in less than the timeout (5ms) will it still > > wait for the timeout, or continue processing after the timestamp is > > received? > > The poll() call is waiting for the descriptor, so it should return as > soon as the timestamp is ready. The option sets the maximum time it > waits. But on kernels older than (mumble) (3.5?) the code will sleep the entire period, then wake to read the time stamp. Thanks, Richard _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Flinuxptp-devel&data=04%7C01%7Cerez.geva.ext%40siemens.com%7C1d784133383c4cd4e2b408d9425fe84b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637613801951566481%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=9D4HZAuH9zExpzT86tfZjXtO4%2FQ%2B6ednYqty4SnbVAQ%3D&reserved=0 _______________________________________________ Linuxptp-devel mailing list Linuxptp-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
