Thread (53 messages) 53 messages, 9 authors, 2010-10-02

Re: [PATCH v6 0/8] ptp: IEEE 1588 hardware clock support

From: Christoph Lameter <hidden>
Date: 2010-09-23 18:36:50
Also in: linux-arm-kernel, linux-devicetree, linuxppc-dev, lkml, netdev

On Thu, 23 Sep 2010, Jacob Keller wrote:
quoted
There is a reason for not being able to shift posix clocks: The system has
one time base. The various clocks are contributing to maintaining that
sytem wide time.

Adjusting clocks is absolutely essential for proper functioning of the PTP
protocol. The slave obtains and calculates the offset from master and uses
that in order to adjust the clock properly, The problem is that the
timestamps are done via the hardware. We need a method to expose that
hardware so that the ptp software can properly adjust those clocks.
There is no way to use that clock directly to avoid all the user space
tuning etc? There are already tuning mechanisms in the kernel that do this
with system time based on periodic clocks. If you calculate the
nanoseconds since the epoch then you should be able to use that to tune
system time.
quoted
I do not understand why you want to maintain different clocks running at
different speeds. Certainly interesting for some uses I guess that I
do not have the energy to imagine right now. But can we get the PTP killer
feature of synchronized accurate system time first?
The problem is maintaining a hardware clock at the correct speed/frequency
and time. The timestamping is done via hardware, and that hardware clock
needs to be accurate. We need to be able to modify that clock. Yes, having
the system time be the same value would be nice, but the problem comes
because we don't want to jump through hoops to keep that hardware clock
accurate to the ptp protocol running on the network.
Then allow system time == hardware clock?
All of the necessary features for microsecond or better accuracy are done
via the hardware. You can get accuracy to within <10 mircoseconds while only
sending sync packets and such once per second. The reason is because the
hardware timestamps are very accurate. But if we can't properly adjust the
clocks time and frequency, we cannot maintain the accuracy of the
timestamps.
You can already adjust the system time with the existing APIs. Tuning
hardware clocks is currently done using device specific controls. But I
would think that you do not need to expose this to user space if you can
do it all in kernel.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help