What's new

Does RT-N66U have a real time clock? (trying to read system log)

  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

ags

Regular Contributor
Looking at the system log since initial startup, I see timestamps that don't make any sense. First entries are Jan 1 00:00:xx, which makes sense (before any time could be set, using NTP for instance - I presume this is also 1970, I wish the year was included in the timestamp).

Then I see entries for the actual date when first connected (Feb 11), which also makes sense. But then I see some entries for Feb 10, then Feb 11. My TZ is UTC-8, and the logs show that when time "runs backwards" its moving back by 8 hours. I'm guessing that there are some messages being generated by modules that are not using the correct API and/or ignoring the TZ offset. So I have a probable explanation for that.

However, I am also seeing entries for Dec 31, 16:00:xx. This is 8 hours before midnight Jan 1, so that may be the TZ issue with a clock reset. Why is this happening? Is it indicative of a reboot of the router? If so, isn't there a RTC the keeps track until time is checked/corrected using NTP? Note: I'm using the default NTP server of pool.ntp.org.

Edit: Looking at the current uptime reported, and the first timestamp after the last Dec 31 entry, it does appear that the Dec 31 entries occur when the router reboots. I have not rebooted (or removed power) to the router (to my knowledge - unless some changing some configuration settings force a restart?).

Each time there are groups of entries for Dec 31, the previous entries are:

Feb 15 16:34:28 WAN Connection: ISP's DHCP did not function properly.
Feb 15 16:34:28 stop_nat_rules: apply the redirect_rules!
Dec 31 16:00:07 syslogd started: BusyBox v1.17.4

However, every "ISP's DHCP did not function..." entry does not result in the Dec 31 (reboot) entry. Unfortunately, I am using a Motorola Surfboard SB6141 modem with Comcast. I've been reading that thread and don't see any generally accepted diagnosis/fix. I'm not seeing the constant DHCP errors, but have seen several in the past week since initial power-up.

So in trying to understand what's going on with this (brand new) router, I'm asking:

Does the router have a RTC? (seems not - which is surprising, but I suppose a way to cut costs)
If there is no RTC does time begin at Unix/POSIX time 0 (Jan 1 1970) after a restart?
Is the likely explanation of why timestamps "jitter" +/- 8 hours the inconsistent use of UTC offset?
If this all does mean that my router is rebooting, why would that happen? Can the modem cause this? Can Comcast send some signal to force this? Is it a malfunctioning router?
 
Last edited:
I've seen the same issues with timestamps and wondered as well. Look forward to hearing if anyone knows what's going on here.
 
If no one is able to comment on the actual hardware (is there an RTC?) perhaps a better question would be if everyone is seeing initial timestamps of Jan 1 in the system log each time their router restarts?
 
If no one is able to comment on the actual hardware (is there an RTC?) perhaps a better question would be if everyone is seeing initial timestamps of Jan 1 in the system log each time their router restarts?

There's no RTC, so yes it's normal for the clock to revert back to December 31st or January 1st after a reboot (depending on the firmware version).
 
It has no RTC. All it does is sync with an NTP server periodically to maintain the correct time, so when you select an NTP server, make sure its one that is close to you.
 
default NTP server is prone to timing out due to the load
make sure you are entering the IP of the NPT server and not the domain name
so you avoid the chicken<>egg scenario (seriously asus/toastman this should be the default) for cases where the DNS issues might be present
 
The default NTP server, pool.ntp.org, is not a specific server at all - it is a pool of over 3000 servers which changes hourly. The pool was created to ensure no single server would ever be overloaded. See www.pool.ntp.org

You should not use an IP address for a time server unless you have permission from the system owner to do so. Such permission is almost never given.

Setting pool.ntp.org as the default "server" is the most fail-safe choice Asus could have made. (Technically, Asus should apply for a vendor name through the pool. Once granted, asus.pool.ntp.org should be set as the default time server. In the off-chance anyone from Asus reads this, please see www.pool.ntp.org/vendors.html)
 
The default NTP server, pool.ntp.org, is not a specific server at all - it is a pool of over 3000 servers which changes hourly. The pool was created to ensure no single server would ever be overloaded. See www.pool.ntp.org

You should not use an IP address for a time server unless you have permission from the system owner to do so. Such permission is almost never given.

Setting pool.ntp.org as the default "server" is the most fail-safe choice Asus could have made. (Technically, Asus should apply for a vendor name through the pool. Once granted, asus.pool.ntp.org should be set as the default time server. In the off-chance anyone from Asus reads this, please see www.pool.ntp.org/vendors.html)

you are a idiot and clearly don't understand what a domain/dns is
also its been my experince that going though pool.ntp.org causes unessary latency due to the sher-load the round-robbin system gets and if you are using services such as dns-cryp or anything using ssl you need to have a vaild network time for the certs to be accepted and in the case of dns-crypt no network time = no dns = you can't resolve the dns server ;loop while case=1
 
you are a idiot and clearly don't understand what a domain/dns is
also its been my experince that going though pool.ntp.org causes unessary latency due to the sher-load the round-robbin system gets and if you are using services such as dns-cryp or anything using ssl you need to have a vaild network time for the certs to be accepted and in the case of dns-crypt no network time = no dns = you can't resolve the dns server ;loop while case=1

I don't think that rude response is called for?

I also don't see you offering anything specifically better than what was suggested by LHSS.
 
So you think name calling is okay if you call yourself stupid too?

I do not think your presence is required here if that the immature attitude you have. Especially when you can't offer anything useful instead.
 
Folks, please avoid name calling and other rude behaviours while posting on the forums.

Warnings have been issued to the appropriate users. Please keep this thread on topic, or I will be forced to put this thread under lock and key.

Thank you for your cooperation.
 

Similar threads

Latest threads

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!
Top