[an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive] (none) [an error occurred while processing this directive] [an error occurred while processing this directive] [an error occurred while processing this directive][an error occurred while processing this directive]
 
[an error occurred while processing this directive] [an error occurred while processing this directive]
Skåne Sjælland Linux User Group - http://www.sslug.dk Home   Subscribe   Mail Archive   Forum   Calendar   Search
MhonArc Date: [Date Prev] [Date Index] [Date Next]   Thread: [Date Prev] [Thread Index] [Date Next]   MhonArc
 

Re: [CPROG] En ordentlig timing



On Sat, 03 Nov 2001 19:52:11 +0100, Peter Aagaard Kristensen wrote:

>  >> En løkke omkring en sammenligning med gettimeofday() (som er både
>  >> hurtig og med høj præcision) er umiddelbart mit bedste bud, men
>  >> stadig ikke til de tidsintervaller, du snakkede om. Du kan også se
>  >> på select()/pselect(), som måske er lidt mere portable.
>  >Det hjælper vel ikke rigtig noget med at lave gettimeofday()
>  >systemkald når vi snakker om forsinkelser i 100nsec området. Jeg ved
>  >ikke hvad tiden for kontekst skift er under linux præcist, men under
>  >Minix er det oppe i omkring et 1/2 mikrosekund (900Mhz Celeron), og
>  >Linux er næppe hurtigere. På 100ns når man ikke at udføre mange
>  >instruktioner.
> gettimeofday og andre upræcise tidspunktioner kan godt bruges hvis det
> er til at måle hvor lang tid et busywait tager. Hvis man måler tiden,
> gentager busywait f.eks. 1 million gange og måler tiden igen har man et
> nogenlunde præcist svar på hvor lang tid 1 busy wait tager. Så kan man
> gentage sin busy wait x antal gange som passer til den tid man vil
> vente.
> Hvis målingen ikke er blevet forstyrret af for meget af kontekst skift
> så kan man
> busy waite rimeligt præcist.

Ikke når dit interval er 100ns. Det hjælper ikke at gettimeofday() er
præcist hvis det tager 2us at udføre, vel?

Hvis du vil lave busy-wait så må den bedste metode være med tsc, og som
Mads skrev:

long until  = read_tsc_low() + 100*(1E9/CPUFREQ) while(until >
read_tsc_low()) ;

> Men jeg må nok opgive de 100ns' præcision - det kommer nok aldrig til at
> virke i
> multitaskingsmiljøer uden en eller anden form for hardware timer, og
> nogle meget
> hurtige processorer :-(

Du _har_ jo hardware timere til rådighed i en PC, selvom de er noget
gammelt skrammel.

Men med de forsinkelser du snakker om er det klart at det kan _ikke_ lade
sig gøre i et user-space program. Du er nødt til at skrive et kerne
drivprogram istedet. For optimalt resultat så skriv det til RealTime
Linux.

Det er klart at du nok _ikke_ skal regne med at kunne lave divx enkodning
samtidig med din brændning ;-)

> Derfor ender det nok med at jeg implementerer selve timingen(og derved
> brændingen)
> i hardware og kun lader PC'eren styre hvordan det sker.

Tja, hver sin smag ;-)

Mvh Morten


 
Home   Subscribe   Mail Archive   Index   Calendar   Search

 
 
Questions about the web-pages to <www_admin>. Last modified 2005-08-10, 20:09 CEST [an error occurred while processing this directive]
This page is maintained by [an error occurred while processing this directive]MHonArc [an error occurred while processing this directive] # [an error occurred while processing this directive] *