Sorry but I only have the ptp4l running and I want to add stress. I have
not tuned it yet. I supposed that someone had done the same (ptp4l +
stress) and experienced the same problems like me.
Thank you for your help. I apreciate it.
Diego
El 22/04/2021 a las 17:12, Richard Cochran escribió:
On Thu, Apr 22, 2021 at 11:55:57AM +0200, Diego García Prieto wrote:
> adding CPU load, suddenly I lose sync. I have to say that if I force ptp4l
> and phc2sys to run in one core and the threads in other cores, everything is
> OK,
Ah, now you are getting somewhere!
You are attempting to tune your
Right, and work has no priority at all in the kernel. This could be
improved at the driver level by using the PHC kthread, which then
could be given priority administratively.
If you say to change the kworkers priority of the same core where ptp4l
and phc2sys are, I did it via "chrt -f -p 99 [
One thing. Try to load the CPU with stress-ng in your systems and check
what happens.
This is the stress-ng command: "sudo stress-ng --cpu 4 --cpu-load 25
--sched fifo --sched-prio 50 --times"
This command generates 4 threads (because I want to add load to my 4
cores) with 25% of load each.
Hello Richard,
El 22/04/2021 a las 2:03, Richard Cochran escribió:
On Wed, Apr 21, 2021 at 09:55:31PM +, Keller, Jacob E wrote:
You mentioned you were using igb. I believe that driver still relies
on a work queue task to handle the Tx timestamps, as well as
overflow check.
Right, and work
You mentioned you were using igb. I believe that driver still relies on a work
queue task to handle the Tx timestamps, as well as overflow check.
If your device needs the overflow check, and it gets skipped that could result
in very wild incorrect timestamping results. However, I do not beli
On Wed, Apr 21, 2021 at 09:55:31PM +, Keller, Jacob E wrote:
> You mentioned you were using igb. I believe that driver still relies
> on a work queue task to handle the Tx timestamps, as well as
> overflow check.
Right, and work has no priority at all in the kernel. This could be
improved at
> -Original Message-
> From: Diego García Prieto
> Sent: Wednesday, April 21, 2021 9:25 AM
> To: Richard Cochran
> Cc: linuxptp-users@lists.sourceforge.net
> Subject: Re: [Linuxptp-users] Loss of sync with 25% of CPU load
>
> Hello,
>
> It does not
Hello,
It does not work. Done: stress-ng (fifo 50), ptp4l (fifo 99),
phc2sys(fifo 99), kworker of the cores where ptp4l and phc2sys run (fifo
99). it still breaks the ptp4l synchronization when stress-ng boots up.
I do not believe that it has not happend to others.
Some new advice?
Thank y
Hello Miroslav,
That NIC and driver are solid in my experience, so I'd suspect an
issue with the system clock.
Check current and available clocksources:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
a
Hello Miroslav,
That NIC and driver are solid in my experience, so I'd suspect an
issue with the system clock.
Check current and available clocksources:
cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource
a
On Tue, Apr 13, 2021 at 11:36:00AM +0200, Diego García Prieto wrote:
> Kernel version: Linux 4.9.18-rt14-rt14 (a preempt-RT patch)
I don't know much about RT kernels.
> NIC: I210 Gigabit Network Connection - Vendor: Intel corporation - Version:
> 03
>
> Driver: igb
That NIC and driver are solid
Alright.
Kernel version: Linux 4.9.18-rt14-rt14 (a preempt-RT patch)
NIC: I210 Gigabit Network Connection - Vendor: Intel corporation -
Version: 03
Driver: igb
Ask me more if you want.
Diego
El 13/04/2021 a las 11:19, Miroslav Lichvar escribió:
On Tue, Apr 13, 2021 at 10:51:36AM +0200,
On Tue, Apr 13, 2021 at 10:51:36AM +0200, Diego García Prieto wrote:
> The driver of the network card is the intel_pstate. Is this what you refer
> to?
I think intel_pstate is about CPU power states. That might be related
if it is an issue with the TSC clocksource, but I was interested in
the kern
I am running ptp4l an dphc2sys with priority fifo 99 as well as the
stress-ng. Stress-ng load the CPU with 4 threads at 25% of load (the
board has 4 cores). I do not understand why kworkers have priority 20 by
default. I am trying to rise them to 99 for avoid interferences by the
load. Is this
The driver of the network card is the intel_pstate. Is this what you
refer to?
Thank you for your help,
Diego
El 13/04/2021 a las 10:04, Miroslav Lichvar escribió:
On Mon, Apr 12, 2021 at 04:59:06PM +0200, Diego García Prieto wrote:
Might it be fixed by disabling the sanity_freq_limit (--sa
On Mon, Apr 12, 2021 at 04:59:06PM +0200, Diego García Prieto wrote:
> Might it be fixed by disabling the sanity_freq_limit (--sanity_freq_limit 0)
> to avoid the message "clockcheck: ...jumped or slower than expected!"?
I think that just hides the underlying issue. I don't see how CPU load
could
Might it be fixed by disabling the sanity_freq_limit
(--sanity_freq_limit 0) to avoid the message "clockcheck: ...jumped or
slower than expected!"?
Diego
El 12/04/2021 a las 13:36, Diego García Prieto escribió:
I run it by changing the priorities to allow be higher the ptp4l than
the stress-
I run it by changing the priorities to allow be higher the ptp4l than
the stress-ng but it still remains the same. What could I do to solve
that loss of sync when I apply 25% of CPU load?
Thank you in advance for your responses,
Diego
El 07/04/2021 a las 18:31, Diego García Prieto escribió:
IOW, give it higher sched_fifo priority than stress-ng.
Done but it keeps similar. ptp4l at 99 and stress-ng at 50 and even at 1
priority
Also, depending on your network load, watch out for stress-ng starving
the networking stack (by keeping ksoftirqd from running).
Also, watch out for stress-
On Wed, Apr 07, 2021 at 11:38:55AM +0200, Diego García Prieto wrote:
> I would like to know if I can stablish somehow a deadline to the ptp4l
> protocol to avoid other threads run before it. I think that whereby I can
> avoid the loss of syncronization. What do you think with respect to it?
IOW,
Hello everyone,
I would like to know if I can stablish somehow a deadline to the ptp4l
protocol to avoid other threads run before it. I think that whereby I
can avoid the loss of syncronization. What do you think with respect to it?
Thank you,
Diego
El 06/04/2021 a las 12:29, Diego García
22 matches
Mail list logo
