Different in offset?

I got a esp32 ntp sever using gps as time source when i test it, i got fine offest:
hugo@Hugo:~$ ntpdate -q
24 Oct 22:45:16 ntpdate[368030]: no servers can be used, exiting
hugo@Hugo:~$ ntpdate -q time.zetalon.com
server 203.30.14.27, stratum 1, offset -0.115989, delay 0.10777
24 Oct 22:45:25 ntpdate[368087]: adjust time server 203.30.14.27 offset -0.115989 sec
hugo@Hugo:~$ ntpdate -q time.zetalon.com
server 203.30.14.27, stratum 1, offset +0.218531, delay 0.15965
24 Oct 22:48:17 ntpdate[368633]: adjust time server 203.30.14.27 offset +0.218531 sec

However when u test it with Ad-hoc NTP Server Check, the offset is high!!! any idea why and how to fix it??

Results

  1. usdaa1-1tcp71g
    Offset: -1944.76862ms
    RTT: 297.418551ms

  2. ussjc1-1a6a7hp
    Offset: -1503.31495ms
    RTT: 316.710409ms

  3. nlams2-1a6a7hp
    Offset: -1203.1666ms
    RTT: 454.926428ms

Hi hugodonotexit, welcome!

What are you trying to veryfy against what?
Can it be that the time.zetalon.com server distributes a borderline accurate time? The first time i ran a check against it, it reported time as inaccurate (a few minutes later its acceptable, however).

when i test time.zetalon.com (203.30.14.27) using the NTP pool montors i get:


(notice the high offset).

When using an external NTP test website to check against time.zetalon.com i sometimes get:

You might want to use an alternative, external time source.
Are you sure that your server has GPS-sync?

yes i am sure my sercer has gps sync, i also compare it with timewindows.com and pool.ntp.org

hugo@Hugo:~/CBudgie$ python3 test.py
Data from time.windows.com:
Server Time (Unix): 1729779291
Offset: -0.413982 seconds
Hex Data:
±-------------------------------+
| 1c 03 00 e9 00 00 00 74 |
| 00 00 06 b9 19 42 e6 02 |
| ea c4 d4 21 9a 99 a4 81 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db be 70 95 94 |
| ea c4 d4 db be 70 bd d8 |
±-------------------------------+
Data from time.zetalon.com:
Server Time (Unix): 1729779291
Offset: -0.521369 seconds
Hex Data:
±-------------------------------+
| 24 01 06 fa 00 00 01 ff |
| 00 00 08 06 47 50 53 00 |
| ea c4 d4 db aa 0e 62 99 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db aa 0e 62 99 |
| ea c4 d4 db aa 0e e8 d1 |
±-------------------------------+
Data from pool.ntp.org:
Server Time (Unix): 1729779291
Offset: -0.558236 seconds
Hex Data:
±-------------------------------+
| 1c 03 00 e7 00 00 02 6c |
| 00 00 00 54 0a a5 08 0a |
| ea c4 d4 9c 18 08 b5 93 |
| 00 00 00 00 00 00 00 00 |
| ea c4 d4 db e2 47 e0 9f |
| ea c4 d4 db e2 4c 82 56 |

and the these offest and time are very similar

We need more information about the NTP server. It doesn’t behave as expected. As I type this, the root delay is 7.8 msec; a GPS-driven stratum 1 is normally a small value, typically 0. The root dispersion is steady at 31 msec; GPS/stratum 1 should be well under 1 msec.

Over the past several days I see errors of 60 seconds, 1729760431 seconds, even 54 years. At other times the error is small.

Most of my GPS/NTP servers are raspberry pi based. I have no direct experience with the Arduino. The principles are the same though.

What software is being used?
What GPS is being used & how is it connected to the computer?

src: ESP32-GPS-NTP-server/gpsntp.ino at main · Hugodonotexit/ESP32-GPS-NTP-server · GitHub

“Over the past several days I see errors of 60 seconds, 1729760431 seconds, even 54 years. At other times the error is small.” that’s because i was testing it

it doesn’t connect to pc it connected to the internet directly
gps sent a pulse every second which will tiggler the ESP32 to read the time, and reset the built in timer (in microsecond) to 0

Can expand on:
“gps sent a pulse every second which will tiggler the ESP32 to read the time, and reset the built in timer (in microsecond) to 0”

  • What GPS chipset/device is used?
  • How is it physically connected to the ESP32?
  • Is the TCP stack running on the ESP32?
  • Is the NTP protocol implemented on the ESP32?

Is this something that you built / designed? What are your goals for the system?

GPS chipset: NEO-6M

  • Connection: The GPS module is connected to the ESP32’s UART1, using pins 16 (RX) and 17 (TX).
  • PPS Signal: A Pulse Per Second (PPS) signal from the GPS module is connected to GPIO 23 of the ESP32. This signal triggers an interrupt on the ESP32 every second.
  • NTP Protocol: The ESP32 acts as an NTP server, handling requests and sending time data back to clients. The NTP timestamps are derived from the GPS-provided time.
    the TCP stack is running on the ESP32. The ESP32’s Wi-Fi library provides support for TCP/IP networking, allowing it to handle NTP over UDP

That helps, thanks.

It sounds like the ESP32 - Internet connection is WiFi based. that can introduce many milliseconds of jitter. The jitter can be higher when aggressive power savings is used.

The server currently has a somewhat steady offset error of about 200 msec. This shouldn’t happen with a PPS. There are frequent errors of 1 second; sporadically the errors are much higher. The transition between high errors and much lower errors are sudden. The alarm bits (LI field) appears to be unused. This and your previous statements suggest that custom software is being used rather than NTP software most of us are familiar with.

This doesn’t appear to be an NTP Pool issue, at least not yet.