Openmoko Bug #2244: otimed is poorly designed/implemented in a way that affects its operation

[Openmoko Public Trac]

#2244: otimed is poorly designed/implemented in a way that affects its operation
-------------------------+--------------------------------------------------
 Reporter:  BillK        |          Owner:  openmoko-devel
     Type:  enhancement  |         Status:  new           
 Priority:  normal       |      Milestone:                
Component:  unknown      |        Version:  unspecified   
 Severity:  normal       |       Keywords:                
 Haspatch:  0            |      Blockedby:                
Estimated:               |    Patchreview:                
 Blocking:               |   Reproducible:                
-------------------------+--------------------------------------------------
 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.

 2. 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.

 3. 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.

 4. 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.

 5. 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 ...

 6. I suggest it be looked at with the following goals:
 a. use the industry standard ntp system
 b. be fully controllable before its released (some settings system -
 editing a system file to change the ntp server ...)
 c. use a pool server by default and make it configurable
 d. document it properly - there is not a lot around on otimed - had on ask
 on IRC before I made any headway.

 BillK

-- 
Ticket URL: <https://docs.openmoko.org/trac/ticket/2244>
docs.openmoko.org <http://docs.openmoko.org/trac/>
openmoko trac