SuSE 12.2 NTP Server

English Network/Internet
#1

Greetings everyone,

I’m not a professional when it comes to computers. I consider myself a hobbyist; and very much a sincere Linux enthusiast. I have a fairly extensive network for my home and home office, and recently I have began to coordinate my network to a single NTP server on my network. My box is SuSE 12.2; I’m able to use it just fine as a stratum 2 NTP server - I’m using a USNO peer. However, I’m becoming greedy with my seeking of furthering my understanding of NTP and I have been wanting to use a small GPS device ( DeLorme Earthmate BT-20) to turn my server to stratum 1.

I’ve used open streets with my GPS and it seems to work fine. However, I can’t seem to get the YaST NTP Configuration to recognize that I have an attached NMEA compliant device. I have set the drivers to “generic NMEA GPS Receiver”; I create a symlink - “/dev/serial/by-id/usb-DeLorme_Publishing_DeLorme_USB_Earthmate-if00-port0”. BUT… when I display the log, I get:
ntpd[3453]: ntpd exiting on signal 15

ntpd[4407]: refclock_open /dev/gps0: No such file or directory

ntpd[4407]: 127.127.20.0 interface 127.0.0.1 -> (none)

I Thank You, if anyone out there in SuSE land can help me with this. Please try to keep it simple for me, as I’m not a computer professional.

Respectfully

Justin

PS - I’m posting in the Network/Internet forum because the word “network” makes up the title “network time protocol.”

#2

Welcome here.

A few remarks (sorry no direct solution to your problem).

  1. There is not such a thing as SuSE for a long time. These forums are, as is explicitly stated on the main page at least, about openSUSE. And because you say the version you have is 12.2 I assume you also have openSUSE. (I say this because other version numbers could point to SUSE Linux, which is something different).

  2. You show some computer text in your post, which is OK and very much readable in this case. But in most cases computer output will be distorted to much when you post it as normal text. Thus please copy/paste computer text between CODE tags in a post. You get CODE tags ny using the # button in the toolbar of the post editor. And plaese when you want to show a command and it’s output do so by copy/paste of the prompt, the command, the output and the next prompt between the CODE tags. This will show more then story telling about what you did.

  3. I never tried what you do here, but it is not clear what symlink you created to what. Again, like in 2), better do post the ln command, thus there can be no confusion of what is linked to what. Also, changing things within /dev (like making this link) is vulnarable in such a way that it is deleted at shutdown and not recreated after a boot. /dev is a temporary file system in RAM.

  4. What I read from the messages you got is that ntpd is missing /dev/gps0. You never mention that you created that one. Am I missing something?

Hope this helps in getting the bug finding process on the way :wink:

#3

Mr. Velden,

Sorry about my egregious spelling error with openSUSE. Your assumption is correct I am using openSUSE 12.2.

I’m not an advanced user, so I try to avoid the command line interface if I can. Everything that I described in my first post can all be achieved thru the YaST GUI by selecting NTP Configuration. Everything I’ve done: creating the GPS profile, selecting the driver, creating the symlink, even displaying the log I’ve done it all through the GUI. That might play into why all the things I’ve shown in my posting aren’t “distorted.”

As for your statement/question - “4) What I read from the messages you got is that ntpd is missing /dev/gps0. You never mention that you created that one. Am I missing something?” - I would have to say that I believe I have created it through the GUI process. If you think you have a better way that will recognize the GPS’ NMEA ouptut by the NTPd; then please please please! instruct me.

#4

Hm, as I said, I never tried to do what you did. It indeed did not come to my mind that you did this using YaST alone. And when somebody here says that he made a symbolic link, then he mostly means just that: typing

ln -s <some-existing-file> <some-link-to-it>

A big misunderstanding. But it is, at least partly, created by the fact that you did not descibe exactly what you did. You apparently presuming that all other people immideatly would guess that correctly. This is most often not the case.

Now describing exactty what one does and posting it is definitely more difficult for something done in a GUI (often requiring screen prints posted in a a paste=bin) then in the CLI. One of the reasons why we prefer the CLI in such cases.

I tried to find out a bit about what your action could have been in start YaST > Network Services > NTP configuration. I guess you clicked then the Add button and choose something like Raioclock or so. Please explain what you did exactly there. And keep in mind that maybe none of the people here has ever done this (in the mean time hoping that someone tunes in here who has experience). Most are satisfied with seting up a connection to a server on their Lan or the Internet. Only a few will use their openSUSE as NTP server for their LAN. And that is about what is normal here.

