Yep the -h option did it.  It is now rock solid!  However it get the feeling things will get HOT.  Can`t get something 
for nothing ;-)

-----Message d'origine-----
De : Hans-Peter Reichert [mailto:community-noreply@qnx.com] 
Envoyé : 30 juillet 2010 02:24
À : osmeta-core_os
Objet : Re: RE: Can`t explain delay

the kernel trace does not show any other obvious reason.
we had a similar problem with 6.4.0, 6.4.1 related to Intel power mgmt.
the workaround was to start procnto with "-h", disabling pwr mgmt with that option we got rid of the "gap".
there was a PR(72535) on this.
/hp

> I guess it could.  I will need to move it to a different computer that 
> I`m sure doesn`t have SMI enable to test this theory.  I wanted to be 
> sure I wasn` t missing anything obvious in the log file.
>  
> -----Message d'origine-----
> De : Neil Schellenberger [mailto:community-noreply@qnx.com]
> Envoyé : 29 juillet 2010 12:10
> À : osmeta-core_os
> Objet : Re: Can`t explain delay
> 
> Other much more knowledgeable people will probably chime in, but if 
> this is
> x86 could it be SMI?
> 
> On Thu, 2010-07-29 at 12:05 -0400, Mario Charest wrote:
> > The attached kev file ( compressed with 7z ) was generated on 6.5.0.    I`d 
> appreciate if someone could take a look.  I could send the file in 
> .zip format  but it`s twice the size.
> > 
> > Process to look at is encodeur.exe and the thread named 
> > TickJobThread which
> is woken up by a timer set a 1ms and priority 255.
> > 
> > At event 466750 you`ll see the thread go in READY state.  It goes in 
> > RUNNING
>  state 220us later.  Can`t see why it`s taking so long.
> > 
> > The same thing happends at 514137, but this time it takes 349us to 
> > go from
> READY to RUNNING.
> > 
> > There are no other thread running at this priority and the data 
> > doesn`t
> seems to indicate it`s related to interrupts. 
> > 
> > What am I missing?
> > 
> > 
> > 
> > _______________________________________________
> > 
> > OSMeta
> > http://community.qnx.com/sf/go/post61072
> 
> 
> 
> _______________________________________________
> 
> OSMeta
> http://community.qnx.com/sf/go/post61074
> 






_______________________________________________

OSMeta
http://community.qnx.com/sf/go/post61153

Would be nice to have the -h option but on a per core/processor basis.  

-----Message d'origine-----
De : Hans-Peter Reichert [mailto:community-noreply@qnx.com] 
Envoyé : 30 juillet 2010 02:24
À : osmeta-core_os
Objet : Re: RE: Can`t explain delay

the kernel trace does not show any other obvious reason.
we had a similar problem with 6.4.0, 6.4.1 related to Intel power mgmt.
the workaround was to start procnto with "-h", disabling pwr mgmt with that option we got rid of the "gap".
there was a PR(72535) on this.
/hp

> I guess it could.  I will need to move it to a different computer that 
> I`m sure doesn`t have SMI enable to test this theory.  I wanted to be 
> sure I wasn` t missing anything obvious in the log file.
>  
> -----Message d'origine-----
> De : Neil Schellenberger [mailto:community-noreply@qnx.com]
> Envoyé : 29 juillet 2010 12:10
> À : osmeta-core_os
> Objet : Re: Can`t explain delay
> 
> Other much more knowledgeable people will probably chime in, but if 
> this is
> x86 could it be SMI?
> 
> On Thu, 2010-07-29 at 12:05 -0400, Mario Charest wrote:
> > The attached kev file ( compressed with 7z ) was generated on 6.5.0.    I`d 
> appreciate if someone could take a look.  I could send the file in 
> .zip format  but it`s twice the size.
> > 
> > Process to look at is encodeur.exe and the thread named 
> > TickJobThread which
> is woken up by a timer set a 1ms and priority 255.
> > 
> > At event 466750 you`ll see the thread go in READY state.  It goes in 
> > RUNNING
>  state 220us later.  Can`t see why it`s taking so long.
> > 
> > The same thing happends at 514137, but this time it takes 349us to 
> > go from
> READY to RUNNING.
> > 
> > There are no other thread running at this priority and the data 
> > doesn`t
> seems to indicate it`s related to interrupts. 
> > 
> > What am I missing?
> > 
> > 
> > 
> > _______________________________________________
> > 
> > OSMeta
> > http://community.qnx.com/sf/go/post61072
> 
> 
> 
> _______________________________________________
> 
> OSMeta
> http://community.qnx.com/sf/go/post61074
> 






_______________________________________________

OSMeta
http://community.qnx.com/sf/go/post61153

  Hans-Peter Reichert wrote:
> the kernel trace does not show any other obvious reason.
> we had a similar problem with 6.4.0, 6.4.1 related to Intel power mgmt.
> the workaround was to start procnto with "-h", disabling pwr mgmt

IMHO ... it's not a good idea to "disable" the power mgt.
The option -h forces the CPU into the active idle loop instead of going 
into the halt status.

--Armin