This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Call to clock_gettime(CLOCK_MONOTONIC, &monotime) jumps 131073 seconds (about 2^17)

Other Parts Discussed in Thread: AM3359

I am using an the AM3359 processor and we see a jump of roughly 36 hours at least once a week.  We are using 3.2.0 Linux with the build from linux-3.2.0-psp04.06.00.11.  I have seen the post on 

https://groups.google.com/forum/#!topic/beagleboard/PLIroG3SVOU

where a jump of 2^17 seconds is discussed with the dmtimer and a patch for 3.2.  I verified that the patch posted by Vaibhav Hiremath was the code that we have running but we are still seeing the jump in time.  I have checked the timer and it is running at 32kHz.

root@am335x-evm:/# grep -i clock /var/log/messages
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.000000] OMAP clocksource: GPTIMER1 at 32768 Hz
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.000000] sched_clock: 32 bits at 32kHz, resolution 30517ns, wraps every 131071999ms
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.138671] Switching to clocksource gp timer
Apr 22 15:28:24 am335x-evm user.info kernel: [ 1.338287] clock: disabling unused clocks to save power
Apr 22 15:28:24 am335x-evm user.info kernel: [ 1.483184] omap_rtc am33xx-rtc: setting system clock to 2015-04-22 15:28:13 UTC (1429716493)

root@am335x-evm:/# grep -i timer /var/log/messages
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.000000] OMAP clockevent source: GPTIMER2 at 24000000 Hz
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.000000] OMAP clocksource: GPTIMER1 at 32768 Hz
Apr 22 15:28:24 am335x-evm user.info kernel: [ 0.138671] Switching to clocksource gp timer
Apr 22 15:28:24 am335x-evm user.info kernel: [ 1.082641] OMAP Watchdog Timer Rev 0x01: initial timeout 60 sec
Apr 22 15:28:24 am335x-evm user.info kernel: [ 1.215393] oprofile: using timer interrupt.

What needs to be done to keep the CLOCK_MONOTONIC from jumping?  We already have an investment in time in the release we are using.

Here is a copy of the code that shows the jump.

#include <iostream>
#include <unistd.h>
#include <signal.h>
#include <termios.h>
#include <cerrno>
#include <string>
#include <algorithm>
#include "MsTimer.h"
#include <time.h>
#include <stdio.h>
#include <sys/sysinfo.h>

namespace CONST {
const char Application[] = "TimerChk";
const char Version[] = "0.0.2";
const char BuiltOn[] = __DATE__ " " __TIME__ ;
}


