• Score is low and not raising

    From ProGeek@21:1/5 to All on Mon Jun 7 22:03:22 2021
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ProGeek@21:1/5 to William Unruh on Tue Jun 8 01:14:57 2021
    hello,

    I am using Chrony as a server.

    i manage to lower the offset to 97ms hope is OK like this...or i will try new settings

    now chrony stats reports are like this:

    MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* GPS0 0 3 377 5 -1167us[-2018us] +/- 98ms #x PPM1 0 3 377 4 -406ms[ -406ms] +/- 2497us #? PPS0 0 3 0 - +0ns[ +0ns] +/- 0ns

    On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote:
    You give no details at all so it is hard to figure out what you are
    doing never mind what is wrong. It seems you have a 500 ms (1/2 second) offset, which really is pretty terrible. Wrong edge on the interrupt?
    ( and at the end it inexplicably drops to 100ms, which is still pretty terrible but better-- what changed)

    Hook you Pis up to the network, and compare your PPS yourself to some
    pool server. That way you can debug yourself instead of others doing it
    for you.
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to ProGeek on Tue Jun 8 07:49:51 2021
    You give no details at all so it is hard to figure out what you are
    doing never mind what is wrong. It seems you have a 500 ms (1/2 second)
    offset, which really is pretty terrible. Wrong edge on the interrupt?
    ( and at the end it inexplicably drops to 100ms, which is still pretty
    terrible but better-- what changed)

    Hook you Pis up to the network, and compare your PPS yourself to some
    pool server. That way you can debug yourself instead of others doing it
    for you.


    On 2021-06-08, ProGeek <progeekro@gmail.com> wrote:
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to ProGeek on Tue Jun 8 08:23:07 2021
    On 2021-06-08, ProGeek <progeekro@gmail.com> wrote:
    hello,

    I am using Chrony as a server.

    i manage to lower the offset to 97ms hope is OK like this...or i will try new settings

    now chrony stats reports are like this:

    MS Name/IP address Stratum Poll Reach LastRx Last sample
    ===============================================================================
    #* GPS0 0 3 377 5 -1167us[-2018us] +/- 98ms
    #x PPM1 0 3 377 4 -406ms[ -406ms] +/- 2497us
    #? PPS0 0 3 0 - +0ns[ +0ns] +/- 0ns

    Well, pps is not working at all. I have no idea what PPM1 is, and your
    system is using GPS0 as its source, which is not a good idea, since it
    will be out by many may ms. If you got pps to work, it should have an
    accuracy or a few micro seconds, not many ms. (GPS is the NMEA sentences
    which are always delayed by about over 100ms.)

    So, figure out why pps is not working, and fix that. In the meantime
    without your system actually set up properly in itself, you should not
    be going onto the pool and leading others astray.


    On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote:
    You give no details at all so it is hard to figure out what you are
    doing never mind what is wrong. It seems you have a 500 ms (1/2 second)
    offset, which really is pretty terrible. Wrong edge on the interrupt?
    ( and at the end it inexplicably drops to 100ms, which is still pretty
    terrible but better-- what changed)

    Hook you Pis up to the network, and compare your PPS yourself to some
    pool server. That way you can debug yourself instead of others doing it
    for you.
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to ProGeek on Tue Jun 8 16:06:09 2021
    As I said, at a minimum run a test in which you have at least one
    network pool source to compare your system with some independent outside system. Why demand that pool people do it for you? Since you want to be
    on the pool you must have network connectivity.

    On 2021-06-08, ProGeek <progeekro@gmail.com> wrote:
    ok,
    fixed.

    now stats looks like this:


    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
    ==============================================================================
    GPS0 6 3 82 +16.101 190.363 -80ms 1527us
    SHM1 7 4 94 +0.000 0.020 -740ms 239ns
    PPS0 7 4 94 +0.000 0.020 +0ns 239ns

    MS Name/IP address Stratum Poll Reach LastRx Last sample
    ===============================================================================
    #? GPS0 0 4 377 10 -80ms[ -80ms] +/- 100ms
    #- SHM1 0 4 377 11 -740ms[ -740ms] +/- 1000us
    #* PPS0 0 4 377 11 +264ns[ +922ns] +/- 208ns

    Hope that will make the score higher


    On Tuesday, June 8, 2021 at 11:23:09 AM UTC+3, William Unruh wrote:
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    hello,

    I am using Chrony as a server.

    i manage to lower the offset to 97ms hope is OK like this...or i will try new settings

    now chrony stats reports are like this:

    MS Name/IP address Stratum Poll Reach LastRx Last sample
    ===============================================================================
    #* GPS0 0 3 377 5 -1167us[-2018us] +/- 98ms
    #x PPM1 0 3 377 4 -406ms[ -406ms] +/- 2497us
    #? PPS0 0 3 0 - +0ns[ +0ns] +/- 0ns
    Well, pps is not working at all. I have no idea what PPM1 is, and your
    system is using GPS0 as its source, which is not a good idea, since it
    will be out by many may ms. If you got pps to work, it should have an
    accuracy or a few micro seconds, not many ms. (GPS is the NMEA sentences
    which are always delayed by about over 100ms.)

    So, figure out why pps is not working, and fix that. In the meantime
    without your system actually set up properly in itself, you should not
    be going onto the pool and leading others astray.

    On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote:
    You give no details at all so it is hard to figure out what you are
    doing never mind what is wrong. It seems you have a 500 ms (1/2 second) >> >> offset, which really is pretty terrible. Wrong edge on the interrupt?
    ( and at the end it inexplicably drops to 100ms, which is still pretty
    terrible but better-- what changed)

    Hook you Pis up to the network, and compare your PPS yourself to some
    pool server. That way you can debug yourself instead of others doing it >> >> for you.
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ProGeek@21:1/5 to William Unruh on Tue Jun 8 08:30:31 2021
    ok,
    fixed.

    now stats looks like this:


    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== GPS0 6 3 82 +16.101 190.363 -80ms 1527us SHM1 7 4 94 +0.000 0.020 -740ms 239ns PPS0 7 4 94 +0.000 0.020 +0ns 239ns

    MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #? GPS0 0 4 377 10 -80ms[ -80ms] +/- 100ms #- SHM1 0 4 377 11 -740ms[ -740ms] +/- 1000us #* PPS0 0 4 377 11 +264ns[ +922ns] +/- 208ns

    Hope that will make the score higher


    On Tuesday, June 8, 2021 at 11:23:09 AM UTC+3, William Unruh wrote:
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    hello,

    I am using Chrony as a server.

    i manage to lower the offset to 97ms hope is OK like this...or i will try new settings

    now chrony stats reports are like this:

    MS Name/IP address Stratum Poll Reach LastRx Last sample
    ===============================================================================
    #* GPS0 0 3 377 5 -1167us[-2018us] +/- 98ms
    #x PPM1 0 3 377 4 -406ms[ -406ms] +/- 2497us
    #? PPS0 0 3 0 - +0ns[ +0ns] +/- 0ns
    Well, pps is not working at all. I have no idea what PPM1 is, and your
    system is using GPS0 as its source, which is not a good idea, since it
    will be out by many may ms. If you got pps to work, it should have an accuracy or a few micro seconds, not many ms. (GPS is the NMEA sentences which are always delayed by about over 100ms.)

    So, figure out why pps is not working, and fix that. In the meantime
    without your system actually set up properly in itself, you should not
    be going onto the pool and leading others astray.

    On Tuesday, June 8, 2021 at 10:49:53 AM UTC+3, William Unruh wrote:
    You give no details at all so it is hard to figure out what you are
    doing never mind what is wrong. It seems you have a 500 ms (1/2 second)
    offset, which really is pretty terrible. Wrong edge on the interrupt?
    ( and at the end it inexplicably drops to 100ms, which is still pretty
    terrible but better-- what changed)

    Hook you Pis up to the network, and compare your PPS yourself to some
    pool server. That way you can debug yourself instead of others doing it
    for you.
    On 2021-06-08, ProGeek <prog...@gmail.com> wrote:
    Hello,
    i have 2 IPv6 servers made publicly some days ago.
    Servers are build around Raspberry PI and U-blox GPS modules, using PPS and GPIO.
    The problem is that i try to make the servers available in pool, but i get constant -20 on rating.

    Any idea how can i improve the score?

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    https://www.ntppool.org/scores/2a02:2f04:a0e:9199:99::2

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Roger@21:1/5 to progeekro@gmail.com on Tue Jun 8 20:02:02 2021
    On Tue, 8 Jun 2021 08:30:31 -0700 (PDT), ProGeek
    <progeekro@gmail.com> wrote:

    Hope that will make the score higher

    Excuse me for my rudeness but forget the bloody scores. You need
    to concentrate on having low offsets for months at a time. Look
    at these two servers which are both using GPS.

    https://www.pool.ntp.org/scores/212.159.133.83 https://www.pool.ntp.org/scores/185.57.191.229

    Look at the left hand axes; 16 to -4 ms for the first, 0.2 to
    -0.6 ms for the second. Your graphs range from 2 to -2 seconds.
    Both servers are currently showing an offset of 500 ms. Useless
    to the pool at present. Once your offsets are good the scores
    will automatically be good.
    --
    Roger

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andreas Mattheiss@21:1/5 to All on Tue Jun 8 21:42:53 2021
    Hello,

    just as additional source of information: I have a similar setup here
    (ublox PPS into a proper serial port of a PC) and I see a stable offset of
    -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
    though.

    Regards
    Andreas

    --
    CAMILLE: What do you think?
    KRYTEN: Well, I -- I think you look... really nice.
    CAT: Nice? She looks like something that dropped out of the Sphinx's nose!

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to Roger on Tue Jun 8 20:48:54 2021
    On 2021-06-08, Roger <invalid@invalid.invalid> wrote:
    On Tue, 8 Jun 2021 08:30:31 -0700 (PDT), ProGeek
    <progeekro@gmail.com> wrote:

    Hope that will make the score higher

    Excuse me for my rudeness but forget the bloody scores. You need
    to concentrate on having low offsets for months at a time. Look
    at these two servers which are both using GPS.

    https://www.pool.ntp.org/scores/212.159.133.83 https://www.pool.ntp.org/scores/185.57.191.229

    Look at the left hand axes; 16 to -4 ms for the first, 0.2 to
    -0.6 ms for the second. Your graphs range from 2 to -2 seconds.
    Both servers are currently showing an offset of 500 ms. Useless
    to the pool at present. Once your offsets are good the scores
    will automatically be good.

    Actually for GPS discipline, the offsets should be much better than 1ms.
    It should be more like 1us, ie 1000 times better. Of course much of the
    trouble could be due to connection problems between the machine and
    Newark NJ which is trying to measure the offset (but even then 1ms seems
    like a lot).

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to Andreas Mattheiss on Wed Jun 9 16:56:01 2021
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here
    (ublox PPS into a proper serial port of a PC) and I see a stable offset of
    -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
    though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter ====================================================================== o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001 +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054 *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From ProGeek@21:1/5 to chris on Wed Jun 9 14:00:57 2021
    On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here (ublox PPS into a proper serial port of a PC) and I see a stable offset of -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter ====================================================================== o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
    +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
    *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris
    this is what i see on sourcestats:

    210 Number of sources = 7
    .- Number of sample points in measurement set.
    / .- Number of residual runs with same sign.
    | / .- Length of measurement set (time).
    | | / .- Est. clock freq error (ppm).
    | | | / .- Est. error in freq.
    | | | | / .- Est. offset.
    | | | | | | On the -.
    | | | | | | samples. \
    | | | | | | | Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev ============================================================================== GPS0 12 6 176 -29.089 42.914 -8857us 1790us SHM1 12 7 178 +0.000 0.010 -530ms 435ns PPS0 12 7 178 +0.001 0.011 +3ns 445ns blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms 188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us

    if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers.

    my settings are like this:

    # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
    refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646

    # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
    refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 0.5300

    # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
    refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer delay 0.50

    something is off but i can't pinpoint what

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to ProGeek on Thu Jun 10 00:40:08 2021
    On 06/09/21 22:00, ProGeek wrote:
    On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here
    (ublox PPS into a proper serial port of a PC) and I see a stable offset of >>> -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
    though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ======================================================================
    o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
    +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
    *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris
    this is what i see on sourcestats:

    210 Number of sources = 7
    .- Number of sample points in measurement set.
    / .- Number of residual runs with same sign.
    | / .- Length of measurement set (time).
    | | / .- Est. clock freq error (ppm).
    | | | / .- Est. error in freq.
    | | | | / .- Est. offset.
    | | | | | | On the -.
    | | | | | | samples. \
    | | | | | | |
    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
    ==============================================================================
    GPS0 12 6 176 -29.089 42.914 -8857us 1790us
    SHM1 12 7 178 +0.000 0.010 -530ms 435ns
    PPS0 12 7 178 +0.001 0.011 +3ns 445ns
    blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms
    188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us
    time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us
    time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us

    if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers.

    my settings are like this:

    # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
    refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646

    # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
    refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 0.5300

    # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
    refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer delay 0.50

    something is off but i can't pinpoint what

    Just using a standard ntpd here, as it's more than adequate for the
    task, with minimum granularity in microseconds. Does look like there
    is something seriously wrong, as the gps is 8mS out, and should be
    fractions of a mS if working right.

    What I would try is to strip out all except the pps and gps sources
    and see what the offset looks like. Also, please post the ntpd.conf
    file, as that can skew everything if misconfigured. Finally, check
    the polarity of the pps signal, as the ~500mS offset for several
    sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
    ntp.conf file has a line to define that...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to ProGeek on Thu Jun 10 02:13:04 2021
    On 2021-06-09, ProGeek <progeekro@gmail.com> wrote:
    On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here
    (ublox PPS into a proper serial port of a PC) and I see a stable offset of >> > -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
    though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ======================================================================
    o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
    +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
    *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris
    this is what i see on sourcestats:

    210 Number of sources = 7
    .- Number of sample points in measurement set.
    / .- Number of residual runs with same sign.
    | / .- Length of measurement set (time).
    | | / .- Est. clock freq error (ppm).
    | | | / .- Est. error in freq.
    | | | | / .- Est. offset.
    | | | | | | On the -.
    | | | | | | samples. \
    | | | | | | |
    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
    ==============================================================================
    GPS0 12 6 176 -29.089 42.914 -8857us 1790us
    SHM1 12 7 178 +0.000 0.010 -530ms 435ns
    PPS0 12 7 178 +0.001 0.011 +3ns 445ns
    blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms
    188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us
    time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us
    time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us

    if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers.

    Sorry but that is nuts.
    Your external sources are 500ms ( 1/2 sec) off from the internal ones.
    But that is probably because you told your system to screw up the
    internal sources.


    my settings are like this:

    # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
    refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646

    Why that offset? and why precision of 1e-1?

    # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
    refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 0.5300

    Why that offset?
    Also, why are you having both gpsd and pps0 delivering data? It is the
    same pps. And they fight each other-- when one interrupt is processing,
    the other one is locked out. This makes the accuracy of pps less than
    it should be (by a factor of about 10)
    Tell gpsd not to use the PPS.


    # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
    refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer delay 0.50

    Why that delay?

    HOw about getting rid of all of the offset and delay stuff on your
    internal sources.

    something is off but i can't pinpoint what

    Sure is.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to chris on Thu Jun 10 02:17:58 2021
    On 2021-06-09, chris <chris-nospam@tridac.net> wrote:
    On 06/09/21 22:00, ProGeek wrote:
    On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here
    (ublox PPS into a proper serial port of a PC) and I see a stable offset of >>>> -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd
    though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ======================================================================
    o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
    +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
    *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris
    this is what i see on sourcestats:

    210 Number of sources = 7
    .- Number of sample points in measurement set. >> / .- Number of residual runs with same sign. >> | / .- Length of measurement set (time). >> | | / .- Est. clock freq error (ppm). >> | | | / .- Est. error in freq.
    | | | | / .- Est. offset.
    | | | | | | On the -.
    | | | | | | samples. \
    | | | | | | |
    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
    ==============================================================================
    GPS0 12 6 176 -29.089 42.914 -8857us 1790us
    SHM1 12 7 178 +0.000 0.010 -530ms 435ns
    PPS0 12 7 178 +0.001 0.011 +3ns 445ns
    blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms
    188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us
    time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us
    time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us

    if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers.

    my settings are like this:

    # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
    refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646 >>
    # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
    refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 0.5300

    # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
    refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer delay 0.50

    something is off but i can't pinpoint what

    Just using a standard ntpd here, as it's more than adequate for the
    task, with minimum granularity in microseconds. Does look like there
    is something seriously wrong, as the gps is 8mS out, and should be
    fractions of a mS if working right.

    No, it should not be. GPS is the NMEA sentences from the gps device. It
    is usually delayed by from .1 to .3 sec. Ie, it keeps terrible time.
    It is the PPS that is spot on to the ns level.

    What I would try is to strip out all except the pps and gps sources
    and see what the offset looks like. Also, please post the ntpd.conf

    He did post the sentences from the chrony.conf file ( the equivalent to
    the ntpd.conf file) and they are weird.

    file, as that can skew everything if misconfigured. Finally, check
    the polarity of the pps signal, as the ~500mS offset for several
    sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
    ntp.conf file has a line to define that...

    It may be that he has chosen the wrong polarity, but I suspect he has
    simply chosen the wrong options (the delay and offset options).




    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From chris@21:1/5 to William Unruh on Thu Jun 10 11:38:55 2021
    On 06/10/21 03:17, William Unruh wrote:
    On 2021-06-09, chris<chris-nospam@tridac.net> wrote:
    On 06/09/21 22:00, ProGeek wrote:
    On Wednesday, June 9, 2021 at 6:56:04 PM UTC+3, chris wrote:
    On 06/08/21 20:42, Andreas Mattheiss wrote:
    Hello,

    just as additional source of information: I have a similar setup here >>>>> (ublox PPS into a proper serial port of a PC) and I see a stable offset of
    -3 ms to 3 servers on the net (-3 ms to any of them). I'm using ntpd >>>>> though.

    Regards
    Andreas

    This is what I see at the ntp host here:

    chris@ntp-host:~ % ntpq -pn
    remote refid st t when poll reach delay offset jitter
    ====================================================================== >>>> o127.127.22.0 .PPS. 0 l 1 8 377 0.000 0.000 0.001
    +192.9.200.168 .GPS. 1 u 10 64 377 0.193 0.001 0.054
    *192.9.200.169 .GPS. 1 u 7 64 377 0.354 0.008 0.046

    Using mini pc host with two network interfaces, internet and internal
    network facing. FreeBSD 12 with ttl pps into the serial port dcd line
    via a ttl to rs232 converter...

    Chris
    this is what i see on sourcestats:

    210 Number of sources = 7
    .- Number of sample points in measurement set.
    / .- Number of residual runs with same sign.
    | / .- Length of measurement set (time). >>> | | / .- Est. clock freq error (ppm).
    | | | / .- Est. error in freq.
    | | | | / .- Est. offset.
    | | | | | | On the -.
    | | | | | | samples. \
    | | | | | | |
    Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
    ==============================================================================
    GPS0 12 6 176 -29.089 42.914 -8857us 1790us
    SHM1 12 7 178 +0.000 0.010 -530ms 435ns
    PPS0 12 7 178 +0.001 0.011 +3ns 445ns
    blackmamba-g0.eff.ro 2 0 77 -0.005 2000.000 +501ms 4000ms
    188.213.49.35 9 6 184 -0.748 21.608 +492ms 721us
    time.cloudflare.com 6 4 81 +1.162 9.574 +500ms 72us
    time.cloudflare.com 14 11 168 +0.502 0.939 +500ms 42us

    if i get the results from PPS0 the offset is low, but is still reported high. and also correspond with the external time servers.

    my settings are like this:

    # SHM(0), gpsd: NMEA data from shared memory provided by gpsd
    refclock SHM 0 refid GPS0 poll 4 precision 1e-1 trust noselect offset 0.646 >>>
    # SHM(1), gpsd: PPS0 data from shared memory provided by gpsd
    refclock SHM 1 refid SHM1 poll 4 precision 1e-3 lock GPS0 trust noselect offset 0.5300

    # PPS: /dev/pps0: Kernel-mode PPS ref-clock for the precise seconds
    refclock PPS /dev/pps0 refid PPS0 poll 4 precision 1e-7 lock GPS0 trust prefer delay 0.50

    something is off but i can't pinpoint what

    Just using a standard ntpd here, as it's more than adequate for the
    task, with minimum granularity in microseconds. Does look like there
    is something seriously wrong, as the gps is 8mS out, and should be
    fractions of a mS if working right.

    No, it should not be. GPS is the NMEA sentences from the gps device. It
    is usually delayed by from .1 to .3 sec. Ie, it keeps terrible time.
    It is the PPS that is spot on to the ns level.

    Well, we know that, but if there is an available PPS, that becomes
    the primary reference for the local system.


    What I would try is to strip out all except the pps and gps sources
    and see what the offset looks like. Also, please post the ntpd.conf

    He did post the sentences from the chrony.conf file ( the equivalent to
    the ntpd.conf file) and they are weird.

    Not familar with chrony, but why not go back to basics, run a stock
    ntpd, which works out of the box. Why make life difficult, when ntpd has
    more than adequate precision for the task ?. Experiment with other
    solutions once the basics are known working and experience gained.


    file, as that can skew everything if misconfigured. Finally, check
    the polarity of the pps signal, as the ~500mS offset for several
    sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
    ntp.conf file has a line to define that...

    It may be that he has chosen the wrong polarity, but I suspect he has
    simply chosen the wrong options (the delay and offset options).


    If the 1pps signal has a 50% m/s ratio, then the ~0.5second offset on
    the external sources is a glaring indicator of wrong polarity...

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From William Unruh@21:1/5 to chris on Thu Jun 10 17:28:06 2021
    On 2021-06-10, chris <chris-nospam@tridac.net> wrote:

    Not familar with chrony, but why not go back to basics, run a stock
    ntpd, which works out of the box. Why make life difficult, when ntpd has
    more than adequate precision for the task ?. Experiment with other
    solutions once the basics are known working and experience gained.

    chrony IS the basics, just as ntpd is. I believe he is piling on
    options, when he should just try things straightforardly. At present, he
    is telling chrony to offset the GPS and the SHM ( which is another pps,
    which interferes with the kernel pps) by 1/2 sec, and discovers that
    things are out by 1/2 sec.



    file, as that can skew everything if misconfigured. Finally, check
    the polarity of the pps signal, as the ~500mS offset for several
    sources, (0.5 x 1sec), suggest pps input needs an inversion, but the
    ntp.conf file has a line to define that...

    It may be that he has chosen the wrong polarity, but I suspect he has
    simply chosen the wrong options (the delay and offset options).


    If the 1pps signal has a 50% m/s ratio, then the ~0.5second offset on
    the external sources is a glaring indicator of wrong polarity...

    Yes, except most pps signals do not have a 50% ratio. More like a 10%
    ratio. I do not know the UBlock gps unit so it could be weird, or maybe
    he set up the UBLOCk to have a 50% ratio. Or maybe his "offset" commands
    are confusing everything.



    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)