Time Sync Ntp And Rc12

[guima]

Hi,

The zaurus time gets late when it goes to sleep. I believe this is a known problem, although I thought I had seen some posts saying that it was (or it would be) fixed.

One way of keeping the time in sync  is to use ntp. This is not a perfect solution because I am not always connected to the internet, however it is better than nothing.

Out of the box, rc12 comes with a time setting tool, which allows to define ntp servers, however there is no ntp daemon running by default.
I have installed ntpd and ntpdate from the feed .
After a reboot, I still didn't get ntpd running.
When using ntpdate with one of the default servers:
ntpdate 0.pool.ntp.org
the time gets changed to 18:00, it is now 12:00. So, I guess it is using UTC.

Can someone help me with this?
1) Is there any known fix to get correct time without ntp?
2) How to setup ntp to work properly? BTW, the "time and date setting" tool does not have any facility to define if we use UTC time or not, or to turn ON/OFF ntp. That would be nice.

Thanks,
Joao

[albertr]

What Zaurus model do you have? On my C1K clock is accurate - the time doesn't get off more than a couple of seconds a week. I don't run ntpd, but use ntpdate sometimes. You local time zone doesn't seem to be set correctly. Keep your hardware clock in UTC, but symlink /etc/localtime to the appropriate timezone.
-albertr

[guima]

What Zaurus model do you have? On my C1K clock is accurate - the time doesn't get off more than a couple of seconds a week. I don't run ntpd, but use ntpdate sometimes.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=102582\"][{POST_SNAPBACK}][/a][/div]

I forgot to say that my Zaurus is the C860.
I have never been able to keep the time accurate with the pdaxrom (since rc 10).
It is really annoying with PIM applications.

I am not sure about the second part of your email. I do not have /etc/localtime and I don't know where to link it to!

-Joao

[guima]

I fixed the timezone with (found in another thread)
ln -s /usr/share/zoneinfo/America/Chicago /etc/localtime

After that, when I tried to use ntpdate 0.pool.ntp.org, the screen went black (I believe it went into suspend) and the the zaurus end up freezing.
That's the second time in 5 minutes!

[guima]

Some more progress, after my last freeze and hard reboot, ntpd is now running.
I rebooted with the network card plugged in. Does ntpd need network to be started?

The clock is now running with Chicago time. Will see how accurate it will be later.

Another question:
I do not have the hwclock command! Which package has that?

BTW,
There is some information about this in:
https://www.oesf.org/forums/index.php?showt...228&#entry35228

However, Laze says this problems will be fixed in the next release. That is why I was wondering if there is any fix in place besides ntp.

Thanks,
Joao

[guima]

OK, so I am still having trouble.
I tried the tricks on this forum with sethwclock and sltime but it is not working.
I think the problem is that my hardware clock is not in UTC.
However, I don't see how I can change it since hwclock is not available anymore.

Is there a way of setting the hardware clock to UTC with sethwclock? I can't find any documentation on this binary.
Also, what does "sltime" do?

Thanks.
Joao

[huu]

I've been having similar problems with my newly-bought C750. Every once in a while, about once a day, it won't wake up: it has suspended apparently normally, but when I try to turn it on the screen stays black. Once I remove and reinsert the battery it reboots, but the time is reset to about the time when it was suspended.

Yesterday I grabbed hwclock from my old SL-5500 and changed the hardware clock to UTC. This seems to have fixed it to the extent that this particular problem hasn't appeared yet. On the other hand, when I changed sethwclock / sltime -set in the suspend scripts to hwclock --systohc the zaurus stopped suspending properly. A quick session with hwclock --debug showed that there seems to be some sort of problem with /dev/rtc.

More often than not, hwclock --debug says that it is "Waiting for clock tick..."; hwclock with other options just hangs. On the other hand, sethwclock and sltime appear to work, but sltime seems to set the clock back to the time of the last sltime -set. In other words, the clock behind /dev/rtc is not running, just like hwclock says.

Now the interesting question is whether this is a feature of this particular c750, all cXX0's, or pdaXrom on a cXX0.

