Yo Jiri!
On Tue, 24 Feb 2015 10:07:11 +0100
Jiri Benc <jb...@redhat.com> wrote:
> On Mon, 23 Feb 2015 18:48:51 -0800, Gary E. Miller wrote:
> > ptp4l[364.654]: port 1: UNCALIBRATED to SLAVE on
> > MASTER_CLOCK_SELECTED phc2sys[365.199]: port 002590.fffe.f355da-1
> > changed state phc2sys[365.199]: reconfiguring after port state
> > change phc2sys[365.199]: selecting CLOCK_REALTIME for
> > synchronization phc2sys[365.199]: selecting eth0 as the master clock
> > phc2sys[365.199]: phc offset -70353239245525 s0 freq +0
> > delay 1348
> >
> > WTF was that???
> >
> > ptp4l[365.571]: clockcheck: clock jumped forward or running
> > faster than expected! ptp4l[365.571]: master offset 70368744176888
> > s0 freq -9485 path delay 58263
>
> You are apparently running several programs that try to drive the same
> clock. This is going to fail, no matter what software you use. This is
> most likely a misconfiguration on your side, perhaps you're running
> multiple ptp4l instances over the same net interface.
No, I am not. As noted in the test procedure dump I did this first:
# killall ptp4l phc2sys
Does any other program touch the phc clocks?
Please go over my configs, presented completely in my previous email
and see if you can see the miscconfiguration. People keep saying
I'm doing it wrong, but no one coming up with any improvements.
> On a similar note, earlier in the thread, you mentioned that you want
> the realtime (system) clock to be set by other program than phc2sys.
Correct. I want ntpshm in the loop. Is that not what the "clockservo
ntpshm" option is for?
>From the man page:
-E servo
Specify which clock servo should be used. Valid values are
pi for a PI controller, linreg for an adaptive controller
using linear regression, and ntpshm for the NTP SHM
reference clock to allow another process to synchronize
the local clock. The default is pi.
> You must not tell phc2sys to drive the system clock, then, otherwise
> those two programs would fight each other. This means you must not
> pass "-r" to phc2sys, that option tells phc2sys to drive the system
> clock (please do read the phc2sys man page before asking more
> questions about this, thanks).
I've read the mann page 100 times. When I have asked questions about
it people say they do not understand it either.
I tried removing the "-r". When I do that the ntpshm is no longer
written, thus cutting ntpshm out of the loop, making this useless.
> Now, with a single interface and no system clock to sync (i.e. just
> phc2sys -a), there's just one clock (the internal clock of the NIC).
> phc2sys does synchronization of two or more clocks. If it has just one
> clock, it has nothing to synchronize it with and as the consequence,
> it does nothing.
Well, nothing is not what I see, I see craziness.
> As ntpshm is implemented as a servo, it does not come into the game at
> all. phc2sys has nothing to synchronize, as synchronizing one clock
> is a no-op, and thus does nothing. Using manual mode instead of the
> automatic one won't change this.
Well, that conflicts with prior advice on this list. Are you saying that
I have no need to run phc2sys in hardware timestamp mode? Does
that mean I can run just ptp4l in ntpshm mode and timestamp mode?
> What's needed is implementing ntpshm to be a clock, not a servo.
I'm just trying to make it do what people say it can do. I'm unfamiliar
with this code. Got any concrete suggestions?
> tl;dr: What you're trying to achieve does not work with linuxptp
> currently.
So, you are saying I can not use timestamp hardware mode and NTP at the
same time? Gack! That certainly contradicts what several people have
said on this list...
Just in my short time running timestamp software mode with NTP I
have found at least one initialization bug that requires a reboot to
overcome. Without a separate time source to compare too how can anyone
know this stuff even works?
I have also seen ptp4l software time suddenly gain large (300 mSec)
offsets that persist for hours. A program restart fixes that. There is
a lot of promise to this package, but a lot of work to do as well.
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
g...@rellim.com Tel:+1(541)382-8588
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
