ptpd version with kernel send time stamps - synchronization improvements

[gertjan hofman]

Hi Patrick,

I only just had a chance to glance at that paper. Thanks for the link (and
the reference therein to my e-mail on the topic).

I think the results are somewhat dependent on the time scale.  From your
table 2, system-load-full gave standard deviations on the order of ~ms.  In
that case I am sure the time-stamping mechanism is less important, which is
confirmed indirectly by your system-load-cpu figure being 1000x better.  The
network prioritization and unfiltered spikes of MtSD is dominant.

Did you get to try any experiments to improve the convergence rate ? Just
last week I decided to tweak the time interval in timer.c (in the 'old
ptpd')

  itimer.it_value.tv_sec = itimer.it_interval.tv_sec = 0;
  itimer.it_value.tv_usec = itimer.it_interval.tv_usec = 100000;

And found my nodes claim to converge in < 45 sec.  I have yet to do any real
test (with external pulses applied to measure the true time offsets) but it
seems a simple solution to getting my system ready faster.

Cheers

Gertjan



On Sun, Jan 31, 2010 at 11:49 PM, Patrick Ohly <patrick.ohly at intel.com>wrote:

> On Fr, 2010-01-29 at 17:15 +0000, gertjan hofman wrote:
> > We didn't change any of the time stamping mechanism but found that we
> > could get improvement by taking a closer look at the filtering applied
> > to the Master to Slave Delay etc.  Especially with store and forward
> > switches,  it is not obvious to me that the kernel time stamping is
> > the dominating factor in the time synchronization.
>
> Hardware time stamping on the host definitely led to a measurable
> improvement:
>
> http://www.linuxclustersinstitute.org/conferences/archive/2008/PDF/Ohly_92221.pdf
>
> But I agree, delays inside the network are more likely to affect the
> results, which is why PTP v2 support in ptpd and v2 enabled switches are
> important. I'm sure your traffic prioritization also helps.
>
> --
> Best Regards, Patrick Ohly
>
> The content of this message is my personal opinion only and although
> I am an employee of Intel, the statements I make here in no way
> represent Intel's position on the issue, nor am I authorized to speak
> on behalf of Intel on this matter.
>
>
>


-- 
==================================================
Gertjan Hofman
ghofman [at] gmail.com   gertjan.hofman [at] honeywell.com

604-982-3574
==================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/ptpd/attachments/20100202/5feed88c/attachment.htm>