I looked back through your previous messages and did not see that you
ever indicated what platform you are running.
An earlier message did report that the only time sources your platform
has available are tsc and acpi_pm which I take to mean you are on an
x86 platform, but I have not seen an x86 platform in a long time which
does not also have HPET timer available as a clock source. According
to the wiki article on HPET it has been in x86 chipsets since 2005:
https://en.wikipedia.org/wiki/High_Precision_Event_Timer
My platform is: Kontron COMe-mBT10, A quad-core Intel Atom E3845 at 1,91GHz.
I check again the path "cat
/sys/devices/system/clocksource/clocksource0/available_clocksource" and
there is not HPET, only tsc and acpi_pm. I checked it on the realtime
kernel Preempt-RT and the generic kernel of Ubuntu. No one of them have
HPET.
Have you looked at the description of TSC on wikipedia?
https://en.wikipedia.org/wiki/Time_Stamp_Counter
"There is no promise that the timestamp counters of multiple CPUs on a
single motherboard will be synchronized. Therefore, a program can get
reliable results only by limiting itself to run on one specific CPU.
Even then, the CPU speed may change because of power-saving measures
taken by the OS or BIOS, or the system may be hibernated and later
resumed, resetting the TSC."
I disabled P-States and C-States on the BIOS, so the frequency on the
processor will be the maximum without relaxing.
Does /proc/cpuinfo contain the constant_tsc flag? If not then
probably the processor clock is being changed which is changing the
rate at which the tsc is ticking.
Even if your platform does have constant_tsc I am not positive what
happens if the processor goes into thermal throttling.
Can you monitor core temperatures to see what happens when you start
the load program? Maybe the processor clock first increases because
of the higher load, then decreases as the processor gets hot. If that
seems to be the case you could try running the processor at a
constant clock and lock to a frequency lower than maximum (using the
user mode scheduler for example).
Checking "/proc/cpuinfo" I saw "constant_tsc" flag. "tsc" flag as well.
What do you want me to do? I have to active it somehow?
The synchronization issue is immediately after I push enter to run the
stress-ng with priority fifo 50 and load percentage 25%. I do not
consider that the heat is a factor. The error appears just after pushing
the enter key.
I should note that my workstation is using TSC for clock, not HPET, so
I would guess that is the common choice if the processor supports
constant_tsc.
According to the Red Hat documentation the TSC clock is preferred, but
again I would assume that is on platforms which have constant_tsc, so
definitely verify that first.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux_for_real_time/7/html/reference_guide/chap-timestamping
That Red Hat doc has a lot of good information, you could read through
and compare the options available on your platform to how that doc
describes the behavior of the various options.
What more could I do?
Thank you very much for your help Chris,
Diego G.
_______________________________________________
Linuxptp-users mailing list
Linuxptp-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-users
