On Wed, Feb 28, 2018 at 06:23:54PM +0100, Oliver Westermann wrote:
> If 'pmc -u' is running on client A and client B and client A requests data
> by eg 'GET CURRENT_DATA_SET', is it expected that there is output on
> client B's pmc?
It depends on the number of boundary hops.
> I can't say for
On Wed, Feb 07, 2018 at 12:39:12PM +0200, Yan Yankovskyi wrote:
> On Tue, Feb 6, 2018 at 7:49 PM, Richard Cochran <richardcoch...@gmail.com>
> wrote:
> > By "board running Linux" you mean a custom embedded design, don't you?
>
> Exactly. Connection is
On Tue, Feb 06, 2018 at 06:20:59PM +0200, Yan Yankovskyi via Linuxptp-users
wrote:
> I have a configuration with a PC running Ubuntu and a board running Linux.
By "board running Linux" you mean a custom embedded design, don't you?
Or what do you mean?
> ethtool reports that the board doesn't
On Tue, Feb 06, 2018 at 10:26:34AM +, Mikael Arvids wrote:
> Looking at the code (process_sync, process_follow_up and port_syfusfm) it
> seems that the intention is to handle the case when a follow up is processed
> before the corresponding sync, not when the next sync is received before the
On Thu, Jan 25, 2018 at 03:47:00PM -0500, Andrew Wilson wrote:
> PTP Priority 1 : 200
> PTP Priority 2 : 200
If the microsemi should be the GM, then it should have higher priority
than the slaves, meaning *lower* values for priority1/2.
> [global]
> logging_level
On Mon, Dec 18, 2017 at 04:24:00PM +0100, Omar Pighi wrote:
> > Here is your problem. Don't you see the huge frequency offset?
>
> but it is on the master side so it can affect the slave phc behaviour as
> well??
Yes, naturally.
> > Where did you the PHC driver for the ambarella? AFAICT that
On Sat, Dec 16, 2017 at 09:43:13PM +, Omar Pighi wrote:
> But i i look at the ptp log, tbe offset is low, so the ethernet card
> seems to.be synced...
That proves nothing.
> the phc2sys isnt a "local" problem to.the slaves?
Without seeing the logs and not knowing the details of your arm
On Sat, Dec 16, 2017 at 07:34:11PM +, Omar Pighi wrote:
> 7) what do you mean with letting the phc2sys resetting the system clock?
Do not use: phc2sys -F 0.0
> 8) what parameter can i tune to try to fix it?
-S step
Specify the step threshold of the servo. It is the
On Fri, Dec 15, 2017 at 12:09:02PM -0500, Joey DiGiorgio wrote:
> Any ideas on what might be going wrong here?
Try turning off the firewall.
HTH,
Richard
--
Check out the vibrant tech community on one of the world's
On Fri, Dec 15, 2017 at 12:05:37PM +0100, Omar Pighi via Linuxptp-users wrote:
> i used to check the sync status with
> tail -f /var/log/syslog | grep ptp
> tail -f /var/log/syslog | grep phc
>
> the output is something similar to
>
> Dec 14 16:08:34 it-eva-driving phc2sys: [23058.294] phc
On Fri, Oct 27, 2017 at 07:46:26AM +0200, Miroslav Lichvar wrote:
> If a very short sync interval is used and the process may run up to 20
> milliseconds late, then yes, I think it's expected that the clock
> check in default configuration will have false positives.
Right.
> You may want to
On Thu, Sep 28, 2017 at 06:27:09PM +, Loy, Matthias wrote:
> Attached you can find a patch with my changes.
May I ask you to add a Signed-off-by line and report this on to the
linuxptp-devel list?
Thanks,
Richard
On Tue, Sep 19, 2017 at 07:32:50AM +, Michael Fleischmann wrote:
> Does anybody have an idea?
> [] (__netif_receive_skb_core) from []
> (macb_rx+0x1dc/0x218)
> [] (macb_rx) from [] (macb_poll+0x30/0xc4)
> [] (macb_poll) from [] (net_rx_action+0x64/0x19c)
> [] (net_rx_action) from []
On Mon, Sep 18, 2017 at 01:13:28PM +, Rommel, Albrecht wrote:
> Question:
> when is originTimestamp set to 0, when to the local time?
It is always zero in linuxptp.
> What is the purpose of originTimestamp in ANNOUNCE messages?
> It has no impact on BMCA, nor on T1,T2,T3,T4.
I would say,
On Fri, Sep 15, 2017 at 01:22:56PM +, Michael Fleischmann wrote:
> Is it possible to compile linuxptp-1.8 with glibc 2.6 at all?
If your glibc lacks those, then you can patch the code to use
syscall() to call into the kernel directly, for example:
static inline int timerfd_create(int
On Tue, Aug 29, 2017 at 02:05:05PM +, Michael Fleischmann wrote:
> /Applications/tmp/fw2 # ./phc_ctl /dev/ptp0
> phc_ctl[301.748]:
> capabilities:
> 1953124 maximum frequency adjustment (ppb)
> 0 programable alarms
> 6 external time stamp channels
> 7 programmable periodic signals
>
On Fri, Aug 25, 2017 at 12:42:07PM +0200, frank wrote:
> it is currently 3.18.45 in the openwrt flavor. I think it is basically a
> kernel from Robert C Nelson where the patches are stored seperately.
To my knowledge, the bbb doesn't need any out of tree patches.
Please try mainline v3.18.66 and
On Fri, Aug 25, 2017 at 10:44:46AM +0200, frank wrote:
> I have searched the mailing-list and it looks like this was mentioned
> before, unfortunately I found no clear outcome.
This is a mainline Linux kernel or a vendor kernel?
If mainline, which version is it?
Thanks,
Richard
On Mon, Aug 07, 2017 at 03:47:58PM +, Ian Thompson wrote:
> I first thought that application code may be stamping on some
> configuration registers, and that might be the case, but to have the
> glitch always be a second and not some random time is a bit weird.
On the contrary, the Altera HPS
On Thu, Aug 03, 2017 at 01:12:48PM -0700, Vadim Butakov wrote:
> First of all, thanks for ptp4l. You did an awesome job!
> I'm using two PTP cameras connected to two ethernet network devices
> (non-PTP) on my PC, and I'm trying to sync them by using the software PTP.
Can you tell us why you want
On Fri, Jul 28, 2017 at 10:31:41PM +0100, bruce bushby wrote:
> I tried running many combinations of "ptp4l" , at no point do I ever see
> PTP "offset from master" messages.
Looks like no PTP Announce messages are arriving. You should check with
wireshark or tcpdump.
> I then installed and ran
On Fri, Jul 21, 2017 at 04:38:17PM -0400, Kin Man wrote:
> I have compiled the Linux PTP project v 1.7 and compiled the ptp4l and
> phc2sys apps. The ptp4l seems to work fine between the master (a Linux
> machine) and slave (my Xilinx Zynq board), but the phcsys seems not to work
> properly, as
On Wed, Jul 26, 2017 at 02:37:13PM +, Ian Thompson wrote:
> Forgot:
>
> Ptp4l version 1.8
> Linux 3.18 with modifications to the stmmac driver to attempt to get the
> proper time loaded with a reinitialization.
As I said in the other email, you should not load the time during
On Wed, Jul 26, 2017 at 01:56:49PM +, Ian Thompson wrote:
> Hello:
>
> I have a network of Altera SOC running ptp4l and generally it runs very well
> but there are some "glitches".
>
> Here is the log from a board. It runs for 13 hours without a problem ...
>
>
On Fri, Jul 28, 2017 at 02:27:11PM +, Ian Thompson wrote:
> Jul 28 00:48:17 buildroot user.info phc2sys: [118861.985] rms 28 max 65
> freq -355 +/- 1 delay 1179 +/- 11
> Jul 28 00:52:17 buildroot user.info phc2sys: [119102.033] rms 27 max 66
> freq -354 +/- 1 delay 1178
On Thu, Jun 29, 2017 at 10:17:35AM +0200, Richard Cochran wrote:
> Looking at ptp4l, sending an incorrect currentUtcOffset with
> currentUtcOffsetValid=0 is technically not wrong, but I agree that we
> should retain the correct offset when provided by a GM, even after
> that GM disap
On Thu, Jul 20, 2017 at 01:09:24PM +0200, Petr Kulhavy wrote:
> Now the situation has changed. The master is in sync with the
> SW-timestamping slave and the HW-timestamping slave is 37 seconds behind.
> Why is that?
I guess because your PHC on the GM is set to UTC and not TAI.
Normally, when
On Wed, Jul 19, 2017 at 01:47:37PM +0300, Feras Daoud wrote:
> Is there any way to address this issue using the current implementation ?
The clock identity is an IEEE EUI-64, an eight byte UUID. This value
may be generated automatically using the EUI-48, and that is exactly
what we do in
On Tue, Jul 18, 2017 at 04:09:57PM +0200, Petr Kulhavy wrote:
> 1. GM using HW time stamping
Okay, so make sure the master has the correct UTC offset.
[global]
utc_offset 37
or
ptp4l --utc_offset=37
> The HW-timestamping slave is also running:
> /usr/sbin/phc2sys -s
On Fri, Jul 14, 2017 at 11:20:44AM +0200, Petr Kulhavy wrote:
> My master is another ptp4l running device. What you're saying would then
> mean that ptp4l in master mode sends its time in UTC.
So your setup is this?
1. GM using SW time stamping
2. Slave 1 using SW time stamping
3. Slave 2 using
On Wed, Jun 28, 2017 at 11:38:48PM +0200, Boris Boucher wrote:
> But, in a global system that is powered up, the GPS helped master
> clock will take some some time to start, eventually more time than
> my SERVER machine. In between the SERVER will assume grand master
> role and start broadcast the
On Wed, Jun 28, 2017 at 11:08:04PM +0200, Boris Boucher wrote:
> No, the CLIENTS are running ptpd.
Ok, then ptpd has a bug. It ignores the currentUtcOffsetValid member
of the TIME_PROPERTIES data set. You will need to fix that in order
to solve your start up problem, or you could instead work
On Thu, Jun 22, 2017 at 09:18:34AM +0200, Boris Boucher wrote:
> I also swear that I may also have a problem during system startup, if the
> serveur is started before the master clock, it may
> start to broadcast a time with the wrong UTC offset until the GM is ready.
Be sure to check the value
On Wed, Jun 21, 2017 at 07:57:21PM +0200, Boris Boucher wrote:
> The problem is, if the grand master is lost (power failure, network
> issue), my boundary
> clock promotes itself as grand master, and uses its own knowledge of the
> UTC offset instead
> of the last known offset from the secure
On Wed, May 17, 2017 at 02:29:09PM -0500, John Lemonovich wrote:
> Now I am trying with the -H option for PHC to achieve better timing
> (hopefully). Should it work for the EMAC with the 4.1.22-ltsi-altera
> kernel?
IIRC, last time I looked, the altera HW and drivers are hopelessly
broken.
On Thu, May 18, 2017 at 10:17:32AM +0200, Petr Kulhavy wrote:
> Is the interface always polling? Or can the daemon send notifications?
We have one "push" message for port state. See phc2sys.c for the client side.
Internally, in ptp4l, the push code can be easily enough expanded if needs be.
On Wed, May 17, 2017 at 03:12:36PM +0200, Petr Kulhavy wrote:
> After regaining the network the slave was synchronised to itself and
> didn't want to resync to the master as I expected.
A slave cannot synchronize to itself.
> After restarting ptp4l on the slave it perfectly synchronized to the
On Wed, May 17, 2017 at 03:01:03PM +0200, Petr Kulhavy wrote:
> The reason why I was asking is that some protocols like AVB provide
> the clock master ID and domain number with the stream description.
AVB, you say?
IIRC, there is absolutely nothing in 802.1AS-2011 that allows the
client to pick
On Tue, May 16, 2017 at 10:26:01PM +0200, Petr Kulhavy wrote:
> How is it with domain number? Does the domainNumber limit the slave to
> operate only in that particular domain?
Yes.
> Can the domainNumber be changed in runtime using pmc?
1588 allows this, but it is not implemented. We only
On Tue, May 16, 2017 at 10:44:13AM -0500, John Lemonovich wrote:
> And then I ran: make install which put the output files into
> usr/local/sbin and usr/local/man/man8
BTW, your can do 'make install DESTDIR=/my/embedded/fs' to install the
binaries and man pages to the proper place.
> Can I
On Tue, Apr 25, 2017 at 03:41:12PM +, Mace, Kyle P. wrote:
> Why would you need multiple phc2sys processes? Shouldn't you only
> need one? Shouldn't the command phc2sys -s /dev/ptp0 -c /dev/ptp1 -w
> sync the two clocks? And would this still go through the system
> clock?
With 'phc2sys -a'
On Mon, Apr 24, 2017 at 11:58:59AM +, Mace, Kyle P. wrote:
> That is very good news. What do you mean by "gain peaking"?
@book{gardner2005phaselock,
title={Phaselock Techniques},
author={Gardner, F.M.},
isbn=9780471732686,
url={https://books.google.at/books?id=r5yjPuWQde0C},
On Thu, Apr 20, 2017 at 07:08:52PM +, Mace, Kyle P. wrote:
> I am in need to test ptp with as many 'hops' as possible. I have
> multiple systems with dual Ethernet ports. I would like to have a
> setup something like this: grandmaster -> BC 1 port 1 -> BC 1 port 2
> -> BC 2 port 1 -> BC 2 port
On Wed, Apr 19, 2017 at 06:52:41PM +, Collins, Cris L. wrote:
> We have a dozen very similar RHEL 7.2 systems configured with Linuxptp 1.6
> and the same NIC driver version on each. Some of them look great, some show a
> frequency of "-1" and an offset of ~ -233 and some say
>
On Tue, Apr 18, 2017 at 12:54:23PM -0700, Wolfgang Hennig wrote:
> I'm working on a project where a Xilinx Zynq uses a DP83640 (eval board) as
> the Ethernet PHY. I'm running Ubuntu/Linaro 15 on the Zynq's ARM processor
> and successfully modified kernel options and compiled/installed LinuxPTP to
Chandra,
Your question has nothing to do with linuxptp (user space stack) or
even with the Linux kernel, and as such it is off topic for this list.
Having said that, I cannot resist offering an opinion...
> A simple solution is timestamping all the packets and making the dma
> flow uniform to
On Sat, Apr 08, 2017 at 11:39:06AM +0200, Axel Holzinger wrote:
> I dived into device tree files and couldn't yet find out how the
> manufacturer configures CPTS_RFT_CLK. I have the impression that it's not
> running at all. So I contacted them and asked if they can point me in the
> right
On Thu, Apr 06, 2017 at 01:45:19PM +0200, Axel Holzinger wrote:
> To me it looks like there is trouble correctly adjusting the frequency of
> the PHC, it's always remaining +100, but also delays are ridicously high
> and negative (that doesn't make sense, does it?).
Does that SoC use the
On Wed, Apr 05, 2017 at 09:18:09AM +1000, David Mirabito wrote:
> The config is:
>
> [global]
> slaveOnly 1
> summary_interval 6
> priority1 255
>
> [ma2]
>
> And running as:
>/usr/sbin/ptp4l -f /etc/ptp4l.conf
>/usr/sbin/phc2sys -a -r -u 64 -n 5
Why are you using domain number 5 for
On Wed, Apr 05, 2017 at 02:34:14PM +, Ian Thompson wrote:
> Why is the time that gets put into the PTP registers in the STM MAC, Unix
> time rather than PTP time?
See below.
To you question from the other thread:
On Tue, Apr 04, 2017 at 03:45:16PM +, Ian Thompson wrote:
> Possibly
Ian,
The problem you are seeing shares the same symptom as in the original
post, but the root cause is different because you have totally
different HW. Let's take this discussion into its own thread, please.
I'll start by answering your other recent post.
Thanks,
Richard
On Fri, Mar 24, 2017 at 06:44:30PM +0100, Šimon Wernisch wrote:
> Hello,
> I am trying to use ptp4l with software timestamping on my raspberry pi
> with a RT5370 wireless adapter. The driver is rt2800usb found in
> drivers/net/wireless/ralink/rt2x00 of the raspberry kernel and it
> doesn't support
On Fri, Mar 24, 2017 at 10:44:20AM +0800, Hardik Gohil wrote:
> root@phycore-am335x-1:~# ptp4l -i eth0 -m -P -s
Try adding -2 (layer2 transport) to the command line.
It looks like the CPTS does not recognize UDP P2P packets. You should
ask TI about this...
Thanks,
Richard
On Fri, Mar 24, 2017 at 07:48:41AM +0100, Richard Cochran wrote:
> Please try to reproduce the issue using a mainline kernel.
I can reproduce this on a BBB on mainline 3.14.33. I honestly can't
remember whether P2P ever worked on the CPTS, but I think it did,
IIRC.
I'll see if I can tr
On Fri, Mar 24, 2017 at 02:40:33PM +0800, Hardik Gohil wrote:
> It is a vendor kernel from PHYTEC.
Please try to reproduce the issue using a mainline kernel.
Thanks,
Richard
--
Check out the vibrant tech community on
On Fri, Mar 24, 2017 at 10:44:20AM +0800, Hardik Gohil wrote:
> I am working on Linux 3.12 running on TI AM335x.
Is this a mainline kernel, or a vendor kernel?
Thanks,
Richard
--
Check out the vibrant tech community on
On Wed, Mar 01, 2017 at 01:04:48PM -, Hugh Reynolds wrote:
> The hardware timestamp counter seems to be stuck.
>
> We can set it using phc_ctl, but it doesn't count.
Sounds like a missing peripheral clock enable.
I have never used or tested the imx6 ptp driver, and so I don't have
any
On Thu, Feb 23, 2017 at 11:20:26AM +0100, Norbert Lange wrote:
> Yeah, I seen that matrix, and both NICs are on that list. Still have
> some rather serious issues, one is completely useless (82579LM, e1000e
> driver) and the other (i354, igb driver) apparently wraps the timer
> very 18 minutes,
On Thu, Feb 23, 2017 at 10:18:40AM +0100, Norbert Lange wrote:
> ptp doesnt work on any intel hardware, this scientific proof was based
> on samplesize 2. Sent another mail to that list.
> Just out of curiosity, what hardware is this tested on, and verified
> to work as master?
See:
On Wed, Feb 22, 2017 at 01:22:33PM +0100, Norbert Lange wrote:
> The Hardware is an Intel 82579L, soldered on the motherboard. Any idea
> if this is a software issue, a systematic hardware bug or something
> like a wrong reference clock?
Could be a driver issue. I took a brief look at the e1000e
On Sun, Feb 12, 2017 at 10:19:38PM +0100, Jan Deinhard wrote:
> I am looking for a low-budget (< 150 EUR) network interface card
> (preferable PCIe) with reasonable hardware support for PTP.
>
> Can someone recommend a card?
Take a look at the Intel I210-T1. I can recommend it, and I saw on
On Wed, Feb 08, 2017 at 02:35:45PM -0500, Vanderpool, Clyde wrote:
> I do not know how familiar anyone is with Greyware but I used the
> connection troubleshooter and while it can ping the Linux machine it then
> shows 'Error 53: The network path was not found'.
>
> It just doesn't seem like
On Wed, Jan 25, 2017 at 03:49:48PM +0800, Hardik Gohil wrote:
> yes using dual emac mode.
That explains it. I don't think dual emac and cpts will work together.
At least I never tested it.
> sorry for late response.
No problem.
Thanks,
Richard
On Mon, Jan 23, 2017 at 09:58:22AM +0800, Hardik Gohil wrote:
> currently I am using eth0 as peer device.
And are you using dual_emac mode?
Thanks,
Richard
--
Check out the vibrant tech community on one of the world's
On Thu, Jan 19, 2017 at 04:51:23PM +0800, Hardik Gohil wrote:
> both MAC means eth0 and eth1 you mean ? yes they are active.
> active_slave = <0>;
So is there a PTP peer device connected on slave 1 (probably =eth1) as
well? That would explain the messages, as the
On Mon, Jan 16, 2017 at 04:19:15PM +0800, Hardik Gohil wrote:
> I have a message when I configure GPS to work PTP in Peer-to-Peer mode
It is not enough to configure the master alone, you must also
configure the slave in P2P mode.
> ptp4l[18815.624]: port 1: received PDELAY_REQ without timestamp
On Fri, Jan 13, 2017 at 03:31:14PM +0800, Hardik Gohil wrote:
> I would like to know the accuracy of time synchronization ?
Then you need to measure it, using a PPS signal for example.
> And the difference between path delay and master offset ?
The path delay is the measured Ethernet
On Mon, Jan 09, 2017 at 08:53:51PM +, Ian Thompson wrote:
> We are running some embedded boards based on the Altera SOC with its
> stmicro/stmmac.
>
> The v1.7 code runs well.
> I've just compiled v1.8 and replaced the v1.7 binary, no other changes, and
> it fails
Possibly you
On Tue, Nov 22, 2016 at 09:38:43AM -0800, Dave Berg wrote:
> The system we're targeting is the TI am335x Starter Kit (TMDSSK3358),
> which uses the Qualcomm Atheros ar8031 PHY, and the MAC in the am335x
> processor uses the TI CPTS for timestamping.
Just FYI, we don't have generic support for
On Tue, Nov 22, 2016 at 02:21:07PM +0800, Hardik Gohil wrote:
> what is the accuracy of time sync ??
It depends.
Cheers,
Richard
--
___
Linuxptp-users mailing list
On Mon, Nov 21, 2016 at 10:13:32PM +0800, Hardik Gohil wrote:
> Does this means support is there from kernel 3.8
Yes.
> Yes I have tried this method and posted the problem in previous message.
You said you were running kernel 3.2. That won't work. Use kernel
3.8 or later.
BTW, the '-T'
On Sat, Nov 19, 2016 at 11:40:03AM -0500, Dale Smith wrote:
> Interesting. Do you think it's possible to rewrite the driver to
> use whatever HW support is available? Or is the HW so broken that
> they had to do it in SW?
The HW PLLs on the am335x are not stable, and so when you dial a
non-zero
On Fri, Nov 18, 2016 at 08:20:22AM -0500, David Cemin wrote:
> thank you for your prompt response. I assume you have tried it on TI AM335x
> then. If that is the case, did you use any specific development kit ?
It works on the BBW and BBB.
> Im
> interested in understanding what kind of external
On Thu, Nov 17, 2016 at 09:36:54AM -0500, David Cemin wrote:
> The AM571x and AM572x have the same CPTS block and the PTP solution on this
> family of processors is very similar.
>
> My question to this list is: How is the support for linuxptp on these
> processors? Is it fully functional ?
If
On Sun, Nov 06, 2016 at 07:30:48PM +0100, Jan Deinhard wrote:
> $ ethtool -T eth0
> Time stamping parameters for eth0:
> Capabilities:
> software-receive (SOF_TIMESTAMPING_RX_SOFTWARE)
> software-system-clock (SOF_TIMESTAMPING_SOFTWARE)
You are missing:
software-transmit
On Sun, Nov 06, 2016 at 07:57:09PM +0100, Jan Deinhard wrote:
> The difference is 15.002744156 seconds. Ouch!
>
> I guess I have to check the drivers used on my PC or is there anything else
> I can do here?
Ok, so I haven't heard of the i219 before, and somehow the igb driver
is treating it like
On Sat, Nov 05, 2016 at 08:26:27PM +0100, Richard Cochran wrote:
> testptp -g; sleep 60; testptp -g
But first reset the frequency offset, so do
testptp -f 0; testptp -g; sleep 60; testptp -g
Thanks,
Rich
On Sat, Nov 05, 2016 at 04:38:04PM +0100, Jan Deinhard wrote:
> I am using a Debian workstation and a i.MX6UL evaluation board running on a
> Linux build with Yocto. According to ethtool -T eth0 both systems support
> PTP hardware timestamping.
...
> ptp4l[26435.632]: master offset 4399753214 s2
On Mon, Oct 31, 2016 at 12:17:54PM +0100, Richard Cochran wrote:
> This is bug where the gloabl transportSpecific setting is being
> applied to the UDS interface. I'll fix this soon.
I take this back. I thought about it some more and decided not to
change this. Here is why.
First
Dear linuxptp users and developers,
I am planning to release version 1.8 in one week, without any major
new features, in order to fix the regression in version 1.7.
[ Sound familiar? The same thing happened to 1.6. I don't have the
time to maintain stable branches, and so my policy is to
On Tue, Oct 04, 2016 at 10:49:46AM +, Luke Bigum wrote:
> If I do some simple tests with linux/Documentation/ptp/testptp.c, it
> appears the PHC is spinning at about half the Hz it should be doing
> (it takes roughly 2 real seconds for the PHC to advance 1
> second). While it is an anecdotal
> So my questions:
> - is the one-shot alarm functionality of the PHC actually implemented in any
> driver?
No.
> - how can I implement this in the freescale FEC driver without
> having to modify the kernel? (ptp_clock_kernel.h and
> drivers/ptp/ptp_clock.c)
You can't implement this
On Thu, Aug 04, 2016 at 07:36:45PM +, Daniel Le wrote:
> I have frequent synchronization issue on a PTP ordinary clock which
> has Linux kernel 3.18.12 and LinuxPTP v1.6. It runs in slave mode
> with software timestamping.
You didn't tell us what hardware your are using: platform, NIC,
On Tue, Aug 02, 2016 at 07:02:12PM +0200, Richard Cochran wrote:
> struct dataset {
> UInteger8priority1; // GM, from the announce message
> struct ClockIdentity identity; // GM, from the announce message
> struct ClockQuality quality;
On Mon, Aug 01, 2016 at 10:02:04AM -0400, Vanderpool, Clyde wrote:
> The left side of the diagram is synchronized first, with the Ground Gateway
> assuming the Grand Master role. Then the right side of the diagram is
> brought up. On the right side link 1-A (which has no direct connection to
>
On Wed, Jul 27, 2016 at 05:09:04PM +0800, 劉邦慈 wrote:
> Why does the
>
> Slave
>
> (PTP4L)
>
> originTimestamp capture 0?
This is in accordance with the standard.
See Section 11.3.2 in IEEE 1588.
Thanks,
Richard
I just stumbled over Miroslav's recent article.
http://rhelblog.redhat.com/2016/07/20/combining-ptp-with-ntp-to-get-the-best-of-both-worlds/
It gives a thorough treatment of NTP and PTP. Nice work!
(Now I know what the timemaster is good for ;)
Regarding redundancy (resiliency) using PTP,
first SHM segment.
timemaster: ignore failures of non-essential processes.
Richard Cochran (17):
tsproc: Fix time stamp handling with P2P one shot mode.
Properly initialize the message lists.
fault: protect header against multiple inclusion.
print: add missing include
On Tue, Jul 19, 2016 at 10:42:20AM +0200, Baya Oussena wrote:
> I tried to compile the testptp.c but failed. Is there any one from you who
> has a code I could adapt to my need or is it as sample as just opening and
> reading /dev/ptp0 driver.
The testptp.c program is the example for the PHC API.
On Tue, Jul 12, 2016 at 10:36:29PM +0800, W.F. YANG wrote:
> Richard，
> Here i got a minor suspect issue:
> Role: slave node
> Delay Mechanism: E2E
> Scenario: slave sent a delay_req to master, and duration period of
> issuing delay_req for next time is determined by set_tmo_random(), it is a
>
On Tue, Jul 12, 2016 at 12:14:47PM +, Jesuiter, Henry (ALC NetworX GmbH)
wrote:
> Hello,
>
> as a bug fix release, it may be useful if you consider my patch from last
> Friday ([PATCH] Fix data type for return value of vasprintf()),
> regarding the the data type issue in util.c.
>
>
On Thu, Jun 30, 2016 at 11:32:49AM -0400, Dale Smith wrote:
> I think it would be far better to submit the logs as text instead of
> images. Those images are very difficult to read and impossible to edit
> (the text).
+1
In addition, can you post a short pcap file showing the PTP traffic on
the
On Thu, Jun 23, 2016 at 02:08:02PM +0200, Christian wrote:
> there also was this line every one in a while:
>
> ptp4l[5828.626]: port 1: minimum delay request interval 2^^4
That is informational only, not an error.
> I am starting the Master with a config File.
> ptp4l -f /etc/ptp.config
>
>
On Wed, Jun 22, 2016 at 08:16:20AM -0400, Vanderpool, Clyde wrote:
> I guess a little bit of both. From looking things up on google or
> different forums all I could find was kind of circular (i.e. 'frequency
> adjustment is the computer adjusting it's frequency') I figured it had
> something to
No html, please.
Thanks,
Richard
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most
On Wed, Jun 08, 2016 at 09:19:40AM +, DSP wrote:
> The ptp hardware clock seems to be adjusted correct but with phc2sys i can't
> set the RTC on the same value as the PHC. It is 36 seconds away like TAI-UTC.
The RTC should *not* have the same value as the PHC. The RTC uses the
UTC
On Wed, Mar 16, 2016 at 01:45:00PM -0700, John Hubbard wrote:
> If possible it would be really nice to get the HW time-stamping working on
> this system. I can move to another system if needed but getting this
> working would help me in the short term.
The best advice I know, would be to take
On Mon, Mar 07, 2016 at 09:22:57AM +, Fabian Schörghofer wrote:
> Do I need to use phc2sys on the master too to syncronize the time
> between the network clock and CLOCK_REALTIME?
Yes.
> Or is ptp4l already doing that?
No.
Thanks,
Richard
Wow, your code is totally broken...
On Thu, Feb 18, 2016 at 12:04:22PM +0530, Sujatha Guguloth wrote:
> static int xlnx_ptp_adjfreq(struct ptp_clock_info *ptp, s32 ppb)
> {
> struct xlnx_ptp_timer *timer = container_of(ptp, struct
> xlnx_ptp_timer,
>
On Fri, Feb 12, 2016 at 12:09:25PM +0100, frank wrote:
> During printf debugging I have seen large jumps in the timespecs
> returned by clock_gettime().
>
> Using a Intel i5 with a "Intel Corporation Ethernet Connection I217-V
> (rev 05)"
> network card around 100-200 calls to clock_gettime() in
501 - 600 of 655 matches
Mail list logo
