Præcis tidtagning

ANSI C har kun time.h og time som regner i sekunder.

Men mange systemer inkl. linux har sys/timeb.h og ftime som
kører i ned til 1/1000 sekund.

... og så husker vi lige at opløsningen på klokken ikke er mere en 1/18.2 sek...

JP

Andre har sys/time.h og gettimeofday som kan køre ned til mikro sekunder.

hmm, tror ikke jeg er helt med :S

kan ikke lige finde noget om time.h

Kode eksempel:

#include <sys/time.h>
#include <stdio.h>

int main()
{
  struct timeval tv;
  struct timezone tz;
  gettimeofday(&tv,&tz);
  printf(" %ld %ld\n",tv.tv_sec,tv.tv_usec);
  return 0;
}

Eller hvis du skal have tids forskel:

#include <sys/time.h>
#include <stdio.h>

int main()
{
  struct timeval tv1,tv2;
  struct timezone tz1,tz2;
  gettimeofday(&tv1,&tz1);
  sleep(10);
  gettimeofday(&tv2,&tz2);
  printf("%ld\n",(tv2.tv_sec-tv1.tv_sec)*1000000+(tv2.tv_usec-tv1.tv_usec));
  return 0;
}

jpvj>

????

På min Linux box giver:

#include <sys/time.h>
#include <stdio.h>

int main()
{
  int i;
  struct timeval tv[20];
  struct timezone tz[20];
  for(i=0;i<20;i++) {
      gettimeofday(&tv[i],&tz[i]);
  }
  for(i=0;i<20;i++) {
      printf(" %ld %ld\n",tv[i].tv_sec,tv[i].tv_usec);
  }
  return 0;
}

f.eks. følgende output:

1065633733 247624
1065633733 247630
1065633733 247632
1065633733 247633
1065633733 247635
1065633733 247636
1065633733 247638
1065633733 247639
1065633733 247641
1065633733 247642
1065633733 247644
1065633733 247645
1065633733 247646
1065633733 247648
1065633733 247649
1065633733 247651
1065633733 247652
1065633733 247654
1065633733 247655
1065633733 247657

hvilket indikerer en opløsning langt over 1/18.2 sekund.

Tak for svaret, det var lige hvad jeg havde brug for

arne_v> Det er korrekt at opløsningen er i millisekunder i ovennævnte kald. CPU'er efter Pentium har en instruction counter, så man med endnu større opløselighed kan måle tiden (det bliver i nano sekunder).

Det afgørende er, at hvor ofte task scheduleren kører. Da denne er interrupstyret af clock interruptet skal der pilles ved timerkredsen (og det gøres der naturligvis). I en standard linux installation på i386 kører scheduleren 100x/sek (og ikke 1/18.2 gange i sekundet som jeg fejlagtigt skrev i et øjebliks kortslutning), dvs. man er ikke garanteret mere end at "måle processen" kører oftere end 100x/antal processer (antaget at de har samme prioritet, hvilket de naturligvis ikke har i praksis).

Med ex. 10 processer (der belaster så meget de kan, dvs. ikke suspender), vil programmet således kun køre 10x i sekundet i 1/10 sek. Inden for det 1/10 del sekund kan man målet meget præcist med utime (mener jeg det hedder i C) og når tråden bliver suspendet målet man slet ikke.

Dvs. man kan kun måle præcist i de intervaller hvor processen kører (ellers tag et kig på RTLinux).

Udover at jeg angav scheduleren timing forkert, var kommentaren nok for tynd til at blive forstået. Håber dette har forklaret hvad jeg mente/tænkte.

JP

Digital

Er det en lang måde at sige på at det er misvisende at lave
tids målinger på systemer hvor der kører andre CPU intensive processer ?

Ja da :-)