Re: [chrony-dev] [PATCH] contrib: remove obsolete scripts

[Håkan Johansson]

Perhaps it could be explained why they are obsolote,
each contributed item?

Best regards,
Håkan


On Thu, 15 Aug 2019, Vincent Blut wrote:


Hello,

I hope that this proposal will not cause controversy, but I really think that 
apart from Bryan’s work, all the provided scripts should be erased due to 
their obsolescence.


Cheers,
Vincent

Re: [chrony-dev] Documentation patch

[Håkan Johansson]

On Sat, 22 Oct 2016, Rune Magnussen wrote:


På Fri, 21 Oct 2016 16:11:16 -0700 (PDT)
Bill Unruh  skrev:

On Sat, 22 Oct 2016, Rune Magnussen wrote:


Hi

When trying to install chrony from source, I found out that the
README refered to INSTALL which does not exist. Also asciidoctor is
needed during install. here is a patch to fix the docs.


Not at all sure where you are getting your source for chrony.
Version 1.31.2 certainly has an INSTALL file. And I have no idea what
"asciidoctor" is and I certainly do not need it.

Which version of chrony are you refering to? And is this the source
from some distribution?



I just did af git clone from https://github.com/mlichvar/chrony

There is no INSTALL in the same directory as the README.
Where is the INSTALL supposed to be?


'grep -r INSTALL *' hints that in make_release there is a line

iconv -f utf-8 -t ascii//TRANSLIT < doc/installation.txt > INSTALL

such that doc/installation.txt in git ends up as INSTALL in a release.

Cheers,
Håkan

Re: [chrony-dev] [PATCH] Fix precision loss warnings

[Håkan Johansson]

On Sun, 9 Aug 2015, Bryan Christianson wrote:




On 9/08/2015, at 5:57 pm, Håkan Johansson <f96h...@chalmers.se> wrote:


Curiosity:  recvfrom and sendto returns ssize_t (which is 64 bits on some
platforms), so this would invite for code that could make mistakes, by cutting 
the values.

Should the return value not rather be put in a ssize_t or some other variable 
that is large enough?  And if really casted down, first be checked that they 
fit.


The result was being truncated (on some platforms) prior to this patch 
(assigning to variable declared as int) so there is no net change. I don't 
thing chrony will ever return more than 2 billion bytes in a single read, but 
maybe that would be a better way to do it. Is ssize_t available on all 
platforms that chrony supports? I didn't know so chose to maintain the status 
quo in terms of variable sizes.


I am just a bystander, so it is a question for Miroslav.

// Håkan



--
Bryan Christianson
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Alleged out of bounds read in cmdmon.c

[Håkan Johansson]

Dear Clouds,

I also fail to see any memory allocation in transmit_reply().  Line 670 is 
the function itself.  On which line is the allocation?


The pointers used by sendto(): msg and where_to->u both have come as 
pointers to transmit_reply().


The line specification 1815 did not have any allocation in 
chrony-1.30.tar.gz.  Could you verify that you have seen the errors with 
that clean source, and also send the valgrind output?


Thanks,
Håkan Johansson


On Tue, 5 Aug 2014, Miroslav Lichvar wrote:


On Wed, Jul 30, 2014 at 10:53:42AM +0200, Miroslav Lichvar wrote:

On Wed, Jul 30, 2014 at 12:56:21AM -0700, clo...@riseup.net wrote:

Within cmdmon.c, transmit_reply() - line 670, a temporary buffer is
declared and allocated 8 bytes. So further along, within cmdmon.c - line
693, sendto(), addrlen is set to 28 bytes.  Which reads far beyond the 8
bytes allocated.


You mean the memory which where_to is pointing at is only 8 bytes?
where_to should be pointing at union sockaddr_in46, which includes
sockaddr_in, sockaddr_in6 and sockaddr, allocated on stack in
read_from_cmd_socket(). Here, it seems to be 28 bytes with IPv6
enabled and 16 bytes with IPv6 disabled. I don't see how it could be
only 8 bytes.


