Clock is randomly delayed

[lucasmaziero]

Hello,
I do not understand why the clock is randomly delayed, but the interesting thing is that it delay exactly the time set in the variable "updateInterval" or the function "setUpdateInterval ()", I already did several tests but I can not find this bug.

Anyone have any idea where this problem is?

[laurentopia]

You didn't specify the amount of delay, if it's in the seconds, it could be variations in network lag between you and the ntp server.

[jbrown123]

This is actually a bug in NTPClient::forceUpdate(). Here's what happens.

In NTPClient.cpp on line 68 a request is sent for the time via UDP.

NTPClient/NTPClient.cpp

Line 68 in 020aaf8

this->sendNTPPacket();

Lines 70-78 wait for a response or timeout after 1 second (line 76).

NTPClient/NTPClient.cpp

Lines 70 to 78 in 020aaf8

	// Wait till data is there or timeout...
	byte timeout = 0;
	int cb = 0;
	do {
	delay ( 10 );
	cb = this->_udp->parsePacket();
	if (timeout > 100) return false; // timeout after 1000 ms
	timeout++;
	} while (cb == 0);

What happens in this case is that a request goes out, but the response comes back after the 1 second timeout and is thus not processed by the code in NTPClient. This response sits in the buffer until the NEXT update request. On the next update, a new request is sent, but the OLD response (still sitting in the buffer) is processed. This causes the time to be off by whatever the interval is between calls to update (actually to forceUpdate which is called by update).

I verified this bug by making sendNTPPacket() public (altered the header file) and then calling update followed immediately by sendNTPPacket (thus putting an extra response in the queue). This causes the system to be forever off by whatever the update interval is.

I'm guessing you also would like the fix ...

The fix is to insert the following code BEFORE the request is sent on line 68:

  // flush any existing packets
  while(this->_udp->parsePacket() != 0)
    this->_udp->flush();

This works perfectly for me even with the aforementioned test code in place.

I'll submit this as a pull request shortly.

[lucasmaziero]

@jbrown123 Thank you very much for the contribution.

[aentinger]

Fixed by #62 😉

[brich126]

Hello. I use NtpClient for ESP8266. After updating NtpClient to 3.2.1, "timeClient.update()" does not return "true" after a successful time update. In 3.2.0 - returned "true" after a successful time update.
In the "Basic" example, insert "Serial.println(timeClient.update());" into the loop. Always outputs "0", but the time is updated.
I think it's after these changes. Can you fix it? Thank you.