#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
_______________________________________________
devel mailing list
devel@lists.openmoko.org
https://lists.openmoko.org/mailman/listinfo/devel