Is anyone else seeing this? Our code looks good to me, so I suspect
they have some local modifications there. Am I overlooking something?

--
Miroslav Lichvar

--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] GCC issue

[Håkan Johansson]

The second call to fclose should also be checked for errors.

// Håkan


On Tue, 21 Jan 2014, Harald Krammer wrote:


You are right.


Index: src/chrony/reference.c
===
--- chrony/reference.c
+++ chrony/reference.c
@@ -311,14 +311,16 @@
  }

  /* Write the frequency and skew parameters in ppm */
-  if ((fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0) |
-  fclose(out)) {
+  if ( fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0)  {
+fclose(out);
Free(temp_drift_file);
LOG(LOGS_WARN, LOGF_Reference, "Could not write to temporary
driftfile %s.tmp",
drift_file);
return;
  }

+  fclose(out);
+
  /* Clone the file attributes from the existing file if there is one. */

  if (!stat(drift_file,)) {




On Tue, 21 Jan 2014 10:39:43 +0100, Håkan Johansson <f96h...@chalmers.se>
wrote:

With a logical or, the fclose will not happen if fprintf fails.
Perhaps better separate these calls?

// Håkan


On Tue, 21 Jan 2014, Harald Krammer wrote:


Hello,

I am testing Chrony 1.29 on my ARM based System with GCC 3.4.6.

A small problem is happen in reference.c.  GCC 3.4.6 does not respect
the order in bit-wise or.  -> fclose comes for fprintf
-> a logical or works fine


Index: chrony/reference.c
===
--- chrony/reference.c
+++ chrony/reference.c
@@ -311,7 +311,7 @@
  }

  /* Write the frequency and skew parameters in ppm */
-  if ((fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0) |
+  if ((fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0) ||
  fclose(out)) {
Free(temp_drift_file);
LOG(LOGS_WARN, LOGF_Reference, "Could not write to temporary
driftfile %s.tmp",



Nice greetings,
Harald Krammer


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with
"unsubscribe" in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in
the subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.




--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] GCC issue

[Håkan Johansson]

With a logical or, the fclose will not happen if fprintf fails.
Perhaps better separate these calls?

// Håkan


On Tue, 21 Jan 2014, Harald Krammer wrote:


Hello,

I am testing Chrony 1.29 on my ARM based System with GCC 3.4.6.

A small problem is happen in reference.c.  GCC 3.4.6 does not respect
the order in bit-wise or.  -> fclose comes for fprintf
-> a logical or works fine


Index: chrony/reference.c
===
--- chrony/reference.c
+++ chrony/reference.c
@@ -311,7 +311,7 @@
  }

  /* Write the frequency and skew parameters in ppm */
-  if ((fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0) |
+  if ((fprintf(out, "%20.6f %20.6f\n", freq_ppm, 1.0e6 * skew) < 0) ||
  fclose(out)) {
Free(temp_drift_file);
LOG(LOGS_WARN, LOGF_Reference, "Could not write to temporary
driftfile %s.tmp",



Nice greetings,
Harald Krammer


--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] Slow bootup with git

[Håkan Johansson]

On Wed, 25 Apr 2012, Bill Unruh wrote:


On Wed, 25 Apr 2012, Ed W wrote:


On 24/04/2012 11:17, Miroslav Lichvar wrote:

 On Tue, Apr 17, 2012 at 09:07:08AM -0700, Bill Unruh wrote:
>  Mind you the rtc should not take 8 sec to read (it will take a couple, 
>  so
>  perhaps most of that time is chrony starting up), so it is not clear > 
what is

>  happening.
 It collects 8 RTC samples to get an accurate offset for the initial
 system clock adjustment. I.e. it waits for 1 + 8 RTC interrupts, the
 first one is ignored to avoid a kernel bug, which might have been
 fixed long time ago. I think decreasing that number to perhaps 2 or 3
 should be fine, but I haven't tried it.


Curious why reducing it is ok?  What is the current algorithm for reading 
the rtc time?


The rtc can only be read on the second. Ie, reading the rtc will give you the
time accurate to the last second. The rtc produces an interrupt when the
second turns over and this can be used to read the rtc accurately but only at
the second turnover. In order to get 8 samples from the rtc, you need to wait
8 seconds. If you only want 3 samples you wait three seconds. As he said,
there is a bug so that you you needed to throw away the first reading as that
interrupt could have been left over from a prior second turnover, and thus
means nothing. Now, it depends on how accurately you want the rtc time. If 
you are happy with

just the first reading, you could do that. If  you want to average it out so
as to get a really accurate reading -- averaging out some of the noise-- then
you read more times.




I thought I saw a little while back you had some busylooping to try and 
find the exact time it rolled? I thought I saw it got removed though - 
didn't work out?  Potentially that reduces the delay to the minimum 
possible?


The problem is that the setup of the interrupts on the PC has become a
complete and total mess. Thus the rtc interrupt used to come out on a 
separate

interrupt line. Then with HPET etc, the rtc interrupt got entangled with the
NMI interrupt and became essentially unuseable. Thus the rtc got polled
instead. Now if you ae willing to use all of the cpu to keep looking at the
rtc to see if it turns over, that can give you good accuracy. If your polling
is less often, then the time of the turnover becomes more inaccurate.


Could the measurement series be done with increasing accuracy?  And also 
the stepping?


For the first good measurement to be done, we expect no knowledge on where 
inside one second the turnover comes.  So polling is required fully during 
that second.  Except one can use a timeout of say 10 ms between each read, 
leaving most of the CPU to other start-up processes, if there are things 
willing to run in parallel before system time has been set.  After one 
successful good read (i.e. not first), we know within which 10 ms bin the 
turnover is.  For subsequent measurements, a timeout is set up to not wake 
us up until just before a small margin before the expected time (10 ms bin 
first time), and then during that bin polling is done at 100% CPU.  Good 
statistics is not obtained faster, but chrony becomes light on CPU use.


For the initial stepping, would it make sense to have 2 (or even 3) points 
of stepping?  After the 3rd measurement above the time (but not rate) 
should be well known, such that any big step / slew can be performed / 
initiated already then.  Further measurement are to get the rate correct, 
and the correction of that in the background after say perhaps another 8 s 
will only make other processes see a small slew.  (It can of course happen 
that the 3rd measurment misses the point, and one has to wait for the 4th 
turnover...)


Would it make sense to think of setting basically the second correct 
immediately, before any polling?  Only useful if time is really off, and 
some start-up processes would be happy with that accuracy / allow the big 
slew coming out of the next pointsetting after 3 s.


Cheers,
Håkan



The argument for using chrony to intially set the clock from the rtc has
become weak. For one thing, hwclock ( or rather one of the hwclodk versions)
can now estmate the rtc drift. SEcondly, that drift estimation was never very
good, because of temperature differences between on and off. Thus if the rtc
is out by 10PPM, that is about 1sec/day that the rtc will drift. 


I think with boot times coming down there is a desire to try and keep this 
number reasonable.  Even if we background chrony it still means a step/slew 
hitting late in the boot process when it could be done near the start (when 
on average we are less clock sensitive)


Thanks for your work on chrony!

Ed W






--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/

--
To unsubscribe email 

[chrony-dev] Sending time over serial cable and firewire

[Håkan Johansson]

Two programs, serial_ntpshm and ieee1394_ntpshm, to send and receive time 
stamps over a serial null-modem line or firewire bus are available at


http://fy.chalmers.se/~f96hajo/serial_ntpshm/serial_ntpshm_20110108.tar.gz

The serial transmission is with RTS/CTS and DTR/DTS, with the time of the 
latched signals transmitted in cleartext.  The receiving end does 
time-limited polling.  For firewire the bus cycle timer is used, with the 
transmitter broadcasting local measurements of it.  (See attached README 
for more details.)  Accuracy for both seems to be a few us or better.


For firewire, I suspect that the unsolicited direct broadcasting on a 
fixed isochronous channel is a bit 'impolite', perhaps there is a better 
way?


Sorry for the cross-posting, I imagine the topic (of PPS and such) to be 
of interest to some readers on all.  (Or suggestions on how to abuse a 
firewire bus less.)


Cheers,
Håkan

Re: [chrony-dev] PPSAPI: kernel consumer

[Håkan Johansson]

On Mon, 8 Feb 2010, Miroslav Lichvar wrote:


On Mon, Feb 08, 2010 at 12:35:59PM +0100, Håkan Johansson wrote:

I've recently (for slightly other reasons) measured the in-kernel
time consumed by doing getnstimeofday() (several in a row), and for
most machines (2 GHz+) it took a whopping ~ 500 ns.  I.e. one cannot
know to better than 0.5 us what the time was, if one e.g. try to
sandwich something else with two such calls.  The best machine was
actually a slower one (~1.05 GHz) that had about 60 ns between
return values for two back-to-back getnstimeofday().  I suppose we
are down to PCI bus latencies and so on.


Which clocksource was used? The best results should provide tsc,
usually few tens of nanoseconds. From some tests I did a while ago it
seems to worsen with more CPU cores.


The measurements:

AMD 1050 MHz,   back-to-back getnstimeofday takes 62 ns
Pentium M 1600 Mhz, back-to-back getnstimeofday takes 560 ns
Athlon 2000 MHz,back-to-back getnstimeofday takes 560 ns

All systems single-core.  Where I had available, I changed the timesource 
between acpi_pm and tsc with 
/sys/devices/system/clocksource/clocksource0/current_clocksource.

No major effect.

It was however crucial in these things to do one or a few calls to 
getnstimeofday before the two ones to do the timing to heat the processor 
caches.


Cheers,
Håkan

[chrony-dev] SHM naming

[Håkan Johansson]

It seems the SHM refclocks are named (indexed) by their appearance in the 
config file and not by the ntpshm block they correspond to.  Having e.g.


refclock SHM 3:perm=666 filter 63
refclock SHM 2:perm=666 filter 63
refclock SHM 1 filter 63 offset 0.0 delay 1e-4

I still get a list like:

SHM00   0 0 -5.265   2000.000 +0ns  4000ms
SHM10   0 0 -5.265   2000.000 +0ns  4000ms
SHM27   499  1.063  8.924  +3420ns   117us

where e.g. SHM2 in reality is the SHM 1 above.  This is confusing.  Can it 
be changed?


Cheers,
Håkan

[chrony-dev] long time to re-sync with bad system clock

[Håkan Johansson]

Hi,

I have a system with a rather bad internal clock, unstable with respect to 
temperature or voltage.  Without load the frequency is about 80 ppm slow, 
with 100 % system load it is 10 ppm slow.


Anyhow, there is one GPS connected, and quite a few network time sources. 
When load is stable, then also the clock is stable and the poll interval 
of the network sources are automatically increased.  They agree with the 
time provided by the GPS.


When I change the system load, the GPS notices this rather quickly and 
reduces NP and its span until its fit has adapted to the new frequency of 
the system.  At this point I would like chrony to start follow the new 
time.


However, this easily happens before any (or just some) network sources 
have made any new measurement.  I.e., they still think the frequency is 
like before.  Leading to the GPS clock being marked 'x' as falseticker... 
And one of the (now wrong) network sources being used as reference 
instead.


Eventually, the network sources reach their poll interval and then notice 
that their linear fits are wildly off.  On their first measurements they 
reduce their poll intervals and as soon as enough of them has noticed the 
new reality, the GPS source is allowed to discipline the clock again.


It seems to be possible to avoid this long time to re-sync by setting a 
maxpoll 6 or so on the network sources.


To avoid having to do that, I'd like to propose something like:

If a new system (B) is to be elected reference source, taking over from an 
old (A), then B must have made its last measurement at least later than 
the current (half)span of A.  If it has not, a new 'check' measurement by 
B is provoked (without it gaining reference status yet).


Either of two things can then happen: B finds that it is in fact correct 
in which case it proceeds taking over the role as reference.  Or (as I 
hope in this case) it finds that things have changed.  Most likely it will 
(using the existing logics) reduce its poll interval to sort things out 
for itself.  For some short time it will also be marked falseticker, 
perhaps leading to C being tried as reference, which then also gets 
provoked to check itself, in an avalanche...


Naturally, the bad clock system I would not choose as a production network 
time server...  :-)


Cheers,
Håkan

Re: [chrony-dev] shm permissions

[Håkan Johansson]

In the latest git the permissions can now be specified with :perm=666.


Great!

Perhaps and the output of strtol(s, NULL, 8) with 0666 to prevent the 
user from setting any other flags by mistake.


Cheers,
Håkan

Re: [chrony-dev] shm permissions

[Håkan Johansson]

Ok, could it perhaps be made an explicit option of the refclock?  (The 
sysadmins were happy to not have to change more than the config file for 
the few machines in question. :) )


Cheers,
Håkan

On Tue, 26 Jan 2010, Miroslav Lichvar wrote:


On Mon, Jan 25, 2010 at 09:48:57PM +0100, Håkan Johansson wrote:

On Mon, 25 Jan 2010, Bill Unruh wrote:

I am not sure that this is a good idea, since this would allow anyone to send
rogue data to the shm driver. It would be better to leave it at 0600 for the
chrony user ( or for root if you are using root), and let root change it if
the sysadmin wants to allow anyone to write to the shm, or at most make it a
configuration option.


It becomes a configuarion option in the sense that segments 0 and 1
use permissions 0600 and only segments 2 and 3 use 0666, so the
level of trust can then be selected that way.


I agree with Bill. This seems dangerous.


It is not clear to me what the scenario is where someone
other than root should be able to send data to this driver.


My scenario is that I am user on some systems where I will not get
root permissions, so I cannot modify/restart/etc the ntpd/chronyd
process, which I do not need.  But the sysadmins would entrust me to
run e.g. gpsd to provide reference data.  This is useful for the
further testing of gpsd I am doing, and the need to modify/restart
gpsd doing that.


If the sysadmins are willing to configure ntpd/chronyd to use SHM, I
think you can ask them to create the segment before starting the
service with any permissions you want, e.g. 600 with your user as the
owner.





--
Miroslav Lichvar

---
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe" 
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the 
subject.
Trouble?  Email listmas...@chrony.tuxfamily.org.

Re: [chrony-dev] shm permissions

[Håkan Johansson]

On Mon, 25 Jan 2010, Bill Unruh wrote:


I am not sure that this is a good idea, since this would allow anyone to send
rogue data to the shm driver. It would be better to leave it at 0600 for the
chrony user ( or for root if you are using root), and let root change it if
the sysadmin wants to allow anyone to write to the shm, or at most make it a
configuration option.


It becomes a configuarion option in the sense that segments 0 and 1 use 
permissions 0600 and only segments 2 and 3 use 0666, so the level of 
trust can then be selected that way.



It is not clear to me what the scenario is where someone
other than root should be able to send data to this driver.


My scenario is that I am user on some systems where I will not get root 
permissions, so I cannot modify/restart/etc the ntpd/chronyd process, 
which I do not need.  But the sysadmins would entrust me to run e.g. gpsd 
to provide reference data.  This is useful for the further testing of gpsd 
I am doing, and the need to modify/restart gpsd doing that.


Cheers,
Håkan




On Mon, 25 Jan 2010, Håkan Johansson wrote:



Hi,

ntpd creates the shm refclock segments 2 and 3 with permissions 0666
(previously 0777), allowing also non-root users to provide synchronisation
data when these segments are set up.  The attached patch changes chrony to do
that to (currently 0700 for all segments).  It also changes the permissions
from 7 to 6, i.e. removing the useless execute-bits.

Cheers,
Håkan



--
William G. Unruh   |  Canadian Institute for| Tel: +1(604)822-3273
Physics  | Advanced Research  | Fax: +1(604)822-5324
UBC, Vancouver,BC  |   Program in Cosmology | un...@physics.ubc.ca
Canada V6T 1Z1 |  and Gravity   |  www.theory.physics.ubc.ca/

[chrony-dev] shm permissions

[Håkan Johansson]

Hi,

ntpd creates the shm refclock segments 2 and 3 with permissions 0666 
(previously 0777), allowing also non-root users to provide synchronisation 
data when these segments are set up.  The attached patch changes chrony to 
do that to (currently 0700 for all segments).  It also changes the 
permissions from 7 to 6, i.e. removing the useless execute-bits.


Cheers,
Håkandiff --git a/refclock_shm.c b/refclock_shm.c
index b3b689b..9f46a0c 100644
--- a/refclock_shm.c
+++ b/refclock_shm.c
@@ -56,12 +56,18 @@ struct shmTime {
 };
 
 static int shm_initialise(RCL_Instance instance) {
-  int id, param;
+  int id, param, perm;
   struct shmTime *shm;
 
   param = atoi(RCL_GetDriverParameter(instance));
 
-  id = shmget(SHMKEY + param, sizeof (struct shmTime), IPC_CREAT | 0700);
+  if (param < 2) {
+perm = 0700;
+  } else {
+perm = 0777;
+  }
+
+  id = shmget(SHMKEY + param, sizeof (struct shmTime), IPC_CREAT | perm);
   if (id == -1) {
 LOG_FATAL(LOGF_Refclock, "shmget() failed");
 return 0;

[chrony-dev] NTPv4 ?

[Håkan Johansson]

It seems newer versions of ntpd sends client requests with version set to 
4, that therefore are ignored by chronyd only accepting 3.  At least the 
basic packet format looks the same, so one could accept those and send 
responses?


Cheers,
Håkan

Re: [chrony-dev] chronyc linear fit data point dump

[Håkan Johansson]

On Fri, 11 Dec 2009, Bill Unruh wrote:


On Fri, 11 Dec 2009, Håkan Johansson wrote:



Hi,

I could not find a command in chronyc to dump all the currently active data
points used in the linear fit for a source.  This list together with the
residuals would be nice to see what chronyd is up to.  For monitoring, I'm
using (and quite happy with):


Not sure what you would want. Of course to some extent the offsets measured
and reported in measurement.log are used to determine that linear fit. But in
addition, those offsets are continually corrected for the changes in offset
and rate that chrony impliments, so the linear regression in on values which
can differ significantly from the measured offsets. What do you mean by "what
chrony is up to"? How would these values help you in any sense?


The idea would be to see this process of the raw data being continuously 
adjusted in real-time.  As sort of an educational tool.

[chrony-dev] chronyc linear fit data point dump

[Håkan Johansson]

Hi,

I could not find a command in chronyc to dump all the currently active 
data points used in the linear fit for a source.  This list together with 
the residuals would be nice to see what chronyd is up to.  For monitoring, 
I'm using (and quite happy with):


watch -n 1 "./chronyc sources ; ./chronyc sourcestats ; ./chronyc tracking"

Cheers,
Håkan

Re: [chrony-dev] refclock prefer and log

[Håkan Johansson]

I'm testing chrony (current git) with two GPS reference clocks, but am
suffering from chrony moving between the two equally good sources as
reference clock.


In what sense suffering? Those two clocks should be equivalent to better than
a microsecond if you are using pps. If not, then it might well depend on the
length of the sentences being issued.  What are you finding?


Yes, they are giving the same time, within about 1-3 us, often less.  Std 
dev around 0.8-1.5 us.  I guess most jitter comes from the interrupt 
latency (measured once with a scope, is about 20 us, jitter by ~2 ms) 
until gpsd picks the pulse.  I've one gps pps later by 10 ms to not have 
the PPS pulses on top of each other, and the other serial messages are not 
in that window.


Cheers,
Håkan