the problem of gettimeofday

[dophine]

Hi all,

I just wrote a small problem to check gettimeofday in a multi-cores environment.

int timediff(double fTimeQvs, double fTimeTcp)
{
        int iTimeDiff;
        iTimeDiff = (((((int)fTimeQvs)/10000) - (((int)fTimeTcp)/10000)) * 3600) * 1000000;
        iTimeDiff += ((((((int)fTimeQvs)/100)%100) - ((((int)fTimeTcp)/100)%100)) * 60) * 1000000;
        iTimeDiff += ((((int)fTimeQvs)%100) - (((int)fTimeTcp)%100)) * 1000000;
        iTimeDiff += (((long long)(fTimeQvs*1000000))%1000000) - (((long long)(fTimeTcp*1000000))%1000000);

    return iTimeDiff;
}

int main()
{
        struct timeval cur;
        gettimeofday(&cur, 0);

        for(;;)
        {
                struct timeval new_time;
                gettimeofday(&new_time, 0);

                double diff = difftime(new_time.tv_sec,cur.tv_sec);
                if(diff > 1.0)
                        printf("Big:%ld.%ld,%ld.%ld,%lf\n",new_time.tv_sec,new_time.tv_sec, cur.tv_sec,cur.tv_usec,diff);
                else if(diff < 0.0)
                        printf("Small::%ld.%ld,%ld.%ld,%lf\n",new_time.tv_sec,new_time.tv_usec, cur.tv_sec,cur.tv_usec,diff);
                cur.tv_sec = new_time.tv_sec;
        }
        return 0;
}

Here is the result:
Small::1217485404.98014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.99014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.100014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.101013,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.102014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.103014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.104014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.105014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.106014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.107013,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.108013,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.109013,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.110014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.111014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.112014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.113014,1217489802.813903,-4398.000000
Big:1217489802.1217489802,1217485404.813903,4398.000000
Small::1217485404.114014,1217489802.813903,-4398.000000

so is there any way to overcome it?

[Ancient Dragon]

looks like you are attempting to use GNU library non-standard time functions. See this article how to use it.

[dophine]

looks like you are attempting to use GNU library non-standard time functions. See this article how to use it.

Yes, the problem is how time can move forwards and backwards again. and the difference is 4389. I did search in the internet. I found it is caused by the clocksource if clocksource is TSC. however, I am using HPET.

[Salem]

The first thing I would do is call 'setaffinity' (your API may vary), to lock the process to a single core. Then make sure you're actually getting the desired result.