Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sat Jun 27, 2009 0:29 Post subject: [Solved] NTP Not Working
Guys, Over the this last week, I upgraded all of my Linksys WRT54G's to 12318 and 12319. ( have 2 TM's, a v2, v6,& v8). One of the TM's is the gateway and is looking to pool.us.ntp.org. the rest are looking to it. Non of them are actually updating their clocks. Is this a problem with the new builds (I upgraded from 10188 and earlier, and all were working then) or did I forget to set something. I have checked each several times and they are configured to enable NTP, and have all the settings set on the page where NTP is enabled. I am mystified at this point, and getting tired of all my systems having different time.
All help is appreciated. _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
Last edited by poundjd on Sun Jun 28, 2009 19:42; edited 1 time in total
Leave the ntp server blank and make sure that all routers using the gateway as a gateway have the gateway set in their basic setup page....it will work. At least it does with 12307 and 12360... _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sat Jun 27, 2009 16:48 Post subject:
I did as you suggested even though I can think of no way that a normal build of NTP would behave in this fashion.
Because of the time difference I'll give them a few hours to cook and see if any of them coalesces into some sibilance of sanity.
I also noticed something else. all of the 12318 routers did not reboot when I changed the NTP server, and the 12319 routers did.
Should I move to a newer build, 319 was the one recommended earlier this week, (6/19/09) and I just went to that directory and down loaded the images that I needed. but the MEGA and STD builds were 318.
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
I have never had a situation where I changed something on the basic setup page and the router did not reboot. Did you hit apply?
I would suggest the 12360 build on all units. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sun Jun 28, 2009 2:28 Post subject:
All,
I updated to "DD-WRT v24-sp2 (06/22/09) mega - build 12360M NEWD Eko" on the TM's, std on the V2, and micro on both the V6 and V8, and NTP is fixed.
My mega and std builds do not reboot when i make NTP changes on basic setup page. The micro's do. Don't understand that. but suspect that it is due to memory.
Also on the upgrades, I was able to upgrade all of them in place. The did not lose there data, and did not reset to new password. - I did have two web windows open to each router when I updated it. I planed to reenter the data once the update was done, but did not need to. I don't understand that either.
I have also noticed that a lot of the help pages are in need of major help or totally missing, but that is a story for another topic.
Thanks,
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
Posted: Sun Jun 28, 2009 8:08 Post subject: Re: NTP Not Working
poundjd wrote:
Guys, Over the this last week, I upgraded all of my Linksys WRT54G's to 12318 and 12319. ( have 2 TM's, a v2, v6,& v. One of the TM's is the gateway and is looking to pool.us.ntp.org. the rest are looking to it. Non of them are actually updating their clocks.
All help is appreciated.
I am not surprised since the correct url is us.pool.ntp.org
I have made a comment on your enhancement request in the Trac and suggested a GUI setting for update interval.
Multiple NTP servers doesn't take care of the time drift that occurs in all computers which doesn't have a high precision real-time clock.
Beeing able to update the clock at specified intervals is the solution to time drift in our routers.
When requesting an enhancement one has to understand the consequences of it and make reasonable requests, otherwise one will get nowhere with the developers.
10 + 10 servers will have to be stored in nvram and will take up around 400 bytes of something that we are already running short of.
Add to that the code needed for the GUI change and the extra code for ntp client - this is flash memory but we don't have much of that left either. _________________ Kernel panic: Aiee, killing interrupt handler!
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sun Jun 28, 2009 19:25 Post subject: [SOLVED]
Yes the typo was in the post not in the configurations.
Your discussion about NTP causes me to ask a question, What Version of NTP is used in the Build?
ntpd v4 does not have a separate client and server, they are one code base. And NTP is designed to pole several systems and select the best one to synchronize to. It is not designed to simply synchronize to one source. That defeats a major reason it is used.
Setting an "update interval" is completely contrary to the core functionality of NTP. One of the most important things that the software does is determine what the needed polling interval should be. This is based on the observed characteristics of the networks that the packets traverse to get from NTP system to NTP system, and the internal system clock. This is calculated independently for every NTP server that a system polls.
I have seen much less powerful systems with much worse internal clocks keep time within a couple 10's of milliseconds for months using NTP.
From what your saying, i get the impression that what is actually happening is the equivalent doing a TIME OF DAY check a few times a day and just setting the internal clock. NTP keeps history on the clock skew and adjusts for it so that more stable time is kept.
SO are they actually building a NTP client/server into the builds or something else and just calling it NTP?
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sun Jun 28, 2009 20:11 Post subject:
Can we agree to disagree, I run a full NTP configuration on all my systems (I am wondering about dd-wrt) because of my need for ACCURATE and STABLE time.
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
You should keep in mind, that we have limited space in flash. So, ntp is probably stripped down. And, in my opinion the function of ntp in dd-wrt is absolutely enough, because there is no RTC in most of the "cheap" devices and having a stable timebase for logging is all i need.
You are right, the purpose of the ntp client in dd-wrt is to have a relatively correct timestamp in the logs.
Therefore it is only a client not a server and from what I can see it is BusyBox rdate command that is being used.
It occupies around 700 bytes of our program space. _________________ Kernel panic: Aiee, killing interrupt handler!
Setting an "update interval" is completely contrary to the core functionality of NTP. One of the most important things that the software does is determine what the needed polling interval should be. This is based on the observed characteristics of the networks that the packets traverse to get from NTP system to NTP system, and the internal system clock. This is calculated independently for every NTP server that a system polls.
And still most ntp clients has the switch -i for setting the update interval..
We are not using a sofisticated ntp server software here, only a tiny client.
I did a quick search on the net and found ntpV4 code sizes to vary between 500-700Kb (the latter win32).
The keyword , which is pointed out in my first post here, is to be realistic and ask for enhancements which are possible to implement.
Increasing the code size with 0.5Mb for the purpose of gaining milliseconds of accuracy is not realistic.
You can take a look at the drift file for most of the ntp servers on the net and you will see that it doesn't make that big difference which one you choose to get your time from.
poundjd wrote:
I have seen much less powerful systems with much worse internal clocks keep time within a couple 10's of milliseconds for months using NTP.
From what your saying, i get the impression that what is actually happening is the equivalent doing a TIME OF DAY check a few times a day and just setting the internal clock. NTP keeps history on the clock skew and adjusts for it so that more stable time is kept.
-jeff
As far as I understand, dd-wrt does a NTP request and sets the routers time at restart and is thereafter relying on cpu timer ticks for incrementing time.
This causes time drift and the simple way to compensate for that is to do a NTP time update at regular intervals, once a day should be enough for keeping time within an accuracy of a second.
There are users with routers that has an uptime of months, they will also have a big drift in their router time.. _________________ Kernel panic: Aiee, killing interrupt handler!
When we were having major problems with the clock in the Asus WL520GU, there was a cron job script that was used to update the clock every five minutes. _________________ SIG:
I'm trying to teach you to fish, not give you a fish. If you just want a fish, wait for a fisherman who hands them out. I'm more of a fishing instructor.
LOM: "If you show that you have not bothered to read the forum announcements or to follow the advices in them then the level of help available for you will drop substantially, also known as Murrkf's law.."
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Fri Jul 10, 2009 2:17 Post subject:
Well I am not surprised now that I have seen such variance in my routers times. Using Rdate for time is REALLY different than using NTP, even a "Striped Down Client" All of the NTP clients are supposed to have clock drift correction. Rdate does not do this.
If the decision was to use Rdate because it is small and we all know what a premium space is at in the flash.
I am just upset that the claim NTP and then really only do an Rdate request.....
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!
I think the so-called NTP in DD-WRT is just a SNTP client,the equivalent of ntpdate. It resets the local clock to the remote one, no slews it. So you will get uncertain jitter of time when you query it, depending on when you issue query.
Joined: 05 Oct 2008 Posts: 21 Location: Fayetteville, PA, USA 17222
Posted: Sun Jul 12, 2009 18:53 Post subject:
Yes that is the conciseness of the group here.
-jeff _________________ WRT54G-TM (2)
WRT54G V2.0
WRT54G V6
WRT54G V8
Check out www.ebox-platform.com
To your Own Morals be True!