Setting time on cRIO via remote front panel causes CPU to go to 100% for 90 seconds

[WNM]

The cRIO-9075 is a budget device that does not have a battery-backed date/time and as a result every time it is power cycled, the date/time reverts to something like 16:00:00 & 12/31/1969.    The RT code I run on these has a remote front panel interface avalable which can be accessed from a web browser running on a laptop with the LV2013 RTE installed and connected to the cRIO's Ethernet port.  It is through this browser interface that I can monitor and control the activitiesof the cRIO's RT and in turn FPGA code and I can also see the incorrect date. I have provided means for the date/time to be corrected to whatever the laptop thinks is correct.

Part of the information displayed by the RT code is the cRIO "health" information; amounts of various memory used and the various CPU loads.  The normal-priority CPU load runs around 30%. But just as soon as I cause the time/date to be corrected from 1969 to the present, the CPU load goes to values that vary from 98-to-100% and it stays at this level for about 90 seconds before dropping back to the more normal 30%.  During this high-usage 90 seconds, the Time/Date appears to be updated instantly and the RT code continues on with the tasks I programmed it to do (watch FPGA codes front panel, check RT health, report state to user, check for user inputs, sleep briefly and repeat) but something else seems to be launched in the background that really gets the RT system wound up.

A subsequent updating of the time/date (i.e. set to "NOW" again) does not cause another CPU spike.

Can anyone explain what's going on?   Is it caused by the little NI cRIO elf madly scrambling to advance all the clocks in the cRIO's house?

[mikeporter]

I have noticed the same thing before on other CRIO systems - no idea what is causing it. I'd vote for the elfs...

Mike...

PS: Don't Panic