SNTP Task to Synchronize time

[MQXuser]

I will call  (with the proper parameters)

SNTP_init();

in order to initialize the task .

1.-I would like to know if this task will automatically synchronize MQX and RTC time to be the same or would I have to do it myself?

2.-Does SNTP contains date information too?

Regards

[PetrM]

1. No, it only sets the MQX time

2. Yes, it also contains date information

PetrM

[MQXuser]

Thank you for the reply.

I will make a task that will be calling periodically SNTP_oneshot(), I want to poll the SNTP server every 60 minutes (as I read that was a default value for some clients). Question is the following:

Is there a better way to do the following?

_time_delay(60*60*1000); //60 Seconds * 60 Minutes * 1000(since the value is in ms)

[PetrM · Accepted solution]

Well, creation of another task just for this is maybe too heavy.

Maybe you should consider to incorporate the check into one of you existing tasks.

You can use for example RTC stopwatch request for easy check. 

PetrM

[MQXuser]

I seem to have a problem after calling SNTP_oneshot()  function. Problem is that sometimes my tasks stop running. There are no stack overflows, neither unhandled interrupts, I dont see any memory corruption. All my task status are OK and waiting for a time delay, message blocked, etc but none of them run again.

Do any of you have a clue about what could be going on?

[dspNeil]

Please help!

I'm having a similar issue:

I'm calling SNTP_oneshot( ipaddr, 3000 ) from a rather low priority thread, while also hosting a web server and some other networking APIs on higher priority threads. When SNTP_oneshot fires, everything just seems to lockup, for much longer than 3000ms, unless the time is resolved quickly. Should I not be calling this from a low priority thread? Do I need mutex locks to prevent my other thread from being serviced? Is 3000ms overkill?

This is seriously hindering my board's performance, so any insight would be much appreciated!

[traceecraft]

Hi Neil,

I am seeing the same issue with the SNTP_oneshot call as you have described, our set up is very similar as well, the task calling SNTP_oneshot is a lower priority task.

Were you able to resolve your issue?   Any insight you can shed would be appreciated!    With our system, the issue is not 100% recreatable so I'm not sure what is the magic recipe to recreate it either for debug.

Thanks.

[dspNeil]

I never found a fix for this, and it is rearing it's ugly head again. I seem to be able to reproduce it reliably by setting my default gateway to an invalid address on my local network. As a note, I also tried setting my NTP server as an IP address, instead of an address that needs to be resolved. As long as all of the settings are correct, then my task continues. The real problem is though, if my users enter wrong information, I have no way to break out of the SNTP_oneshot, until it magically decides to give up trying, which can take several minutes. This is very unacceptable, and searching the forums, it seems to be an issue that's been around for a couple of years.

[Martin_]

Hi,

I think it doesn't magically decide to give up, it gives up after 3 minutes ARP timeout, because a peer's ethernet address is not known. If I SNTP_oneshot an IP at different subnet via unreachable gateway, I get 180 s timeout - with RTCSERR_ARP_CANT_RESOLVE error code returned by SNTP_oneshot. The RTCS finds out that SNTP_oneshot tries to contact a peer at different subnet. Thus, it should send such a packet via default gateway. So it uses ARP to ask "who has default gateway's IP address?" on your local network, but since there is none existing, the ARP request times out without being responded. The SNTP packet can't be sent and thus the SNTP timeout timer doesn't start.

[donmarquardt]

Hi:

I have noticed a similar problem in that if I enter an invalid SNMP destination address (eg 10.0.0.2) when I do a sendto it takes 180 seconds before that sendto timesout.This situation simulates lousing a wireless connection to a router. Checking further into why this is happening I discovered that in arp_prv.h the timesouts are

#define ARPTIME_RESEND_MIN	5000	/*  5 sec */
#define ARPTIME_RESEND_MAX	30000	/* 30 sec */
#define ARPTIME_EXPIRE_INCOMPLETE	180000L	/*  3 min */

And the problem I have is that there can be up to 10 destinations with 5 retries and therefore  10*5*3 (150) minutes before I see a timeout and reactivate/reset my watchdog. I can change my code so the watchdog is kicked before each sendto but the timeout seems too long. I changed the times to

#define ARPTIME_RESEND_MIN	500	/*  .5 sec */
#define ARPTIME_RESEND_MAX	1000	/*  1 sec */
#define ARPTIME_EXPIRE_INCOMPLETE	5000L	/*  5 sec */

and my system seems to be functioning without moving the watchdog kick into the lower level code.

Does anyone see an issue with reducing these values? ARP responses should be quick.