Networking → Router's clock can't maintain accurate time, why?

I ran into an unusual problem and wondering if anyone else has seen this before, and has any suggestions.

I bought a pair of ASUS WL-500gP V2 wireless routers about three years ago. Each is used in a different home as the primary router. Both are running TomatoUSB (the last, original version 1.28 from TeddyBear, dated Nov 30, 2010), and so absolutely identical, and have worked perfectly, until recently.

About two months ago, I started to periodically lose the internet connection between the router and cable modem. After changing the ethernet cable and modem didn’t help, I noticed this only happens as the DHCP lease is nearing expiration, and that a simple DHCP renewal fixed it. That got me to thinking it’s a timing issue. And when I checked the router’s clock, I finally realized it’s WAAAY off (approx. 12 secs/min), despite being updated every four hours. So now I see the problem; it’s so far behind the correct time (over a 4 hr window, ~48 mins!), it doesn’t renew the DHCP lease in time, and so connectivity is lost until it catches up.

According to a router dump, it’s using MIPS as its clocksource. So that got me to thinking it might be due to something I installed as optware, or router overloading. So I reinstalled the firmware, cleared NVRAM, and started over. Same problem. Tried switching AC outlets (it’s normally on a surge protector w/ other devices), and changing the AC adapter, same problem. Nothing I’ve done so far changes the fact this router’s clock is ALWAYS off by ~12 secs/min.

Meanwhile, the other WL-500gP V2 router is working just fine. It keeps perfect time.

After searching Google, I can’t find anyone who’s experienced a similar problem, specifically w/ a router (I realize devices based on a CMOS battery would explain some of this). But for a router?, nothing. I find it hard to believe I’m the first and only one.

Anyone else seen this before? What could cause the router’s clock to suddenly run so much slower? And it seems relatively predictable (it’s not wavering all over the place, it’s pretty much 12 secs/min). Perhaps some electronic damage due to a surge (although, as I said, it’s normally protected)? Is this router simply at the end of its life? Anyone have any other ideas, suggestions?

For the time being, I’m resyncing the clock every 5 mins off a local NTP server. But I’d like to fix it if possible rather than use this hack.

This is the only thing that I could find. Hope that this helps.
»www.dd-wrt.com/phpBB2/vi ··· 9#231599

Thanks for the reply. That definitely looks like the problem. As described in the dd-wrt bug report, it’s off ~12 secs/min. However, I’m baffled why one of my WL-500gP v2 routers keeps perfect time, while the other has this problem. By every spec/measurement I can dig out, they appear to be identical. Same make, model, firmware, chipsets (right down to the rev and pkg), same MIPS, etc. Yet I get different results. Even reset the troublesome router and reinstalled the firmware (Tomato v1.28.9054 MIPSR1-beta K26 USB vpn3.6), so just a raw, plain vanilla setup. Something’s obviously different, but I’m stumped about what it is.

WL-500gp v2 (#1) keeps perfect time:
system type : Broadcom BCM5354 chip rev 3 pkg 0
processor : 0
cpu model : Broadcom BCM3302 V2.9
BogoMIPS : 239.20
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented : mips16
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available

unaligned_instructions : 9
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0

This WL-500gP v2 (#2) is always off by 12 secs/min:
system type : Broadcom BCM5354 chip rev 3 pkg 0
processor : 0
cpu model : Broadcom BCM3302 V2.9
BogoMIPS : 239.20
wait instruction : no
microsecond timers : yes
tlb_entries : 32
extra interrupt vector : no
hardware watchpoint : no
ASEs implemented : mips16
shadow register sets : 1
VCED exceptions : not available
VCEI exceptions : not available

unaligned_instructions : 0 Different, does it matter?
dcache hits : 0
dcache misses : 0
icache hits : 0
icache misses : 0
instructions : 0

Only difference I see is unaligned instructions (I have no idea if this is significant).

Best I can tell from the bug reports, the problem occurs because the source code incorrect identified the processor speed and essentially underclocked it. But as you can see, both routers are reporting the same (and accurate) cpuinfo.

Also tried installing latest Shibby (109), same problem.

Just plain weird.

UPDATE:

Tried installing dd-wrt (build 14896, recommended in the DB), same problem.

Tried the latest firmware from ASUS (3.0.4.4), same problem!

So even the ASUS stock firmware has this problem (something I never noticed until now). I bet something about the hardware is different, despite whatever the firmware is reporting. And I don't see any hardware version markings on the device itself either. There's just nothing I can find that actually says the hardware is different. Yet all the behavior suggest there is.

You've probably done this but I'm gonna ask anyways. Have you been performing 30-30-30 hard reset every single time? It's a shot in the dark. I know that you've tried everything but I keep coming back to some kinda hardware issue.

Using the various sourced firmwares to test the unit leads me to believe that it is a hardware issue. Most likely, the chip that contains the Real Time Clock is failing. Since it is beyond the return period, either scrap it, set the clock update to every 60 seconds, or configure it for use as an Access Point (where correct time does not matter).

You can't do a true 30-30-30 reset on most ASUS routers. There's no reset button. Only restore and WPS buttons. The only way to clear nvram is w/ the GUI-based firmware update. So that’s what I did. Then used tftp to install the next firmware. I don’t think nvram has anything to do w/ the problem. I’ve been doing firmware updates like this for years, never had this problem before.

I also think it’s a hardware problem, but I don’t think it’s due to failing hardware. What are the odds that failing hardware would just happen to match the same exact problem identified in prior versions of dd-wrt (12 secs/min)? If this was failing hardware, I’d expect the time loss to be different, and vary.

I suspect the problem has always been there, but I just never noticed it before. The router is used in our second home, which we only visit occasionally. It’s only recently that I’ve been using this router on a day to day basis. It was probably dropping connections all the time.

I currently have a problem report filed w/ ASUS. I don’t really expect any action on it (the router was purchases 2 ½ years ago), but I just want to see if they at least acknowledge it’s a known problem.

Interesting. I got a late reply today from ASUS (wasn't expecting anything until at least Monday). Here's what it says:

We regret that your issue can only be resolved by our repair centre, please complete the online RMA form to book for a collection/repair on the following link:

»vip.asus.com/eservice/us ··· erv.aspx

That strongly suggest to me it's a known problem. Perhaps a bad batch of routers (I bet it's some error in the chipset microcode). At least they seem to be accepting an RMA (I mentioned it's 2 1/2 years old in my problem report). Would be great is they just replaced it. Keeping my fingers crossed.