Yo Miroslav!
On Fri, 6 Mar 2015 12:45:50 +0100
Miroslav Lichvar wrote:
> On Wed, Mar 04, 2015 at 12:16:48PM -0800, Gary E. Miller wrote:
> > Which still leaves me with slave PHC clocks that either go crazy or
> > have huge offsets...
>
> Another thought, is it possible that the PTP master is us
On Wed, Mar 04, 2015 at 12:16:48PM -0800, Gary E. Miller wrote:
> Which still leaves me with slave PHC clocks that either go crazy or have
> huge offsets...
Another thought, is it possible that the PTP master is using HW
timestamping with a PTP clock that is not synchronized to anything? If
it was
On Wed, Mar 04, 2015 at 12:16:48PM -0800, Gary E. Miller wrote:
> Which still leaves me with slave PHC clocks that either go crazy or have
> huge offsets...
>
> I have two live test beds now and I'mm getting a better feel for the failure
> mechanisms.
>
> It almost feels like the sign of the of
Yo Dale!
>
> On Wed, 4 Mar 2015 16:43:24 -0500
> Dale Smith wrote:
> In today's setup, the pulse is 1 mSec, 1 mSec NTP peered to the PtP
> master, and the error I see varies from -400 mSec to 800 mSec.
I could have worde that better. One PPS on the slave and one PPS on the
PTP master. The mas
Yo Dale!
On Wed, 4 Mar 2015 16:43:24 -0500
Dale Smith wrote:
> Just a pure shot in the dark, but how wide is your PPS pulse? It
> wouldn't be 80mS would it? Like you are syncing to the trailing edge
> instead of the leading edge?
I got one of each. My test bench is crowded and cross-calibrat
Greetings,
Just a pure shot in the dark, but how wide is your PPS pulse? It wouldn't
be 80mS would it? Like you are syncing to the trailing edge instead of the
leading edge?
-Dale
On Mon, Mar 2, 2015 at 9:54 PM, Gary E. Miller wrote:
> Yo Gary!
>
> On Mon, 2 Mar 2015 15:39:23 -0800
> "Gary E
Yo Miroslav!
On Wed, 4 Mar 2015 09:24:33 +0100
Miroslav Lichvar wrote:
> On Tue, Mar 03, 2015 at 11:44:47AM -0800, Gary E. Miller wrote:
> > Miroslav Lichvar wrote:
> > > On Tue, Mar 03, 2015 at 12:38:41AM -0800, Gary E. Miller wrote:
> > > > First, why does chronyd not support uSec SHM? (I us
On Tue, Mar 03, 2015 at 11:44:47AM -0800, Gary E. Miller wrote:
> Miroslav Lichvar wrote:
> > On Tue, Mar 03, 2015 at 12:38:41AM -0800, Gary E. Miller wrote:
> > > First, why does chronyd not support uSec SHM? (I usually use the
> > > SOCK)
> >
> > It does support both microsecond and nanosecond
Yo Miroslav!
On Tue, 3 Mar 2015 10:28:37 +0100
Miroslav Lichvar wrote:
> On Tue, Mar 03, 2015 at 12:38:41AM -0800, Gary E. Miller wrote:
> > > > Ah, that explains a lot. Will that fix the jitter computation?
> > >
> > > Yes, the +/- value in the chronyc sources output should be smaller
> > > t
On Tue, Mar 03, 2015 at 12:38:41AM -0800, Gary E. Miller wrote:
> > > Ah, that explains a lot. Will that fix the jitter computation?
> >
> > Yes, the +/- value in the chronyc sources output should be smaller
> > than 1 us now. It's mostly a cosmetic issue, it likely won't have any
> > noticeable
Yo Miroslav!
On Tue, 3 Mar 2015 09:31:58 +0100
Miroslav Lichvar wrote:
> > Miroslav Lichvar wrote:
> > > The default precision of the SHM refclock in chrony is 1
> > > microsecond, it won't report jitter smaller than that. Add
> > > "precision 1e-9" to the SHM line in your chrony.conf to fix th
> Miroslav Lichvar wrote:
> > The default precision of the SHM refclock in chrony is 1 microsecond,
> > it won't report jitter smaller than that. Add "precision 1e-9" to the
> > SHM line in your chrony.conf to fix that.
>
> Ah, that explains a lot. Will that fix the jitter computation?
Yes, the
Yo Gary!
On Mon, 2 Mar 2015 15:39:23 -0800
"Gary E. Miller" wrote:
> On Thu, 26 Feb 2015 21:16:21 +
> "Vick, Matthew" wrote:
>
> > One other tidbit is that I210 supports EEE, which can affect jitter,
> > although I wouldn't expect it on that level. You can try turning
> > this off via etht
Yo Jacob E!
On Tue, 3 Mar 2015 00:28:01 +
"Keller, Jacob E" wrote:
> Excellent news! :) I had forgotten about EEE
Which is why I am writing a HOWTO.
Now to figure out the problems are with my other two NICs...
RGDS
GARY
---
Yo Miroslav!
On Fri, 27 Feb 2015 07:48:09 +0100
Miroslav Lichvar wrote:
> > > One other tidbit is that I210 supports EEE, which can affect
> > > jitter, although I wouldn't expect it on that level. You can try
> > > turning this off via ethtool (ethtool --set-eee ethX eee off) to
> > > see if th
On Mon, 2015-03-02 at 15:39 -0800, Gary E. Miller wrote:
> Yo Matthew!
>
> On Thu, 26 Feb 2015 21:16:21 +
> "Vick, Matthew" wrote:
>
> > One other tidbit is that I210 supports EEE, which can affect jitter,
> > although I wouldn't expect it on that level. You can try turning this
> > off via
Yo Matthew!
On Thu, 26 Feb 2015 21:16:21 +
"Vick, Matthew" wrote:
> One other tidbit is that I210 supports EEE, which can affect jitter,
> although I wouldn't expect it on that level. You can try turning this
> off via ethtool (ethtool --set-eee ethX eee off) to see if that helps.
Ding-ding
On Thu, Feb 26, 2015 at 01:31:33PM -0800, Gary E. Miller wrote:
> This is the I210:
>
> #x SHM2 0 4 377 8 -212ms[ -212ms] +/-
> 1000ns
>
> This is a local reference clock over NTP
>
> ^* spidey.rellim.com 1 8 377 135+10us[ +14us] +/-
>
Yo Matthew!
On Thu, 26 Feb 2015 21:16:21 +
"Vick, Matthew" wrote:
> >Yup. And my hardware timestamping experience:
> >
> > - I217-LM HW bug
> > - 82574 6 mSec or worse jitter
> > - I210 300 to 900 mSec persistent offset
>
> Woah. I wouldn't have expected that (at least, I've
On 2/26/15, 12:08 PM, "Gary E. Miller" wrote:
>Yo Richard!
>
>On Thu, 26 Feb 2015 10:08:05 +0100
>Richard Cochran wrote:
>
>> On Thu, Feb 26, 2015 at 12:18:48AM -0800, Gary E. Miller wrote:
>> > So the three I have on the recommmended list are not good? Yeah, I
>> > gotta agree.
>>
>> You have
Yo Richard!
On Thu, 26 Feb 2015 10:08:05 +0100
Richard Cochran wrote:
> On Thu, Feb 26, 2015 at 12:18:48AM -0800, Gary E. Miller wrote:
> > So the three I have on the recommmended list are not good? Yeah, I
> > gotta agree.
>
> You have these three, I217-LM, 82574, and I210?
>
> - I217-LM H
On Thu, 2015-02-26 at 10:36 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Thu, 26 Feb 2015 18:11:06 +
> "Keller, Jacob E" wrote:
>
> > The absolute minimum
> >
> > HWTSTAMP_TX_ON for Transmit timestamps
> >
> > and
> >
> > HWTSTAMP_FILTER_V2_L4_SYNC if you are a slave in L4 (ipv4 or i
Yo Jacob E!
On Thu, 26 Feb 2015 18:11:06 +
"Keller, Jacob E" wrote:
> The absolute minimum
>
> HWTSTAMP_TX_ON for Transmit timestamps
>
> and
>
> HWTSTAMP_FILTER_V2_L4_SYNC if you are a slave in L4 (ipv4 or ipv6)
> mode. You would never be able to support master.
>
> HWTSTAMP_FILTER_V2_L
On Thu, 2015-02-26 at 10:03 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Thu, 26 Feb 2015 17:43:36 +
> "Keller, Jacob E" wrote:
>
> > > > ptp4l will try HWTSTAMP_FILTER_ALL if its available and degrade to
> > > > more general filters until it finds either a working combination
> > > > o
Yo Jacob E!
On Thu, 26 Feb 2015 17:43:36 +
"Keller, Jacob E" wrote:
> > > ptp4l will try HWTSTAMP_FILTER_ALL if its available and degrade to
> > > more general filters until it finds either a working combination
> > > or exits saying required mode isn't supported.
> >
> > I'm trying to make
On Thu, 2015-02-26 at 08:29 +0100, Richard Cochran wrote:
> @Jason: Got private email this week from another person using the
> I217-LM. Here is what they wrote:
>
> The offset all of a sudden jumps be 4+ seconds. I would think
> that if it was an issue with just reading the timer that th
Hi,
On Wed, 2015-02-25 at 17:47 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Thu, 26 Feb 2015 01:01:36 +
> "Keller, Jacob E" wrote:
>
> > > So what is the minimmum for hardware mode timestamping? Like this?
> > >
> > > HWTSTAMP_TX_OFF
> > > HWTSTAMP_TX_ON
> > > HWTSTAMP_F
On Thu, Feb 26, 2015 at 12:18:48AM -0800, Gary E. Miller wrote:
> So the three I have on the recommmended list are not good? Yeah, I
> gotta agree.
You have these three, I217-LM, 82574, and I210?
- I217-LM HW bug
- 82574 not a great ptp design
- I210 best PCIe card I have tried
> Any
On Thu, Feb 26, 2015 at 08:29:08AM +0100, Richard Cochran wrote:
> @Jason: Got private email this week from another person using the
> I217-LM. Here is what they wrote:
s/Jason/Jacob/
Still dizzy.
Sorry,
Richard
--
Div
Yo Miroslav!
On Thu, 26 Feb 2015 07:24:26 +0100
Miroslav Lichvar wrote:
> On Wed, Feb 25, 2015 at 04:07:05PM -0800, Gary E. Miller wrote:
> > # ipcs -m
> >
> > -- Shared Memory Segments
> > keyshmid owner perms bytes nattch
> > status 0x4e545030 0
Yo Richard!
On Thu, 26 Feb 2015 08:29:08 +0100
Richard Cochran wrote:
> On Wed, Feb 25, 2015 at 05:47:12PM -0800, Gary E. Miller wrote:
> > I'm trying to make this real simple. :-)
> >
> > So, if HWTSTAMP_TX_ON is present, can I know the NIC should be
> > supported for hardware time?
>
> Simp
On Wed, Feb 25, 2015 at 05:47:12PM -0800, Gary E. Miller wrote:
> I'm trying to make this real simple. :-)
>
> So, if HWTSTAMP_TX_ON is present, can I know the NIC should be supported
> for hardware time?
Simple answer: Pick a card that offers HWTSTAMP_TX_ON and
HWTSTAMP_FILTER_V2_EVENT.
> Agre
On Wed, Feb 25, 2015 at 04:07:05PM -0800, Gary E. Miller wrote:
> # ipcs -m
>
> -- Shared Memory Segments
> keyshmid owner perms bytes nattch status
> 0x4e545030 0 root 60096 2
>
> 0x4e545031
Yo Jacob E!
On Thu, 26 Feb 2015 01:01:36 +
"Keller, Jacob E" wrote:
> > So what is the minimmum for hardware mode timestamping? Like this?
> >
> > HWTSTAMP_TX_OFF
> > HWTSTAMP_TX_ON
> > HWTSTAMP_FILTER_ALL
> >
> >
>
> HWTSTAMP_TX_OFF is always supported. HWTSTAMP_TX_ON is re
Hi,
On Wed, 2015-02-25 at 16:48 -0800, Gary E. Miller wrote:
> Yo Jacob E!
>
> On Thu, 26 Feb 2015 00:32:27 +
> "Keller, Jacob E" wrote:
>
> > Yea, in general all you really want is HWTSTAMP_FILTER_ALL, it's a
> > much better implementation.
>
> So what is the minimmum for hardware mode ti
Yo Jacob E!
On Thu, 26 Feb 2015 00:32:27 +
"Keller, Jacob E" wrote:
> Yea, in general all you really want is HWTSTAMP_FILTER_ALL, it's a
> much better implementation.
So what is the minimmum for hardware mode timestamping? Like this?
HWTSTAMP_TX_OFF
HWTSTAMP_TX_ON
HWTSTAMP_FIL
Hi,
On Wed, 2015-02-25 at 16:07 -0800, Gary E. Miller wrote:
> Yo All!
>
> Different day, new results.
>
Looks like much better results. That is at least good for solving this
issue.
> I just got two of these:
>
> Intel Corporation 82574L Gigabit Network Connection
>
> They use the e1000
Yo All!
Different day, new results.
I just got two of these:
Intel Corporation 82574L Gigabit Network Connection
They use the e1000e driver, but report fewer capabilities to ethtool
than my i217-LM:
kong ~ # ethtool -T eth2
Time stamping parameters for eth2:
Capabilities:
hardware-
38 matches
Mail list logo
