NTP Servier - Revision history

Akseewa11: Blanked the page

2013-11-08T18:21:41Z

Blanked the page

← Older revision		Revision as of 18:21, 8 November 2013
Line 1:		Line 1:
	proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).

	~~'''Setup Procedure (Serverside)'''~~
	~~Plug the GPS device into proto via USB.~~
	~~Make a symbolic link from the presence of the USB device on proto to /dev/gps0.~~
	~~Use the configuration file in the footer of this page or edit your configuration file to contain many of its ideas.~~
	~~Restart the ntp daemon.~~

	~~'''Setup Procedure (Clientside)'''~~
	~~Insert this line into your ntp.conf: "server 159.28.230.6"~~

	~~''Debugging'''~~


	~~'''Explanation of Choices'''~~
	Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.

Akseewa11 at 18:20, 8 November 2013

2013-11-08T18:20:36Z

← Older revision		Revision as of 18:20, 8 November 2013
Line 1:		Line 1:
	proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).		proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).

	'''Setup Procedure (Serverside)'''		'''Setup Procedure (Serverside)'''
	Plug the GPS device into proto via USB.		Plug the GPS device into proto via USB.
	Make a symbolic link from the presence of the USB device on proto to /dev/gps0.		Make a symbolic link from the presence of the USB device on proto to /dev/gps0.
Line 7:		Line 7:
	Restart the ntp daemon.		Restart the ntp daemon.

	'''Setup Procedure (Clientside)'''		'''Setup Procedure (Clientside)'''
	Insert this line into your ntp.conf: "server 159.28.230.6"		Insert this line into your ntp.conf: "server 159.28.230.6"

	'''Debugging'''		''Debugging'''


	'''Explanation of Choices'''		'''Explanation of Choices'''
	Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.		Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.

	~~[[Media:Example.ogg]]~~

Akseewa11 at 18:19, 8 November 2013

2013-11-08T18:19:22Z

← Older revision		Revision as of 18:19, 8 November 2013
Line 16:		Line 16:
	Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.		Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.

	[[~~File~~:~~ntp~~.~~conf~~]]		[[Media:Example.ogg]]

Akseewa11: Created page with "proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located..."

2013-11-08T18:18:40Z

Created page with "proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located..."

New page

proto.cs.earlham.edu is an ntp timeserver for Earlham's network. The time value it outputs come from some weighted average of two inputs. The first input is a NIST server located in Chicago. The second input is a GPS device on the fourth floor of dennis (in a box connected to the 4th floor lab's closet).

'''Setup Procedure (Serverside)'''
Plug the GPS device into proto via USB.
Make a symbolic link from the presence of the USB device on proto to /dev/gps0.
Use the configuration file in the footer of this page or edit your configuration file to contain many of its ideas.
Restart the ntp daemon.

'''Setup Procedure (Clientside)'''
Insert this line into your ntp.conf: "server 159.28.230.6"

'''Debugging'''

'''Explanation of Choices'''
Since it is easy to configure one's time to a NIST timeserver and NIST uses highly accurate atomic clocks, you might wonder why we bother with the GPS. The locality of the GPS elimintates network latency and network jitter as sources of error. While, for Earlham, the GPS signal may be more accurate, it is also less reliable. Somebody might accidentally unplug the GPS and HIP might not notice for a few hours/days, whereas the NIST server's importance means that attentive, skillful people would notice problems sooner. Considering this worst case scenario, and the fact that the different between 3:17:30 and 3:17:20 100% of the time is less important to most people than the difference between 4:17:30 and 3:17:30 0.28 percent of the time, it is best to mix the inputs.

[[File:ntp.conf]]