Mario Charest
07/29/2010 12:04 PM
post61072
|
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?
|
|
|
Neil Schellenberger(deleted)
|
|
Neil Schellenberger(deleted)
07/29/2010 12:09 PM
post61074
|
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
|
|
|
Mario Charest
07/29/2010 1:00 PM
post61079
|
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
|
|
|
Hans-Peter Reichert
|
Re: RE: Can`t explain delay
|
Hans-Peter Reichert
07/30/2010 2:23 AM
post61153
|
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
>
|
|
|
Mario Charest
|
RE: RE: Can`t explain delay
|
Mario Charest
08/02/2010 10:54 AM
post61344
|
RE: RE: Can`t explain delay
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
|
|
|
Hans-Peter Reichert
|
Re: RE: RE: Can`t explain delay
|
Hans-Peter Reichert
08/02/2010 12:18 PM
post61348
|
Re: RE: RE: Can`t explain delay
that's good and bad news.
good: the reason is a known one
bad: the PR says that it is fixed, at least in 6.4.1
so Q guys, can you check this!
/hp
>
> 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
|
|
|
Douglas Bailey
|
RE: RE: RE: Can`t explain delay
|
Douglas Bailey
08/02/2010 12:41 PM
post61352
|
RE: RE: RE: Can`t explain delay
PR72535 says the problem was fixed by PR74065, which patched a head branch fix back to the 6.4.1 branch. So it's been
fixed on the 6.4.1 branch, but the fix was not part of the original 6.4.1 release. If you are using 6.4.1 release you
will need to pick up a more recent patch.
-----Original Message-----
From: Hans-Peter Reichert [mailto:community-noreply@qnx.com]
Sent: Mon 02/08/2010 12:18
To: osmeta-core_os
Subject: Re: RE: RE: Can`t explain delay
that's good and bad news.
good: the reason is a known one
bad: the PR says that it is fixed, at least in 6.4.1
so Q guys, can you check this!
/hp
>
> 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
_______________________________________________
OSMeta
http://community.qnx.com/sf/go/post61348
|
|
|
Hans-Peter Reichert
|
Re: RE: RE: RE: Can`t explain delay
|
Hans-Peter Reichert
08/02/2010 1:13 PM
post61353
|
Re: RE: RE: RE: Can`t explain delay
Mario did it with a 6.5.0!
so the fix is not part of 6.5.0?
/hp
|
|
|
Mario Charest
|
RE: RE: RE: Can`t explain delay
|
Mario Charest
08/02/2010 2:00 PM
post61356
|
RE: RE: RE: Can`t explain delay
I'm using 6.5.0.
-----Message d'origine-----
De : Douglas Bailey [mailto:community-noreply@qnx.com]
Envoyé : 2 août 2010 12:41
À : osmeta-core_os
Objet : RE: RE: RE: Can`t explain delay
PR72535 says the problem was fixed by PR74065, which patched a head branch fix back to the 6.4.1 branch. So it's been
fixed on the 6.4.1 branch, but the fix was not part of the original 6.4.1 release. If you are using 6.4.1 release you
will need to pick up a more recent patch.
-----Original Message-----
From: Hans-Peter Reichert [mailto:community-noreply@qnx.com]
Sent: Mon 02/08/2010 12:18
To: osmeta-core_os
Subject: Re: RE: RE: Can`t explain delay
that's good and bad news.
good: the reason is a known one
bad: the PR says that it is fixed, at least in 6.4.1
so Q guys, can you check this!
/hp
>
> 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
_______________________________________________
OSMeta
http://community.qnx.com/sf/go/post61348
_______________________________________________
OSMeta
http://community.qnx.com/sf/go/post61352
|
|
|
Mario Charest
|
RE: RE: Can`t explain delay
|
Mario Charest
08/02/2010 11:03 AM
post61345
|
RE: RE: Can`t explain delay
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
|
|
|
Armin Steinhoff
08/02/2010 3:02 PM
post61360
|
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
|
|
|
Mario Charest
08/02/2010 3:21 PM
post61361
|
-----Message d'origine-----
De : Armin Steinhoff [mailto:community-noreply@qnx.com]
Envoyé : 2 août 2010 15:02
À : osmeta-core_os
Objet : Re: Can`t explain delay
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.
Indeed. It's getting warmer in here. I'm scared of putting that fix in our farm of 20 computers ;-)
>--Armin
_______________________________________________
OSMeta
http://community.qnx.com/sf/go/post61360
|
|
|
Hans-Peter Reichert
08/02/2010 3:22 PM
post61362
|
that's not the question.
-h is for Mario to validate the problem he observes.
And as -h gives the same results as with the similar problem in 6.4.1
it shows that a fix (see the mentioned PR) didn't make it from 6.4.1 to 6.5.0
or worse, there's another multi core sched problem.
/hp
|
|
|
Mario Charest
08/06/2010 11:53 AM
post62049
|
> that's not the question.
> -h is for Mario to validate the problem he observes.
> And as -h gives the same results as with the similar problem in 6.4.1
> it shows that a fix (see the mentioned PR) didn't make it from 6.4.1 to 6.5.0
> or worse, there's another multi core sched problem.
> /hp
Can some one confirm if the correction made it to 6.5.0 or not?
|
|
|
Armin Steinhoff
07/30/2010 2:53 AM
post61155
|
Hi,
what type of CPU you are using? The Intel Q6600 CPU e.g. does
management if its clock which introduce remarkeable delays ...
--Armin
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
|
|
|
|