int main (int argc, char *argv[]) {

bool bDone = false;
time_t rawtime, oldrawtime;
uint32_t monotime, oldmonotime;
uint32_t oldinfotime;
uint32_t oldrealtime;
uint32_t oldrawmono;

struct timespec realtime, rawmono;
struct sysinfo info;

{
struct timespec monotimesample, realtimesample;
clock_getres(CLOCK_REALTIME, &realtimesample);
clock_getres(CLOCK_MONOTONIC, &monotimesample);
std::cerr << "Real Time data: sec " << realtimesample.tv_sec << " nsec " << realtimesample.tv_nsec;
std::cerr << " Mono Time data: sec " << monotimesample.tv_sec << " nsec " << monotimesample.tv_nsec;
std::cerr << std::endl << std::endl;
}

sysinfo(&info);
clock_gettime(CLOCK_REALTIME, &realtime);
clock_gettime(CLOCK_MONOTONIC_RAW, &rawmono);
oldrawmono = rawmono.tv_sec;
oldrealtime = realtime.tv_sec;
oldinfotime = info.uptime;
std::cerr << "Raw Monotonic, Up Time, Monotonic Timer, Real-Time timer, time Timer" << std::endl;
time(&oldrawtime);
oldmonotime = SecTimer();
while (!bDone)
{
time(&rawtime);
monotime = SecTimer();
sysinfo(&info);
clock_gettime(CLOCK_REALTIME, &realtime);
clock_gettime(CLOCK_MONOTONIC_RAW, &rawmono);
if ((abs(monotime - oldmonotime) > 2) || (abs(rawtime - oldrawtime) > 2) ||
(abs(info.uptime - oldinfotime) > 2) || (abs(realtime.tv_sec - oldrealtime) > 2) || (abs(rawmono.tv_sec - oldrawmono) > 2))
{
bDone = true;
}
oldmonotime = monotime;
oldrawtime = rawtime;
oldrawmono = rawmono.tv_sec;
oldrealtime = realtime.tv_sec;
oldinfotime = info.uptime;
std::cerr << rawmono.tv_sec << ", " << info.uptime << ", " << monotime << ", " <<
realtime.tv_sec << ", " << rawtime << ", " << ctime(&rawtime);
// printf("date: %s", ctime(&rawtime));
sleep(1);
}

return 0;
}

  • Hello R_Culley,

    Could you attach the "MsTimer.h"? I'll try to reproduce this in different platforms.

    Best regards,
    Kemal

  • Hi Kemal,

    MsTimer.h 

    /**
     * @file   MsTimer.h
     * @Author Culley
     * @date   April 2015
     *
     */

    #ifndef __MS_TIMER_H__
    #define __MS_TIMER_H__

    #include <stdint.h>

    extern uint32_t SecTimer(void);

    extern bool SecExpired(uint32_t until);

    #endif  

    plus 

    MsTimer.c

    /**
     * @file   MsTimer.c
     * @Author Culley
     * @date   April 2015
     *
     */

     

    #include "MsTimer.h"

    #include <time.h>

    uint32_t SecTimer(void) {
    struct timespec tp;
    if (clock_gettime(CLOCK_MONOTONIC, &tp) == 0) { return((uint32_t)tp.tv_sec); }
    return(0);
    }

    bool SecExpired(uint32_t until) {
    return(SecTimer() >= until);
    }

    Thanks

  • Hello R_Culley,

    I ran the test code on starter kit and beagle bone black with linux-3.2.0-psp04.06.00.11 for approximately 24 hours.

    root@am335x-evm:/# ./clock
    Real Time data: sec 0 nsec 1 Mono Time data: sec 0 nsec 1

    Raw Monotonic, Up Time, Monotonic Timer, Real-Time timer, time Timer
    88, 89, 88, 1430152561, 1430152561, Mon Apr 27 16:36:01 2015
    89, 90, 89, 1430152562, 1430152562, Mon Apr 27 16:36:02 2015
    90, 91, 90, 1430152563, 1430152563, Mon Apr 27 16:36:03 2015
    ........................................................................................................................
    ........................................................................................................................
    91554, 91555, 91554, 1430244028, 1430244028, Tue Apr 28 18:00:28 2015
    91555, 91556, 91555, 1430244029, 1430244029, Tue Apr 28 18:00:29 2015
    91556, 91557, 91556, 1430244030, 1430244030, Tue Apr 28 18:00:30 2015

    It seems there is no jumps. It is possible your board to get affected by the NTP adjustments or you may have trouble with the RTC. Check these treads out. Seems they had the same problem like you.

    e2e.ti.com/.../417299
    e2e.ti.com/.../265663
    e2e.ti.com/.../1073951

    Best regards,
    Kemal

  • Thanks Kemal,

    I am actively looking into the threads that you sent.  

    The first thread with the errata specifies that the grounding of the two oscillators need to be grounded to the nearest processor ground pin and not a generic ground.  We are using the ZCZ part but layout does conform to the errata and routes the grounds of the oscillator circuit back to the adjacent pins.  We are also experiencing a jump forward and not a backward jump like the first thread had demonstrated.

    I have made the adjustments to the code listed in the second thread.

    I am just starting to look at the third thread now.

    We do no have ntpd running on the system so were are not currently adjusting the clock.  I just recently ran ntpd after enabling in busybox just recently to give the current date.

    An example of the test I ran gave the following results:

    138287, 138286, 1428882166, 1428882166, Sun Apr 12 23:42:46 2015

    269360, 269359, 1429013240, 1429013240, Tue Apr 14 12:07:20 2015

    This was before I added the CLOCK_MONOTONIC_RAW into the code.  I hope you still have your test going since as you can see my took a little longer than 24 hours to produce.  I have also pulled out my Beagle bone white and put an evm image on it and started the same TimerChk test.

    What are the troubles with the RTC that I should look for?

    Best Regards,

    R_Culley

  • Hello Culley,

    I will leave the test running for the next 3 days.

    Best regards,
    Kemal
  • Hello again,

    After 3 days of running the test, clock drift has not observed on BBB.

    ..............................................................................................................................................

    285721, 285722, 285721, 1431110127, 1431110127, Fri May  8 18:35:27 2015                                                                                        
    285722, 285723, 285722, 1431110128, 1431110128, Fri May  8 18:35:28 2015                                                                                        
    285723, 285724, 285723, 1431110129, 1431110129, Fri May  8 18:35:29 2015

    Your system may require different clock speed.

    Could you post the output of the kernel time variables taken by adjtimex.

    adjtimex -p
    adjtimex -c

    You can download the adjtimex from here.

    Best regards,

    Kemal

  • Hello Kemal,

    I did get the system to run for a full week without a time jump.  The change was to use the 24MHz clock rather than the 32.768KHz clock.  However, the RTC clock is battery back so there is a preference for using the slower clock.

    There are a couple boards with the extra grounding of the clock ground to the closest ground point that we are running the timer test on.  One failed within the first 36 hours.

    adjtimex gave me the following results:

    root@am335x-evm:/usr/sbin# adjtimex -p
    mode: 0
    offset: 0
    frequency: 0
    maxerror: 16000000
    esterror: 16000000
    status: 64
    time_constant: 2
    precision: 1
    tolerance: 32768000
    tick: 10000
    raw time: 1431073523s 477804us = 1431073523.477804
    return value = 5
    root@am335x-evm:/usr/sbin# adjtimex -c

    --- current --- -- suggested --
    cmos time system-cmos error_ppm tick freq tick freq
    1431073545 -1.035135
    1431073555 -1.035227 -9.2 10000 0
    1431073565 -1.035196 3.1 10000 0 9999 6350475
    1431073575 -1.035227 -3.1 10000 0 10000 203125
    1431073585 -1.035135 9.2 10000 0 9999 5950475
    1431073595 -1.034922 21.3 10000 0 9999 5156725
    1431073605 -1.035257 -33.5 10000 0 10000 2196875
    1431073615 -1.035227 3.0 10000 0 9999 6356725
    root@am335x-evm:/usr/sbin#

    I will let you know about the grounding trial.

    Thanks,

    R_Culley