[linux] Re: Timer gebeuren onder Linux

[Daniel C. von Asmuth]

Aldus schreef Cecil Westerhof op Wed, Dec 19, 2007 at 08:27:55PM +0100:
> Op woensdag 19-12-2007 om 15:29 uur [tijdzone +0100], schreef Udo van
> den Heuvel:
> > Roeland Th. Jansen wrote:
> > > dat is een stukje kernel wijziging..
> > 
> > Eenvoudig te doen.
> > Wellicht al gebeurd?
> > Kijk eens in /proc/config.gz? (mits aanwezig)
> 
> Het enige waar ik eventueel invloed op kan hebben is het programma. De
> hardware en OS zijn gewoon een gegeven.
> 
> 
> > >> Ik heb het vermoeden dat de functie iedere keer voor duizenden (als het
> > >> niet nog veel meer zijn) meetpunten wordt aangeroepen. (En voor alle
> > >> meetpunten tegelijkertijd.) 
> > 
> > Er worden duizenden processen gestart op hetzelfde moment?
> > Of threads? Of hoe/wat precies?
> 
> Dat is de grap, dat weet ik dus niet precies. Ik weet alleen dat voor al
> die meetpunten gegevens worden verzameld en dat op seconde 43 van alle
> punten de gegevens verwerkt gaan worden. Ik heb begrepen dat dit timer
> gestuurd is, maar het project heeft een kleine tien keer een andere
> ontwikkelaar gekregen, dus dit is alleen maar een opmerking van hoe het
> volgens de vorige ontwikkelaar is geimplementeerd. Deze wist dat dus ook
> niet zeker. :-{
> 
> 
> > ALs het om processen gaat is het misschien beter de processen al in RAM,
> > draaiend, te hebben zodat ze allemaal tegelijk kunnen starten met hun taak.
> > Dat scheelt de starttijd elke keer.
> 
> Ik vermoed dat dat al gebeurd.

Voor mij is het nog niet geheel helder. Is het bijvoorbeeld een probleem als
de verwerking van de gegevens twee seconden later start?  Kun je de timer
veranderen zodat-ie op de 42-e seconde afgaat? Hoeveel (reken)tijd is
gemoeid met het verzamelen van die gegevens? Kun je het niet oplossen door 
je verwerkingsprogramma een heel hoge prioriteit te geven?

Suc6,



Daniel 

-- 
	This algorithm terminates in O(1) time - for large values of 1.