Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1387958

Summary: minpoll and maxpoll only communication but not really synchronize,isn't it?
Product: Red Hat Enterprise Linux 7 Reporter: muahao <muahao>
Component: ntpAssignee: Miroslav Lichvar <mlichvar>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: low Docs Contact:
Priority: unspecified    
Version: 7.2   
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-10-24 06:35:46 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description muahao 2016-10-24 03:45:03 UTC 
## MY QUESTION：minpoll and maxpoll only communication but not really synchronize,isn't it?

Hello my friends,I have a problem want to know,why ntp syncorized from uppper stratum NTP server so slowly??

minpoll ,maxpoll at my view is not really "synchronize and do adjust system's time to correct ",but only "communication with upper NTP server and after almost 10-20mins really do synchronize and adjust system's time by upper NTP server"

__My question is can I adjust my client server's parameter to make my client to synchronize from upper NTP server frequently?__


## Steps to Reproduce:
Bellow is just a test ,so only one NTP server was configured,just want to know NTP's synchronization behavior

NOW:


	#date
	Mon Oct 24 10:54:55 CST 2016


reset date time:


	#date -s "2016-10-24 10:52"


after about 10min:


	#ntpq -np
	     remote           refid      st t when poll reach   delay   offset  jitter
	==============================================================================
	10.101.242.8    10.233.7.230     3 u    4   64  377    0.102  175930.   0.070



after about 10min:



	#ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
	==============================================================================
	*10.101.242.8    10.233.7.230     3 u    4   64  377    0.102  175930.   0.070



after about  10min:

time was adjusted by NTP
Comment 2 Miroslav Lichvar 2016-10-24 06:35:46 UTC 
There is an option called "tinker stepout" (described in the ntp_misc(5) man page), which controls how long ntpd waits before stepping the clock. The default value is 900 seconds (15 minutes). It's mainly useful to avoid steps when the network is congested and the NTP measurements include a large error. If you need a faster reaction, you can add "tinker stepout 300" or similar to ntp.conf.