ntp problems
in [Linux Networking]
|
Prev: ntp problems
Next: gateway setup
From: unruh on 21 Apr 2010 12:32 On 2010-04-21, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: > On comp.os.linux.networking, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: >> On comp.os.linux.networking, David Schwartz <davids(a)webmaster.com> wrote: >>> On Apr 19, 5:26=A0pm, Sidney Lambe <sidneyla...(a)nospam.invalid> wrote: >>> >>>> >> And if rdate -p 127.0.0.1 fails that there is a problem? >>> >>>> > It would be surprising if it succeeded since most Linux boxes >>>> > stopped supporting that protocol around the same time they >>>> > stopped running 'inetd' by default. >>> >>>> You are mistaken. It comes with the latest Debian, for starters: >>>> >>>> http://packages.debian.org/lenny/rdate >>>> >>>> (This will work just fine on any distro. Is a simple utility >>>> needing only the basic libs to function.) >>> >>> Even if you have 'rdate', 'rdate -p 127.0.0.1' will fail if you're not >>> running the 'rdate' server. When most distributions stopped enabling >>> 'inetd' by default, they generally also stopped providing 'rdate' >>> service by default. This applies whether or not you have a client or >>> server installed. >> >> I don't run a timeserver here. I set the gateway computer's clock >> using rdate and then use scripts calling date on the other >> boxes on the LAN to read and set their time from the gateway >> box. > > I just discovered my memory was faulty. Each box on the LAN hits > the pool once an hour at different times using rdate. Been working > just fine for years. The orignal scripts that worked as described > above are in the same file, commented out. Don't remember when > I abandoned them. > > I laughed when I read the OP saying that it was all so simple. > Right. Everything is once you know how to do it. Sure didn't > seem simple to him when he posted here after being unable to > make it work for so long. > > And ntpd sure isn't simpler than cron calling simple rdate > scripts. I've never had ANY problems and never will. And > it takes a tiny fraction of the system resources by comparison. Actually it is, and it keeps the clocks running far more accurately than your system does. That may not be important for you, so keep going with your approach. For example if the network goes down for a day, you will typically be out by many seconds by the end of the day. And ntp machine would be out by milliseconds. But if you do not care about that, fine. also, if the machine you get your time from goes down, or worse, its clock goes nuts for some reason, so will yours. ntpd has backups to detect crazy source. Again, if you do not care about this, use your technique. > > Sid > >
From: Sidney Lambe on 21 Apr 2010 13:49 On comp.os.linux.networking, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > On 2010-04-21, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: > >> On comp.os.linux.networking, Sidney Lambe >> <sidneylambe(a)nospam.invalid> wrote: >> >>> On comp.os.linux.networking, David Schwartz >>> <davids(a)webmaster.com> wrote: >>> >>>> On Apr 19, 5:26=A0pm, Sidney Lambe >>>> <sidneyla...(a)nospam.invalid> wrote: >>>> >>>>> >> And if rdate -p 127.0.0.1 fails that there is a problem? >>>> >>>>> > It would be surprising if it succeeded since most Linux >>>>> > boxes stopped supporting that protocol around the same >>>>> > time they stopped running 'inetd' by default. >>>> >>>>> You are mistaken. It comes with the latest Debian, for >>>>> starters: >>>>> >>>>> http://packages.debian.org/lenny/rdate >>>>> >>>>> (This will work just fine on any distro. Is a simple >>>>> utility needing only the basic libs to function.) >>>> >>>> Even if you have 'rdate', 'rdate -p 127.0.0.1' will fail >>>> if you're not running the 'rdate' server. When most >>>> distributions stopped enabling 'inetd' by default, they >>>> generally also stopped providing 'rdate' service by default. >>>> This applies whether or not you have a client or server >>>> installed. >>> >>> I don't run a timeserver here. I set the gateway computer's >>> clock using rdate and then use scripts calling date on the >>> other boxes on the LAN to read and set their time from the >>> gateway box. >> >> I just discovered my memory was faulty. Each box on the LAN >> hits the pool once an hour at different times using rdate. >> Been working just fine for years. The orignal scripts that >> worked as described above are in the same file, commented out. >> Don't remember when I abandoned them. >> >> I laughed when I read the OP saying that it was all so simple. >> Right. Everything is once you know how to do it. Sure didn't >> seem simple to him when he posted here after being unable to >> make it work for so long. >> >> And ntpd sure isn't simpler than cron calling simple rdate >> scripts. I've never had ANY problems and never will. And it >> takes a tiny fraction of the system resources by comparison. > > Actually it is, Are you serious? > and it keeps the clocks running far more > accurately than your system does. That may not be important > for you, so keep going with your approach. Like I need your permission. "My system" (which you obviously don't understand) has been working fine for years. Never had a problem with anything. > For example if the network goes down for a day, you will > typically be out by many seconds by the end of the day. It went down for 5 days once and was only off by an average of 7 seconds. > And ntp machine would be out by milliseconds. And this accomplishes what when the network is down anyway? > But if you do not > care about that, fine. also, if the machine you get your time > from goes down, or worse, its clock goes nuts for some reason, > so will yours. That explains why your article here makes no sense. Try actually reading the post your are replying to. Each machine here contacts the ntp pool independently. > ntpd has backups to detect crazy source. Again, if you do not > care about this, use your technique. How good of you to give me permission to do what I do. I am so greteful. And all this from the guy who told everyone that rdate doesn't do SNTP. I go with what works best. And ignore the advice of fatheaded geeks like you. _That's_ my system. It works very well indeed. If I listened to people like you I'd be bogged down with so much unnecessary software that my network would require constant attention. As it is now, it is, literally, maintenance free. Sid
From: unruh on 21 Apr 2010 14:11 On 2010-04-21, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: > On comp.os.linux.networking, unruh ><unruh(a)wormhole.physics.ubc.ca> wrote: > >> On 2010-04-21, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: >> >>> On comp.os.linux.networking, Sidney Lambe >>> <sidneylambe(a)nospam.invalid> wrote: >>> >>>> On comp.os.linux.networking, David Schwartz >>>> <davids(a)webmaster.com> wrote: >>>> >>>>> On Apr 19, 5:26=A0pm, Sidney Lambe >>>>> <sidneyla...(a)nospam.invalid> wrote: >>>>> >>>>>> >> And if rdate -p 127.0.0.1 fails that there is a problem? >>>>> >>>>>> > It would be surprising if it succeeded since most Linux >>>>>> > boxes stopped supporting that protocol around the same >>>>>> > time they stopped running 'inetd' by default. >>>>> >>>>>> You are mistaken. It comes with the latest Debian, for >>>>>> starters: >>>>>> >>>>>> http://packages.debian.org/lenny/rdate >>>>>> >>>>>> (This will work just fine on any distro. Is a simple >>>>>> utility needing only the basic libs to function.) >>>>> >>>>> Even if you have 'rdate', 'rdate -p 127.0.0.1' will fail >>>>> if you're not running the 'rdate' server. When most >>>>> distributions stopped enabling 'inetd' by default, they >>>>> generally also stopped providing 'rdate' service by default. >>>>> This applies whether or not you have a client or server >>>>> installed. >>>> >>>> I don't run a timeserver here. I set the gateway computer's >>>> clock using rdate and then use scripts calling date on the >>>> other boxes on the LAN to read and set their time from the >>>> gateway box. >>> >>> I just discovered my memory was faulty. Each box on the LAN >>> hits the pool once an hour at different times using rdate. >>> Been working just fine for years. The orignal scripts that >>> worked as described above are in the same file, commented out. >>> Don't remember when I abandoned them. >>> >>> I laughed when I read the OP saying that it was all so simple. >>> Right. Everything is once you know how to do it. Sure didn't >>> seem simple to him when he posted here after being unable to >>> make it work for so long. >>> >>> And ntpd sure isn't simpler than cron calling simple rdate >>> scripts. I've never had ANY problems and never will. And it >>> takes a tiny fraction of the system resources by comparison. >> >> Actually it is, > > Are you serious? > >> and it keeps the clocks running far more >> accurately than your system does. That may not be important >> for you, so keep going with your approach. > > Like I need your permission. > > "My system" (which you obviously don't understand) has been > working fine for years. Never had a problem with anything. > >> For example if the network goes down for a day, you will >> typically be out by many seconds by the end of the day. > > It went down for 5 days once and was only off by an average > of 7 seconds. > > >> And ntp machine would be out by milliseconds. > > And this accomplishes what when the network is down anyway? > It accomplishes your machine only being off by milliseconds after 5 days even though the network is down. It also accomplishes making sure that the clock does not step backwards and have later files timestamped with earlier times. >> But if you do not >> care about that, fine. also, if the machine you get your time >> from goes down, or worse, its clock goes nuts for some reason, >> so will yours. > > That explains why your article here makes no sense. Try actually > reading the post your are replying to. Each machine here contacts > the ntp pool independently. > >> ntpd has backups to detect crazy source. Again, if you do not >> care about this, use your technique. > > How good of you to give me permission to do what I do. I am so > greteful. > > And all this from the guy who told everyone that rdate doesn't > do SNTP. > > I go with what works best. And ignore the advice of fatheaded geeks like > you. _That's_ my system. It works very well indeed. > > If I listened to people like you I'd be bogged down with so much > unnecessary software that my network would require constant > attention. As it is now, it is, literally, maintenance free. > > Sid > >
From: unruh on 21 Apr 2010 14:25 On 2010-04-21, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: > On 2010-04-21, Sidney Lambe <sidneylambe(a)nospam.invalid> wrote: >> >> And all this from the guy who told everyone that rdate doesn't >> do SNTP. Actually it does not on Linux (at least the distros I have seen). On openbsd apparently it has been rewitten so it does. >> >> I go with what works best. And ignore the advice of fatheaded geeks like >> you. _That's_ my system. It works very well indeed. Fine, as I pointed out, you have my permission to do whatever you want on your system. When you advise other people, as you have done here, I will continue to point out the problems with your solution.
From: Sidney Lambe on 21 Apr 2010 14:27
On comp.os.linux.networking, unruh <unruh(a)wormhole.physics.ubc.ca> wrote: I know your type. You couldn't admit you were wrong about something if your life dependended in it. [delete] Sid |