[albertr]

I'm not sure about CXXX, first I don't have one and sharp's 2.4.18 kernel is different from sharp's 2.4.20 kernel. But on my C1K hwclock runs fine, time is accurate and I don't have any problem with suspending/resuming in pdaXrom or Qtopia. Sorry, not that it probably helps you... AFAIK, both CXXX and CYYYY Zauries don't have a real hardware clock, it;s all emulated.
-albertr

[clofland]

I'll throw in my 2 cents.

My clock on my c760 was very accurate for weeks on end under CackoROM. It gets off by about 5 minutes a day or more on pdaXrom until it is about 15 minutes behind, and then seems to be happy there for a while.

If I use ntpdate to set the time while X is up, the machine goes to sleep immediately, and will not let me wake it up without going RIGHT back to sleep until the time interval that it was changed has passed.

If I install the ntp service, then it does this to me on EVERY suspend.

I have put this into a bug report on the pdaXrom site last month.

It should be noted that CakcoROM is set to sync its time using ntpdate on EVERY network connection, so that may be why it was more accurate in the long run. As I've noted, syncing the time under pdaXrom basically crashes the machine if X is running, so this isn't an option with pdaXrom yet, but when it is, that may be the solution.

[gab74]

i try on my C3100 for setting the right time the solution above....

Code: [Select]

remove /etc/localtime if it exists (so that you are working in UTC)
use ntpdate to set the system clock to the correct time in UTC (or date --set)
use hwclock to set the hardware clock from the system clock(ie: hwclock --systohc)
tell hwclock to work in UTC (ie: hwclock --utc)
copy /usr/share/zoneinfo/whatever/whatever from a *nix box to /etc/localtime
if i suspend and resume in a little time all works well but if i suspend and resume after 15 minutes matchbox freeze !!!! and i've to reboot my Z C3100 by keep up and keep in the battery......is there a solution

[clofland]

I little update here.

I finally got my 760 to stop loosing time on every suspend.

The solution was to run "sethwclock" after I set the time. I also put this command into the suspend/resume scripts.

I know that the "sltime -set" is already run, but it seems that "sethwclock" must also be run, otherwise my Z would loose time after every suspend.

ADDITION:

Also, I THINK I fixed the part where my Z would go straight to suspend after I changed the time by running "xset -dpms" before updating the time and then "xset +dpms" afterwards. Again, I think this fixed it, but I'm not 100% sure yet.

ADDITION2:

WOW, overnight and the Z is still TO THE MINUTE accurate with time! I haven't seen that since I used CackoROM. I don't know what "sethwclock" does, but it seemed to fix my problem. (The 7x0 pdaXrom's don't have hwclock in the ROM, so I didn't try any of the optins suggested with that program.)

Ah, and here is a reference to this exact fix, almost a year ago:
https://www.oesf.org/forums/index.php?showt...indpost&p=59793

It appears that the sltime -set was added to the apm scripts, but not the 'sethwclock' I wonder why not?

[huu]

I can confirm this. For the past couple of weeks I'd been wondering why my 750 kept its time less and less accurately. This weekend it dawned on me that there was a clear pattern: after each suspend it was 89--90 seconds late, regardless of how many suspends or how much time had passed since the last ntpd -q.

It turns out that the sethwclock / sltime -set in the suspend scripts wasn't enough; however, a sethwclock right after the ntpd -q did the trick.

[lindenle]

I can confirm this. For the past couple of weeks I'd been wondering why my 750 kept its time less and less accurately. This weekend it dawned on me that there was a clear pattern: after each suspend it was 89--90 seconds late, regardless of how many suspends or how much time had passed since the last ntpd -q.

It turns out that the sethwclock / sltime -set in the suspend scripts wasn't enough; however, a sethwclock right after the ntpd -q did the trick.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=110052\"][{POST_SNAPBACK}][/a][/div]

Ok so can someone summarize what I need to change in 1.0.1beta1 to make my time work correctly after a suspend with a c860. I am having a hard time distilling all this info. Thanks.