#5

Mr. Velden,

I believe what I will do is attempt to restate the process I have completed thus far with my - AMATEUR - attempt at making a home NTP server. I have no formal training with computers, operating system, etc.; so I am very much an amateur. I try to avoid the CLI when possible, unless I have step-by-step instructions of what to do; because I do know that you can really FUBAR your computer if you don’t know what your doing. So everything that I will attempt to explain has only happened in the GUI.

In my efforts to setup a personal NTP server (to coordinate my computers, cameras, clocks, etc., and -as a joke - in preparation for the zombie apocalypse) I begin by starting YaST > Network Services > NTP configuration. Initially, once established in the “Advanced NTP Configuration”, in my process of creating my server - In the “Start NTP Daemon” article I have selected “now and on boot”. In the synchronization list I established an address to the USNO - which from what I’ve read essentially makes my server setup stratum 2 (moot point).

Today I am attempting to create a new synchronization type by selecting Add > Radio Clock. My radio clock is a DeLorme Earthmate BT-20 (NMEA 2.0) GPS receiver. In the Local Reference Clock menu - under clock type - I select “Generic NMEA GPS Receiver.” Then I go to OK, which takes me back to the main “Advanced NTP Configuration”. Again I click OK so that the NTP settings take effect and re-start the ntpd daemon.

I then will go back into the “Advanced NTP Configuration” and the I will select “Display Log”.
The log output is:
“24 Jan 23:15:47 ntpd[16559]: ntpd exiting on signal 15” - note1 = This I assume is good and is based on my Server Synch to the USNO
“24 Jan 23:15:55 ntpd[16660]: refclock_open /dev/gps0: No such file or directory” - note2 = This is obviously the GPS, but the ntpd isn’t finding the GPS
“24 Jan 23:15:55 ntpd[16660]: 127.127.20.0 interface 127.0.0.1 -> (none)” - note3 = This I believe is in reference to the generic NMEA driver

 In reference to note2; I have used the udev-browse command to verify that my system is recognizing that my GPS is plugged in to my computer.  It says that the GPS *DEVPATH /devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2:1.0/ttyUSB0/tty/ttyUSB0*.  In the Local Reference Clock menu where it allows you to create a symlink; I have entered this information and it still results in the same log output.

I hope that this has cleared up what I have been able to do so far. Now the question is: How do I trouble shoot and fix this issue so that ntpd will use my GPS as a clock reference?

Thanks

-Justin

#6

On 1/25/2013 1:46 AM, USMCleather wrote:
>
> Mr. Velden,
>
> I believe what I will do is attempt to restate the process I have
> completed thus far with my - AMATEUR - attempt at making a home NTP
> server. I have no formal training with computers, operating system,
> etc.; so I am very much an amateur. I try to avoid the CLI when
> possible, unless I have step-by-step instructions of what to do; because
> I do know that you can really FUBAR your computer if you don’t know what
> your doing. So everything that I will attempt to explain has only
> happened in the GUI.
>
> In my efforts to setup a personal NTP server (to coordinate my
> computers, cameras, clocks, etc., and -as a joke - in preparation for
> the zombie apocalypse) I begin by starting YaST > Network Services > NTP
> configuration. Initially, once established in the “Advanced NTP
> Configuration”, in my process of creating my server - In the “Start NTP
> Daemon” article I have selected “now and on boot”. In the
> synchronization list I established an address to the USNO - which from
> what I’ve read essentially makes my server setup stratum 2 (moot point).
>
> Today I am attempting to create a new synchronization type by selecting
> Add > Radio Clock. My radio clock is a DeLorme Earthmate BT-20 (NMEA
> 2.0) GPS receiver. In the Local Reference Clock menu - under clock type
> - I select “Generic NMEA GPS Receiver.” Then I go to OK, which takes me
> back to the main “Advanced NTP Configuration”. Again I click OK so that
> the NTP settings take effect and re-start the ntpd daemon.
>
> I then will go back into the “Advanced NTP Configuration” and the I
> will select “Display Log”.
> The log output is: “24 Jan 23:15:47 ntpd[16559]: ntpd exiting on
> signal 15” - note1 = This I assume is good and is based on my Server
> Synch to the USNO
> “24 Jan 23:15:55 ntpd[16660]: refclock_open
> /dev/gps0: No such file or directory” - note2 = This is obviously the
> GPS, but the ntpd isn’t finding the GPS
>
> “24 Jan 23:15:55 ntpd[16660]: 127.127.20.0
> interface 127.0.0.1 -> (none)” - note3 = This I believe is in reference
> to the generic NMEA driver
> In reference to note2; I have used the udev-browse command to
> verify that my system is recognizing that my GPS is plugged in to my
> computer. It says that the GPS
> -DEVPATH/devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2:1.0/ttyUSB0/tty/ttyUSB0-_.
> In the Local Reference Clock menu where it allows you to create a
> symlink; I have entered this information and it still results in the
> same log output.
>
> I hope that this has cleared up what I have been able to do so far.
> Now the question is: How do I trouble shoot and fix this issue so that
> ntpd will use my GPS as a clock reference?
>
> Thanks
>
> -Justin
>
>
Justin;

