I’m not sure I understand what effect a delay in NIO_Linux_RequestTxTimestamp 
would have. That I see, NIO_Linux_RequestTxTimestamp builds a control message 
structure but does not make any level 2 calls. Introducing a delay here should 
be the same as introducing a delay one level up in NIO_SendPacket. Either way, 
this is before the call to sendmsg(), so the only effect I see is that the 
original message to the server is delayed by 100us. I don’t understand how this 
would affect the timing of the server response message, or the timestamp 
message. Is there something that I’m missing?

Denny


> On Nov 14, 2016, at 05:17, Miroslav Lichvar <mlich...@redhat.com> wrote:
> 
> As a quick workaround I'd suggest to try it with this change:
> 
> --- a/ntp_io_linux.c
> +++ b/ntp_io_linux.c
> @@ -465,6 +465,8 @@ NIO_Linux_RequestTxTimestamp(struct msghdr *msg, int 
> cmsglen, int sock_fd)
> {
>   struct cmsghdr *cmsg;
> 
> +  usleep(100);
> +
>   /* Check if TX timestamping is disabled on this socket */
>   if (permanent_ts_options || !NIO_IsServerSocket(sock_fd))
>     return cmsglen;

Reply via email to