Brian Walsh
2015-12-08 16:27:29 UTC
Sorry if this has been asked before. The archives are unreachable on
sourceforge. I keep getting an "Error 403 Read access required" when trying
to view the list archives.
I am having an issue with the ptp4l client and network connectivity. The
client works just fine and syncs the hardware clock on an Intel e1000
device. However, if anything interrupts that connectivity for a couple of
seconds the clock seems to drop the fact that it is synced to a TAI time
source with a leap second offset. It will panic that it is behind and jump
forward 36 seconds (the current leap second offset). Then a few seconds
later when connectivity is restored and resynced, it realizes it is now 36
seconds fast and takes 20 minutes or more to work back to the correct time.
I am able to reproduce this by temporarily blocking access to 1588 udp
ports 319 and 320 through iptables. Wait a few seconds and the clock will
jump ahead by the leap second offest. Unblock the udp ports and then the
clock begins the long process of adjusting back to the actual time.
Is there a setting that I have missed or something I have over looked? The
ptp4l client does not have many options. I would think that the clock
should maintain the last known offset during the brief interruption.
Thanks,
Brian
sourceforge. I keep getting an "Error 403 Read access required" when trying
to view the list archives.
I am having an issue with the ptp4l client and network connectivity. The
client works just fine and syncs the hardware clock on an Intel e1000
device. However, if anything interrupts that connectivity for a couple of
seconds the clock seems to drop the fact that it is synced to a TAI time
source with a leap second offset. It will panic that it is behind and jump
forward 36 seconds (the current leap second offset). Then a few seconds
later when connectivity is restored and resynced, it realizes it is now 36
seconds fast and takes 20 minutes or more to work back to the correct time.
I am able to reproduce this by temporarily blocking access to 1588 udp
ports 319 and 320 through iptables. Wait a few seconds and the clock will
jump ahead by the leap second offest. Unblock the udp ports and then the
clock begins the long process of adjusting back to the actual time.
Is there a setting that I have missed or something I have over looked? The
ptp4l client does not have many options. I would think that the clock
should maintain the last known offset during the brief interruption.
Thanks,
Brian