I’m not sure this will help but try testing with AppArmor disabled. You may
just need to edit the ntpd profile. Just an idea.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

#7

Thanks for the explanation about what you did. Makes it a lot clearer for everybody I assume.
I will think this over if I can advice something . The problem beingthat I can not experiment here, not having such a device. And that is true for most of us I am afraid.

BTW, does the post of Justin ring a bell? I am not sure how he comes to the conclusion that you run AppArmor (I don’t and if I am correct it is not installed or started by default).

BTW, your fear of using the CLI is realy something you should get rid off. You manage Linux systems and while there are tools like YaST to help you in system management and that do have a GUI interface (YaST also has other interfaces), they mostly at the maximum cover the 80% of tasks mostly done. As soon as you venture into more exotic aereas you have to revert to the CLI. Also the CLI gives you a much better direct access to configuration file and the like because it leaves out the extra layer of interpretation of tools (GUI or not). Also advising on problems via the forums here is much, much easier by showiing CLI statements then makeing stories like: “and then there is button with a laughing face in the lower right corner of the left half of the window and …”. Same for reporting back here.

#8

Just as some talk about the background.

I think it is not a bad idea to have one central NTP server in your LAN where all other system synchronise to. Advantages IMHO:
. Less trafic out to the Internet (only one system synchronises with an NTP server on the Internet);
. Even when the NTP server on the internet, or the whole internet connection, fails, internal synchronisation in the LAN is still available. This internal synchronisation can be important when e.g. system use each other’s resources (NFS mount).

I have done this several times in customer’s networks (in the times that I was professional as a system manager).

I, however never saw a direct timer resource (apart from the system clock) used in these cases. Nor the need for it. But I admit it is a nice excersise to see if one can get this working.

#9

And technical. Can you please post the output of the following two statments:

