Yo Jacob E!
On Thu, 26 Feb 2015 17:41:16 +
"Keller, Jacob E" wrote:
> > > To be clear, linreg is just a linear regression servo which could
> > > control the system clock, if you were doing software
> > > timestamping. In this case linreg is controlling the hardware MAC
> > > clock.
> >
> >
Hi,
Sorry to comment so far back in the thread, but...
On Wed, 2015-02-25 at 17:34 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Tue, 24 Feb 2015 23:31:37 +
> "Keller, Jacob E" wrote:
>
> > > Hmm, I see the confusion, I never mentioned my phc2sys offest.
> > > Until it goes to 70,000 s
Just for the record...
On Tue, Feb 24, 2015 at 02:54:37PM -0800, Gary E. Miller wrote:
> > See if you get the same clock jump issue or not.
>
> Since my ptp4l is in linreg mode, it can not jump my system clock.
>
> So what should I look for?
>
> I just did that, looks ugly, but I really have no
Yo Jacob E!
On Tue, 24 Feb 2015 23:31:37 +
"Keller, Jacob E" wrote:
> > Hmm, I see the confusion, I never mentioned my phc2sys offest.
> > Until it goes to 70,000 seconds
> >
>
> Correct. I was not assuming that you had another way to measure
> system time offset from the master.
Not
Yo Richard!
On Wed, 25 Feb 2015 10:35:41 +0100
Richard Cochran wrote:
> I have been out with the flu, but let us take a look...
Well, don't get up on my account. :-)
> > kong ~ # cat ptp.conf
> > [global]
> > clock_servo linreg
>
> I recommend using the pi servo. See recent
[Dropping Gary and Jacob from CC, this is not related to the original
topic anymore.]
On Wed, 25 Feb 2015 16:15:31 +0100, Miroslav Lichvar wrote:
> The man page says the clock is synchronized by another process.
It's not clear what that means, though. I think the behavior of ntpshm
is so special
On Tue, 24 Feb 2015 21:33:49 +, Keller, Jacob E wrote:
> 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 t
On Wed, Feb 25, 2015 at 03:53:26PM +0100, Jiri Benc wrote:
> On Tue, 24 Feb 2015 21:33:49 +, Keller, Jacob E wrote:
> > 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 s
Yo Jacob E!
On Tue, 24 Feb 2015 22:32:40 +
"Keller, Jacob E" wrote:
> > > This is telling you that your clock time (CLOCK_REALTIME) is off
> > > by 70,000 seconds. That's not happy.
> >
> > Except my clock time is off by about 60 uSec. At least until
> > phc2sys tries to 'fix' the problem.
Hi,
> -Original Message-
> From: Gary E. Miller [mailto:g...@rellim.com]
> Sent: Tuesday, February 24, 2015 2:25 PM
> To: Keller, Jacob E
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] ntp SHMs
>
> Yo Jacob E!
>
> On Tue, 24 Feb
Yo Jacob E!
On Tue, 24 Feb 2015 22:35:09 +
"Keller, Jacob E" wrote:
> Hopefully you can provide the ptp4l results alone without phc2sys or
> the chronyd interfering.
Sent, I think.
> Like I mentioned use the testptp program
> from the kernel Documentation to sanity check the device's clock
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!
>
>
I have been out with the flu, but let us take a look...
On Mon, Feb 23, 2015 at 06:48:51PM -0800, Gary E. Miller wrote:
> Yo Jacob!
>
> Just to summarize what I just tried, that failed. I repeated several times,
> similar results, it just took varying times before going crazy, usually
> 10 to 90
Yo Jiri!
On Tue, 24 Feb 2015 10:07:11 +0100
Jiri Benc 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]: reconfigurin
> -Original Message-
> From: Gary E. Miller [mailto:g...@rellim.com]
> Sent: Tuesday, February 24, 2015 2:55 PM
> To: Keller, Jacob E
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] ntp SHMs
>
> Yo Jacob E!
>
> On Tue, 24 Feb
y E. Miller [mailto:g...@rellim.com]
> Sent: Tuesday, February 24, 2015 2:13 PM
> To: Keller, Jacob E
> Cc: Jiri Benc; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] ntp SHMs
>
> Yo Jacob E!
>
> On Tue, 24 Feb 2015 21:33:49 +
> "Keller, Jacob
Yo Jacob E!
On Tue, 24 Feb 2015 21:41:52 +
"Keller, Jacob E" wrote:
> > And drop the bomb:
> >
> > kong ~ # phc2sys -a -r -E ntpshm -m -M 2
> > phc2sys[354.145]: uds: sendto failed: No such file or directory
> >
>
> Apparently it recovers, because you seem to have it working. The
> -Original Message-
> From: Gary E. Miller [mailto:g...@rellim.com]
> Sent: Tuesday, February 24, 2015 3:06 PM
> To: Keller, Jacob E
> Cc: Jiri Benc; linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] ntp SHMs
>
> Yo Jacob E!
>
> On T
Hey,
> -Original Message-
> From: Gary E. Miller [mailto:g...@rellim.com]
> Sent: Monday, February 23, 2015 6:49 PM
> To: Keller, Jacob E
> Cc: linuxptp-devel@lists.sourceforge.net
> Subject: Re: [Linuxptp-devel] ntp SHMs
>
> Yo Jacob!
>
> Just to sum
Yo Jacob E!
On Tue, 24 Feb 2015 21:33:49 +
"Keller, Jacob E" wrote:
> > 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
Yo Miroslav!
On Tue, 24 Feb 2015 11:29:14 +0100
Miroslav Lichvar wrote:
> These sound like a driver bug to me. What kernel and NIC do you have?
Kernel is 3.19.0
Here is the NIC:
00:19.0 Ethernet controller: Intel Corporation Ethernet Connection I217-LM (rev
05)
DeviceName: Intel Eth
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 CLOC
Yo Miroslav!
On Tue, 24 Feb 2015 08:24:00 +0100
Miroslav Lichvar wrote:
> On Mon, Feb 23, 2015 at 06:48:51PM -0800, Gary E. Miller wrote:
> > WTF was that???
>
> Hm. Are you running 1.5 or current git? I'm not sure if it could
> explain this, but there was a bug in 1.5 affecting the shm servo.
On Mon, Feb 23, 2015 at 11:56:02PM -0800, Gary E. Miller wrote:
> Miroslav Lichvar wrote:
> > On Mon, Feb 23, 2015 at 06:48:51PM -0800, Gary E. Miller wrote:
> > > ptp4l[365.571]: clockcheck: clock jumped forward or running
> > > faster than expected!
> >
> > Looks like something else than pt
On Mon, Feb 23, 2015 at 06:48:51PM -0800, Gary E. Miller wrote:
> Here is my config:
>
> kong ~ # cat ptp.conf
> [global]
> clock_servo linreg
>
> Start ptp4l:
>
> kong ~ # ptp4l -i eth0 -l 7 -m -f ptp.conf &
>
> And drop the bomb:
>
> kong ~ # phc2sys -a -r -E ntpshm
Yo Miroslav!
On Tue, 24 Feb 2015 08:24:00 +0100
Miroslav Lichvar wrote:
> Hm. Are you running 1.5 or current git? I'm not sure if it could
> explain this, but there was a bug in 1.5 affecting the shm servo.
Oh, one other thing. Sometimes after running a timestamp hardware
test I can not revert
Yo Jacob!
Just to summarize what I just tried, that failed. I repeated several times,
similar results, it just took varying times before going crazy, usually
10 to 90 seconds.
Here is my hardware:
kong ~ # ethtool -T eth0
Time stamping parameters for eth0:
Capabilities:
Yo Jacob E!
On Tue, 24 Feb 2015 00:38:12 +
"Keller, Jacob E" wrote:
> I'm going to attempt to give you a cleaner set of instructions on how
> to enable NTPSHM servo.
Thank you.
> I assume that eth0 is your NIC, and that eth0 has hardware
> timestamping support.
Yup. Seemingly so:
k
Hello,
I'm going to attempt to give you a cleaner set of instructions on how to
enable NTPSHM servo.
I assume that eth0 is your NIC, and that eth0 has hardware timestamping
support. I am going to use linreg servo for ptp4l, and ntpshm servo for
phc2sys.
Note this uses default hardware timestamp
Yo Jacob E!
On Mon, 23 Feb 2015 22:40:17 +
"Keller, Jacob E" wrote:
> > Not having chronyd or ntpd in the loop is a total non-starter for
> > me.
> >
>
> I think I was mis-leading in my original comment here. I meant to say
> that accuracy of PTP vs NTP over WiFi could very well be differe
Hi,
On Mon, 2015-02-23 at 13:48 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Mon, 23 Feb 2015 21:09:01 +
> "Keller, Jacob E" wrote:
>
> > > Ouch... But I guess pure theory until a WiFi driver has real
> > > support.
> > >
> >
> > NTP and PTP are generally considered solutions to dif
Yo Jacob E!
On Mon, 23 Feb 2015 21:09:01 +
"Keller, Jacob E" wrote:
> > Ouch... But I guess pure theory until a WiFi driver has real
> > support.
> >
>
> NTP and PTP are generally considered solutions to different but
> related problems, so this shouldn't really be an issue.
As a gpsd ma
Hi,
I thought I would reply to answer some of your questions that I can,
On Mon, 2015-02-23 at 11:50 -0800, Gary E. Miller wrote:
> Yo Richard!
>
> On Mon, 23 Feb 2015 09:50:43 +0100
> Richard Cochran wrote:
>
> > > > PTP doesn't work well anyhow over wifi because of the unpredicable
> > > > t
Yo Richard!
On Mon, 23 Feb 2015 09:50:43 +0100
Richard Cochran wrote:
> > > PTP doesn't work well anyhow over wifi because of the unpredicable
> > > transmission scheme.
> >
> > Can it be worse than just plain old NTP?
>
> I would think it can, depending on the PI weights.
Ouch... But I gues
On Sun, Feb 22, 2015 at 01:11:12PM -0800, Gary E. Miller wrote:
> No. I noticed how the Redhat HOWTO specifies all three needed. That
> should be in the linuxptp README.
Good point.
> > PTP doesn't work well anyhow over wifi because of the unpredicable
> > transmission scheme.
>
> Can it be w
Yo Richard!
On Sun, 22 Feb 2015 15:05:48 +0100
Richard Cochran wrote:
> > I'm getting 5 uSec jitter between one hardware timing host and one
> > software time host.
>
> Sounds about right, actually pretty good. Adding a CPU and/or network
> load should make it worse.
Yup, I clearly see that,
On Sat, Feb 21, 2015 at 05:51:16PM -0800, Gary E. Miller wrote:
> I guess I got lucky and software timestamping is working for me on
> an Intel 80003ES2LAN. It uses the e1000e driver, marked as hardware
> supported, but does not have hardware support.
Right, the e1000e driver supports a whole fam
Yo Richard!
On Sat, 21 Feb 2015 16:59:41 +0100
Richard Cochran wrote:
> On Fri, Feb 20, 2015 at 02:45:46PM -0800, Gary E. Miller wrote:
> > BTW, I'm still working on getting LinuxPTP up on my local net. Are
> > there any howto docs? I don't want to use timemaster as I am very
> > picky about m
On Fri, Feb 20, 2015 at 02:45:46PM -0800, Gary E. Miller wrote:
> BTW, I'm still working on getting LinuxPTP up on my local net. Are
> there any howto docs? I don't want to use timemaster as I am very picky
> about my chrony and ntpd configs.
And check the list of supported NICs in the README.
On Fri, Feb 20, 2015 at 02:45:46PM -0800, Gary E. Miller wrote:
> Yo All!
>
> Gary E. Miller here, with the gpsd project.
>
> I can't seem to access linuxptp-users or linuxptp-devel archives
> on sourceforge. Am I missing something?
The web interface on SF is barely usable. Try gmane instead.
40 matches
Mail list logo
