Hi again, > -----Original Message----- > From: Gary E. Miller [mailto:g...@rellim.com] > Sent: Tuesday, February 24, 2015 11:04 AM > To: Jiri Benc > Cc: Keller, Jacob E; linuxptp-devel@lists.sourceforge.net > Subject: Re: [Linuxptp-devel] ntp SHMs > > 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 >
This is probably the root of your problem. Nothing else *should* be writing the clock but any software that has privileges and access to /dev/ptpX could write to it.. Also your driver can do it in case of a reset. Could you post your dmesg log? This is an Intel part that I have some driver experience with so maybe I can spot any inconsistency there. > 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 do not believe Jiri is right. I ran a similar config and it appeared to work fine, without crazy clock jumping. Chronyd simply took the SHM reference and tuned the system clock over time, because the ntpshm servo presents itself to the ntp daemon. > 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. > You need the "-r" because otherwise it doesn't have a clock to synchronize.. > > 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? > You must run phc2sys in hardware timestamping 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. > If the remote clock jumps by 300ms, it is below the normal "jump" and ptp4l servo attempts to tune for this by reducing frequency which will take a very long time to catch up since most devices cannot adjust the frequency very far. This is in order to provide a smooth transition instead of an immediate jump. > 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