ls -l /dev/serial/*
ls -l /dev/gps*
#10

On 1/25/2013 4:06 AM, hcvv wrote:
>
<snip>
> BTW, does the post of Justin ring a bell? I am not sure how he comes to
> the conclusion that you run AppArmor (I don’t and if I am correct it is
> not installed or started by default).
>
<snip>
>
>
Henk;

I think you are refering to my earlier post. I currently run 11.4:Evergreen.
For many years(releases) prior to 12.x, AppArmor was turned on by default.
Perhaps there was a policy change at Opensuse. But I think it is still worth a
look.

–
P.V.
“We’re all in this together, I’m pulling for you” Red Green

#11

On 2013-01-25 08:46, USMCleather wrote:
>
> Mr. Velden,
>
> I believe what I will do is attempt to restate the process I have
> completed thus far with my - AMATEUR - attempt at making a home NTP
> server. I have no formal training with computers, operating system,
> etc.; so I am very much an amateur. I try to avoid the CLI when
> possible, unless I have step-by-step instructions of what to do; because
> I do know that you can really FUBAR your computer if you don’t know what
> your doing. So everything that I will attempt to explain has only
> happened in the GUI.

You can ruin a system also using the GUI :-p

Really, the CLI is the strongest point in favour of Linux. It is so much
easier to follow steps and keep track of them.

> Today I am attempting to create a new synchronization type by selecting
> Add > Radio Clock. My radio clock is a DeLorme Earthmate BT-20 (NMEA
> 2.0) GPS receiver. In the Local Reference Clock menu - under clock type
> - I select “Generic NMEA GPS Receiver.” Then I go to OK, which takes me
> back to the main “Advanced NTP Configuration”. Again I click OK so that
> the NTP settings take effect and re-start the ntpd daemon.
>
> I then will go back into the “Advanced NTP Configuration” and the I
> will select “Display Log”.

> The log output is: “24 Jan 23:15:47 ntpd[16559]: ntpd exiting on
> signal 15” - note1 = This I assume is good and is based on my Server
> Synch to the USNO

No, it says that it exits on signal 15, the program is told to
terminate. It has been killed.

SIGTERM 15 Term Termination signal

> “24 Jan 23:15:55 ntpd[16660]: refclock_open
> /dev/gps0: No such file or directory” - note2 = This is obviously the
> GPS, but the ntpd isn’t finding the GPS
>
> “24 Jan 23:15:55 ntpd[16660]: 127.127.20.0
> interface 127.0.0.1 -> (none)” - note3 = This I believe is in reference
> to the generic NMEA driver
> In reference to note2; I have used the udev-browse command to
> verify that my system is recognizing that my GPS is plugged in to my
> computer. It says that the GPS
> -DEVPATH/devices/pci0000:00/0000:00:13.1/usb6/6-2/6-2:1.0/ttyUSB0/tty/ttyUSB0-_.
> In the Local Reference Clock menu where it allows you to create a
> symlink; I have entered this information and it still results in the
> same log output.

I would like to read some documentation about you having to create any
symlink.

> I hope that this has cleared up what I have been able to do so far.
> Now the question is: How do I trouble shoot and fix this issue so that
> ntpd will use my GPS as a clock reference?

I use ntp, but I never had the chance to test a GPS receiver and connect
it to a computer with ntpd. So I would have to read some documentation
on that… Perhaps you have to communicate on some specific ntpd forum
or mail list, but they will probably want you to use CLI.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#12

Hello,
I get the feeling that you are trying to do something but don’t really understand what you are trying to do.

So, here are some IMO basics…

First, the ntpd. AFAIK it really isn’t supposed to run all the time (but could be wrong). The only time it should run is when it syncs with the Statum 2 NTP on the Internet you’re configured. And, after your system clock has been set and checked, the ntpd should go inactive until the next check.

Seems to me the GPS device is merely a serial device connected to your system. As such, there are no “brains” in the device, it’s simply a GPS radio receiver that connect to your system. For that reason, there should not be any “sync” – Sync to what? Certainly not between your openSUSE and the GPS device because the device has no brains… It simply collects data and sends to your system, and may receive some commands from your system.

So, to me your quest to do <something> with NTP is without reason or foundation… If your openSUSE time is properly set using NTP, you should be in good shape and nothing more needs to be done regarding accurate time.

As for your other errors… Well, there is a difference between critical and non-critical errors. The big question is whether your GPS application running on openSUSE (Is there such a thing as a DeLorme mapping app running on Linux?) or anything else (eg Google is a good bet, Google always wants to know where you are, and if GPS is available they’d be very happy using that over your ISP data).

IMO,
TSU

#13

On 2013-01-26 02:06, tsu2 wrote:
>
> Hello,
> I get the feeling that you are trying to do something but don’t really
> understand what you are trying to do.
>
> So, here are some IMO basics…
>
> First, the ntpd. AFAIK it really isn’t supposed to run all the time
> (but could be wrong). The only time it should run is when it syncs with
> the Statum 2 NTP on the Internet you’re configured. And, after your
> system clock has been set and checked, the ntpd should go inactive until
> the next check.

The daemon is active all the time, but most of the time it is just
waiting for the next event. Basically it tells the kernel to wake it up
so many seconds in the future. But it is “running” all the time :slight_smile:

> Seems to me the GPS device is merely a serial device connected to your
> system. As such, there are no “brains” in the device, it’s simply a GPS
> radio receiver that connect to your system. For that reason, there
> should not be any “sync” – Sync to what? Certainly not between your
> openSUSE and the GPS device because the device has no brains… It
> simply collects data and sends to your system, and may receive some
> commands from your system.

It is a way of speaking. From what I understand, the device writes to
the serial port at intervals a string that says the current time in some
format. The exact instant at which this write operation happens is
crucial. I fact, an USB is worse than a real serial port: USB is faster
but the exact i/o timing is unpredictable and varies a little.

In this manner the time clock of the computer and the GPS can be kept at
exact sync, and the computer can be a source of exact timing for others,
local network or internet, without using other internet clocks for
reference.

That is, instead of using other computers in Internet for keeping an
exact time, it is the other way round. They can use your computer.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#14

Am always open to some new use but it’s my experience that you’re only looking at timestamped GPS data. Granted, since the timestamp comes from the satellite it’s possible to use GPS as the NTP server but I doubt there is any advantage to doing that normally since terresterial Internet connections are usually more reliable than satellite.

IMO the main value of the timestamping is to improve GPS data time accuracy which wouldn’t necessarily be the same as the system clock.

IMO,
TSU

#15

On 2013-01-26 05:16, tsu2 wrote:
>
> Am always open to some new use but it’s my experience that you’re only
> looking at timestamped GPS data. Granted, since the timestamp comes from
> the satellite it’s possible to use GPS as the NTP server but I doubt
> there is any advantage to doing that normally since terresterial
> Internet connections are usually more reliable than satellite.

No, on the contrary.

All those clocks on the Internet get their time from somewhere, and that
somewhere is the GPS system. It is those GPS clock which feed Internet time.

Many computers on the Internet get their time from other computers, but
there must be a master source. The Stratum 1 systems take their timing
from sources more accurate than the Internet.

There is only another source of accurate time, and it is the atomic
clocks that some laboratories run, and not all give their time on Internet.

About the “satellite delay” you mention these are not normal satellites.
The exact delay is known and taken into account, because it is crucial
to the positioning system. Actually, it is the differences in delays
from one satellite to another which is measured to determine the exact
position.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#16

I think you’re making several inaccurate assumptions,

First you’d quickly find that a few Stratum 1 NTP are atomic clocks.
I think also that if each and all Stratum 1 and 2 NTP source their time properly, the chances the clocks are inaccurate are nil. The real problem is the link from the NTP to you, and in general the terrestial Internet is far more responsive and predictable than the issues involved with satellite links.

No, it’s not easy to account for latencies over an extremely long wireless connecion passing through atmospheric layers that shift.

BTW - If you’re running Linux connected to Satellite you should strongly consider implementing the hybla tcp/ip congestion control algorithm, but of course that is not the situation of the OP which is only using GPS for position data.

IMO,
TSU

#17

On 2013-01-26 16:56, tsu2 wrote:

> I think you’re making several inaccurate assumptions,
>
> First you’d quickly find that a few Stratum 1 NTP are atomic clocks.
> I think also that if each and all Stratum 1 and 2 NTP source their time
> properly, the chances the clocks are inaccurate are nil. The real
> problem is the link from the NTP to you, and in general the terrestial
> Internet is far more responsive and predictable than the issues involved
> with satellite links.

No, you are wrong. The time inaccuracies with the GPS satellite network
and proper GPS hardware are almost nil.

And the GPS network has a a time base atomic clocks.

Wikipedia

The Internet “clock” goes third, because it takes as a base the above two.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#18

:wink:
I guess we can agree to disagree…

I just don’t think there is anything that can be done to address the variable conditions related to a satellite link (satellite to earth), so it doesn’t really matter how accurate the satellites are. The best you can do is mitigate but the conditions will always be more unpredictable than the regular Internet.

TSU

#19

On 2013-01-27 00:26, tsu2 wrote:
>
> :wink:
> I guess we can agree to disagree…
>
> I just don’t think there is anything that can be done to address the
> variable conditions related to a satellite link (satellite to earth), so
> it doesn’t really matter how accurate the satellites are. The best you
> can do is mitigate but the conditions will always be more unpredictable
> than the regular Internet.

Impossible. Internet uses those satellites to regulate itself, so you
have first the errors of the satellite network, and then the errors of
the Internet network. You can read the literature on this respect to
confirm it if you don’t believe me.

–
Cheers / Saludos,

Carlos E. R.
(from 12.1 x86_64 “Asparagus” at Telcontar)

#20

The name of device you need to symlink to is most likely /dev/ttyUSB0. Click Browse, navigate to /dev and verify that /dev/USB0 exists. Then select it as link target.