Ticket #2244 (new enhancement)

Opened 10 years ago

Last modified 10 years ago

otimed is poorly designed/implemented in a way that affects its operation

Reported by: BillK Owned by: openmoko-devel
Priority: normal Milestone:
Component: unknown Version: unspecified
Severity: normal Keywords:
Cc: Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible:

Description

In 2008.12 I used ntpd for accurate timekeeping - worked well, though not perfectly. SHR does not keep time well at all (jitters all over the place, and doesnt seem to compensate for clock drift), and it seems to be down to the way otimed is designed.

  1. tries to set my timezone some 3000km away from where I actually am. gsm providers in Australia seem to set the system time near where their head office is - 2hrs ahead of where I am, and ignore daylight saving which is on a different schedule in different states anyway. Its good that its controllable in frameworkd.conf. But overiding the manual timezone link automaticly is not the way to do it.
  1. otimed "grabs" the ntp port so you cant run ntpdate or ntpd to correct the time properly. Needs redesigning in such a way that a manual update can be triggered if necessary.
  1. one shot time updates have a place, but should be use with care Any one shot update runs the risk of hitting severe jitter - and its happening with the FR due to the poor choice of time server (see next) Think logs and database timestamps - the system time jumps forward a few minutes then back ... ntpd should also be able to adjust for local clock slow/fast rates - certainly did on 2008.12 - otimed doesnt seem to do so so the time drifts when not connected.
  1. The default ntp server is somewhere in europe (Germany?) - thats fine for the Europeans but what about the rest of us? - its just too far away to be useful. I also never let my FR out onto the internet alone - I always work through local networks - with their owm timeservers - otimed should also do so. Note that its considered good practise to use a local timeserver wherever possible to reduce the number of clients hitting main servers. Too much traffic to a server creates delays and affects timekeeping accuracy for all clients to that server.
  1. Hard coding an IP address - if you dont know why this is a bad idea ... The ntp people have pool.ntp.org set so you can get a reasonably local timeserver. Also check out http://en.wikipedia.org/wiki/NTP_vandalism - have you contacted the ntp server owner you have used - putting thousands of units pointing to their ntp server is similar to what d-link did - and that had consequences. NetGears? hard coded IP was seen as a DOS attack by its target ...
  1. I suggest it be looked at with the following goals:
  2. use the industry standard ntp system
  3. be fully controllable before its released (some settings system - editing a system file to change the ntp server ...)
  4. use a pool server by default and make it configurable
  5. document it properly - there is not a lot around on otimed - had on ask on IRC before I made any headway.

BillK

Change History

comment:1 Changed 10 years ago by f.hackenberger@…

Just a general question: What was the motivation to rewrite a core service like ntp in the first place? ntpd provides a lot of information about it's state using logging and monitoring (see [1]). Could someone please elaborate?

[1] http://www.eecis.udel.edu/~mills/ntp/html/decode.html

comment:2 Changed 10 years ago by mickey

Thanks for your comments!

First off, ntp has not been rewritten. Second, ntp lacks critical features that are necessary on systems such as a smartphone. E.g.

  • getting time and timezone from GSM
  • getting timezone based on the provider we are currently registered with
  • getting time from GPS

Third, we did consider to extend ntp in the first place, but did not do this yet since adding some logics in frameworkd to quickly improve the user experience was a much lower hanging fruit. There is even task for that in the FSO bugtracker http://trac.freesmartphone.org/ticket/254, albeit somehow slightly misnamed.

We will take your points into account for further work, especially 1.,3.,4.,5. seem reasonable to me. Oh by the way, you can disable otimed or even individual time provider if you don't want it -- so I consider 2. being fixed already.

If you have some time, we'd appreciate some ntp plugins that implement the missing features. Also a dbus interface would be handy.

comment:3 Changed 10 years ago by lindi

Hmm, surely ntpd can get time from GPS? See "USE WITH NTP" section of http://gpsd.berlios.de/gpsd.html

I'm also sure we can extend it to get time from GSM. I can't personally test this since my operator is not sending time via GSM (as far as I know).

comment:4 Changed 10 years ago by mmontour

The biggest issue I can see with ntpd is that it was not designed for devices that spend most of the time suspended, and which only get occasional glimpses of "real" time (a GPS fix, a wifi hotspot that allows a network poll, etc). I think there is a valid reason to do some new development in this area, including proper calibration of the RTC for tracking time while the main CPU is not running (/etc/adjtime or similar).

http://trac.freesmartphone.org/ticket/389 may be related to your issue #1. For #2, "ntpdate -u" should allow you to force an update even if something else is sitting on port 123.

Note: See TracTickets for help on using tickets.