My Arch system does indeed have daylight saving set, but nmea.c forces the
TZ to UTC where a positive value of tm_isdst does not make sense.
On Wed, Apr 21, 2021 at 1:51 PM Geva, Erez
wrote:
> Looks like the man page is not accurate.
> Looking in
>
Looks like you daylight time is broken on Arch Linux and Ubuntu 20.04.
-1 is error by mktime.
Why do you think it is related here?
Fix you daylight time setting in your system and open a bug report in the
relevant packages/systems.
Erez
From: Lars Munch
Sent: Tuesday, 20 April 2021 22:24
Hi Luigi,
there is no reasoning, why you need cmake in this RFC, just the
diffs. Therefore, what is the additional value here compared to
standard make.
-michael
___
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
Looks like the man page is not accurate.
Looking in https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html
A positive or 0 value for tm_isdst shall cause mktime() to presume initially
that Daylight Savings Time, respectively, is or is not in effect for the
specified time.
A
>From the bug reports:
"tm_isdst == 1 for UTC is invalid input for mktime" which makes perfect
sense.
See:
https://bugzilla.redhat.com/show_bug.cgi?id=1653340
https://sourceware.org/bugzilla/show_bug.cgi?id=24630
Seems glibc changed behaviour recently and my fix is perfectly valid.
On Wed, Apr
---
CMakeLists.txt| 189 ++
CMakeModules/CompilerFlags.cmake | 25
CMakeModules/check_features.cmake | 96 +++
CMakeModules/version.cmake| 39 ++
version.c | 4 +
5 files changed, 353
Hi Michael,
Hi All,
My environment is already cmake based and I preferred to handle via cmake.
The most important part is into check_features.cmake, where I check the
kernel features using small pieces of code instead of "grep" on sources.
I marked it as "RFC" because this patch doesn't add
On Wed, Apr 21, 2021 at 03:52:09PM +0200, Luigi 'Comio' Mantellini wrote:
> I marked it as "RFC" because this patch doesn't add anything and doesn't
> resolve any bugs. It is just a product of my work that I prefer to share
> with all.
Thanks for sharing, but I won't apply this patch, because I
On Wed, Apr 21, 2021 at 07:28:59PM +0200, Lars Munch wrote:
> My tests show (with recent glibc version) that with TZ=UTC mktime will
> return -1 for tm_isdst=1. For tm_isdst=0 and tm_isdst=-1 mktime returns the
> same value.
>
> IMHO, tm_isdst=0 makes the most sense for TZ=UTC as UTC does not
---
config.c | 2 +-
port.c | 40 +++-
ptp4l.8 | 9 -
3 files changed, 44 insertions(+), 7 deletions(-)
diff --git a/config.c b/config.c
index 4472d3d..f0e1e07 100644
--- a/config.c
+++ b/config.c
@@ -322,7 +322,7 @@ struct config_item
Thanks,
Forgot about it.
Erez
From: Luigi 'Comio' Mantellini
Sent: Wednesday, 21 April 2021 18:10
To: Geva, Erez (ext) (DI PA DCP R 3)
Cc: linuxptp-devel@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Propagate management messages from UNIX layer to
PTP network
You should specify 0
Hi,
We notice that when sending Management messages using UNIX socket ('pmc -u').
ptp4l propagate the message to the PTP domain network.
We try to set the target using local clock ID.
# pmc -u -f /etc/linuxptp/ptp4l.conf 'target xx.fffe.xx-1' 'get
CLOCK_DESCRIPTION'
Now, we get reply
Sorry I don't understand.
Are you suggest to use twoStepFlag in this way:
PORT_ITEM_INT("twoStepFlag", 0, 0, 1)
Then ptpt.conf should look like this:
[global]
twoStepFlag 1
[eth1]
twoStepFlag 0
[eth2]
twoStepFlag 1
[eth3]
# twoStepFlag ND -> inherit the [globa]/twoStepFlag
ciao
luigi
On Wed, Apr 21, 2021 at 07:16:29PM +0200, luigi.mantell...@gmail.com wrote:
> Sorry I don't understand.
>
> Are you suggest to use twoStepFlag in this way:
>
> PORT_ITEM_INT("twoStepFlag", 0, 0, 1)
Yes, sorry, that is what I meant.
> Then ptpt.conf should look like this:
>
> [global]
>
Set the default domain numbers according to the ITU-T standards
Signed-off-by: Lars Munch
---
configs/G.8265.1.cfg | 1 +
configs/G.8275.1.cfg | 1 +
configs/G.8275.2.cfg | 1 +
3 files changed, 3 insertions(+)
diff --git a/configs/G.8265.1.cfg b/configs/G.8265.1.cfg
index 11947b0..49eef04
That make sense.
nmea uses UTC.
UTC does not use daylight saving.
So we should set tm_isdst to zero or negative.
I think zero is better as UTC should not use daylight saving.
Sound like a good ground for a patch
Erez
From: Lars Munch
Sent: Wednesday, 21 April 2021 15:01
To: Geva, Erez (ext)
On Wed, Apr 21, 2021 at 11:51:55AM +, Geva, Erez wrote:
> Looks like the man page is not accurate.
> Looking in
> https://pubs.opengroup.org/onlinepubs/009695399/functions/mktime.html
Okay, I see now, in the man page we read:
The value specified in the tm_isdst field informs mktime()
On Thu, Apr 15, 2021 at 11:16:00AM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> This change brings slave clock jbod feature which allows ptp4l to work as a
> Ordinary Subordinate/Slave clock using "just a bunch of devices" that are not
> synchronized to each other but a collection of
You should specify 0 (ZERO) boundary hops:
pmc -b 0 -u -f /blabla/ptp4l.conf "GET CURRENT_DATA_SET"
caio
luigi
Il giorno mer 21 apr 2021 alle ore 17:37 Geva, Erez <
erez.geva@siemens.com> ha scritto:
> Hi,
>
>
>
> We notice that when sending Management messages using UNIX socket (‘pmc
>
On Tue, Apr 20, 2021 at 12:35:08PM +0200, Luigi 'Comio' Mantellini wrote:
> port.twoStepFlag.
>
> When -1, inherit the global twoStepFlag value, otherwise enable two-step mode
> for sync messages on port basis. One-step mode can be used only with hardware
> time stamping. The default is -1 (as
My tests show (with recent glibc version) that with TZ=UTC mktime will
return -1 for tm_isdst=1. For tm_isdst=0 and tm_isdst=-1 mktime returns the
same value.
IMHO, tm_isdst=0 makes the most sense for TZ=UTC as UTC does not support
DST.
On Wed, Apr 21, 2021 at 6:50 PM Richard Cochran
wrote:
>
21 matches
Mail list logo
