Those delay times should not cause problems. the algorithm uses the delay to calculate the offset from the ntp time stamp. Think of it this way, the ntp server timestamped it at a certain time and it took "X" amount of time to travel to the client so the delay is used to determine the amount of time it took to travel. The algorithm should not throw this out unless it has others to compare to or the clock starts contradicting itself. With a large delay by itself, the clock will be less accurate because the delay is only our approximation of the travel time.
If any of this was true, the desktop ntp would not work, because it would actually have an increased delay due to having to go through the router as well.
It is possible that the stripped down version of ntp that is being used does not have the most updated code, but it should not be that far off. I have pulled and debugged/compared before and they were close.
I've never looked at any ntp client code implementations so have nothing to say about theory.
In practice, I've observed multiple clients (substantial percentage) that had zero ntp issues suddenly develop ntp issues after an ISP change. It appeared that large and inconsistent latency bothered some ntp client implementations but not others. Dd-wrt was not involved in this situation. The principle router in this case (not dd-wrt) had no ntp issues.
The "increased delay" for clients is not relevant with 0.7s ping times unless the LAN/router are from the stone age. From observation, the ntpd code seems much more robust at handling large variable latency than ntp clients so OP's desktop ntpd working fine is not surprising.
I stand by my entware ntpd suggestion if OP's router has a USB port.
@yoyoma2, I hope that you did not take any offense to my previous post, none was meant. If you did I apologize.
I think I know what you are talking about because with the inconsistent latency it is much easier for the algorithms to have less accuracy and thus the clocks can start to contradict. I do admit that depending on the implementation there can be differences, I am familiar with the network time foundations implementation the most because of volunteer time there, one of these days I will take a deep dive into chrony.
Hey guys, sorry for the delay in getting back. I was busy trying out everything remaining that I could think of, and have found the problem:
Firstly, I found that while I had a properly setup up ntpd configuration on my desktop, it was also failing to update system time off NTP servers, just like my router. It gave the appearance of working because my desktop system time was in fact correct, but not because NTP time sync was working.
on the connection from my home ISP:
$ sudo ntpdate -u pool.ntp.org
12 Oct 13:51:19 ntpdate[96058]: no server suitable for synchronization found
Switching to a hotspot setup on on my mobile phone:
$ sudo ntpdate -u pool.ntp.org
12 Oct 13:50:26 ntpdate[95359]: adjust time server 133.243.238.243 offset -0.239665 sec
The problem is my frickin' ISP!
So the question now is, is there any way around this ISP problem?
Last edited by kinleyd on Mon Oct 12, 2020 10:40; edited 2 times in total
I've never looked at any ntp client code implementations so have nothing to say about theory.
In practice, I've observed multiple clients (substantial percentage) that had zero ntp issues suddenly develop ntp issues after an ISP change. It appeared that large and inconsistent latency bothered some ntp client implementations but not others. Dd-wrt was not involved in this situation. The principle router in this case (not dd-wrt) had no ntp issues.
The "increased delay" for clients is not relevant with 0.7s ping times unless the LAN/router are from the stone age. From observation, the ntpd code seems much more robust at handling large variable latency than ntp clients so OP's desktop ntpd working fine is not surprising.
I stand by my entware ntpd suggestion if OP's router has a USB port.
Thank you for the entware recommendation. That opened my eyes to a whole new world. I've enjoyed playing with ntpd, ntp-utils, nmap downloaded from entware, even though it didn't work given the problem being with the ISP.
Since my desktop's ntpd service is running (even though itself not getting NTP time syncs), I am able to at least sync my router time off the desktop using dd-wrt's ntpclient, as you suggested also. So that confirms that there is nothing wrong with dd-wrt's ntpclient, which is also good to know.
So all round progress, even if the problem is not completely solved.
The biggest bonus is all the reading I've been doing - I know a bit more than I did before!
Thanks for reporting back. Much of the value of forums comes from the OP's conclusion.
Entware is super and they will fix bugs/upgrade packages logged on their github project given enough time. Adding a gps to ntpd is a fun little project and gives you a satellite based time source independant of your ISP. If I were adding a gps today I might add it to an always running raspberry pi instead of to dd-wrt.
Thanks for reporting back. Much of the value of forums comes from the OP's conclusion.
Entware is super and they will fix bugs/upgrade packages logged on their github project given enough time. Adding a gps to ntpd is a fun little project and gives you a satellite based time source independant of your ISP. If I were adding a gps today I might add it to an always running raspberry pi instead of to dd-wrt.
Happy to contribute a bit, and very grateful for all the time shared by you, wildlion and others.
Thanks, exploring a gps to raspberry pi option is looking interesting. I will have to check that out!
The initial post for help was made because the NTP Client settings in the dd-wrt gui wasn't working. I drew attention to the ntpclient and ntpd tools bundled with dd-wrt firmware to see if the fault lay there.
Other suspects were my configuration settings and network latency.
In the end, after much futzing around, the problem turned out to be my ISP which is blocking NTP pings. So nothing wrong with the rest of the suspects.
So I finally used htpdate to sync my desktop and ntpd time, with the router syncing against my desktop. Seems as good as it can get for now.
My next project when I have some free time is to use a GPS tracking device to setup my router as my own independent NTP server. I'm looking forward to that!
Thanks @Wildlion, that link looks like the mother lode to me! I even see contributions by Eric Raymond in the hardware section. I think I'm going to take a great big swing at this one.
So, many thanks @Wildlion and @yoyoma2 - this little adventure is proving to be a heckuva nice experience.
Posted: Sun Dec 06, 2020 16:36 Post subject: NTP sync issue with switch setup - SOLUTION
i have been struggling with a time issue for weeks. finally figured it out. my issue is with my linksys 1200v2 using 40559big. this router is setup as a switch with dhcp disabled. i have been trying all sorts of solutions regarding ntp servers, ip address, and start/stop of the services. nothing was permanent. my issue was that i had the router configured as an access point. once i changed it to router mode, it got the wan IP from the gateway router and the time immediately synced. i know, rookie mistake. hope this helps others if you have this same setup with a second router being used as a switch.
