On 2015-02-15, David Lord <sn...@lordynet.org> wrote: > William Unruh wrote: >> On 2015-02-14, Paul <tik-...@bodosom.net> wrote: >>> On Sat, Feb 14, 2015 at 2:09 PM, William Unruh <un...@invalid.ca> wrote: >>> >>> >>> Yes but you said >>> "This means that if you are using say a PPS source, which gives >>> microsecond long term offset, it can take many hours to get there" >>> and I was responding to that. If you refuse to accept that your previous >>> statements set the context for a discussion then you're just an ANON troll. >> >> Hardly anon. But if the context was PPS, then I agree that I was >> probably wrong (not being able to remember what my test system was >> doing.) >> >>> >>>> To get the discussion started, lets compare some of the differences >>>> between chrony and ntpd. >>>> >>> BZZZZZT. NTPd is yesterday's news. It's core is unlikely to change absent >>> a security flaw. Design "discussions" about it are useless and unhelpful >>> (but they should still be on more relevant list). Come back when you're >>> ready to write about the differences between Chrony and Ntimed with reasons >>> to select one or the other. In the meantime be a better advocate of >>> alternatives to NTPd i.e. get unstuck from the past and port Chrony to >>> Windows. >> >> When timed is actually out I may be interested in testing it again. >> However, you discussion indicates to me that there the design of timed >> had not advanced from that of ntpd. Whether it is yesterday's news or >> not, it seems to be determining tomorrow nontheless. >> You have not given any indication that the design discussion has moved >> on from ntpd. >>> Research is needed, and such research should be part >>>> of any new system. Is it there? >>>> >>> Ntimed has a few constraints -- no research needed: >>> 1) Be safer (simpler) than ntpd. >>> 2) Be smaller than ntpd. >>> 3) Be as good or better than ntpd where better is probably slippery. >> >> None of those indicate that anything about the design has changed. You >> know much better than I do I would assume. >> No idea what is unsafe about ntpd. Smaller may be possible, mainly be >> cleaning up the accretion of code. And I would like to hear about what >> "better" means. I have mentioned why I believe chrony is better. What do >> you mean by better? >> >> >>> It's not clear to me if worrying about dial-up costs is an Ntimed concern >>> (I doubt it) but if it is for you then use Chrony. >> >> Dialup costs? Where did I ever mention dialup costs? And chrony's >> ability to handle dialup is simply an indication of its greater >> flexibility. Dialup costs never played a role in the design of chrony, >> except in making it flexible enough to handle the situation of >> intermittent connectivity to a time source. >> >> I am beginning to wonder who the troll is here. I have given you >> detailed answers to your question, you come back with irrelevancies and >> snarky comments. >> > > Hi > > I must be a troll since I disagree with you. I used chrony during
You can disagree with me and not be a troll. If you demand that I give detailed explanation, tell me that timed is different from ntpd, but give me no explanation as to how, or how timed differs from ntpd, then I would start to think you are a troll (You are not, you give reasons). > the 90's, probably because my isp was demon. I also tried ntpd but > with my pcs not being online 24/7 and using dialup for internet > connection ntpd wasn't really usable. Late 90's to 2005 I > eventually had several pcs online 24/7 and found that ntpd gave > lower and more stable offsets than chrony but I still needed to > use chrony on the dialup pc. The one big flaw with ntpd is that > when motherboard temperature changes too quickly the ntpd control > loop is broken and ntp offset can rise from < 300u to > 10ms. That is of course a disaster. Note that chrony has changed substantially since the 90s. Lichvar has done a lot of updating of chrony, adding refclock support, improving rtc support, etc. Both he and I have done testing of chrony vs ntpd, and both found that chrony disciplined the clock better (I think because of its faster response to temperature changes). > > I've downloaded ntimed which compiled ok so will give it a try in > a few days. Be interesting to see how and what it does. > > > David > > > > _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
