TimerTimeout()

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

In my application, I’m having problems guaranteeing real-time behavior. I
have a periodic interrupt of a timer board at a frequency of 1KHz. I’m not
able to keep the response time < 1ms, even on GHz PCs. My process is the
only one that runs priority 63. The only system calls I’m making are:

MsgReceivePulse() (to receive the pulse triggered by the interrupt)
MsgSendPulse() (to “wake up” other processes)
TimerTimeout(CLOCK_REALTIME, _NTO_TIMEOUT_RECEIVE, 0, 0, 0); +
MsgReceivePulse();
(to check if there is already another pulse waiting, to detect if my
pulse handler is falling behind)

The same thing runs perfect in QNX4, replacing MsgReceivePulse() with
Receive(), MsgSendPulse() with Send(), and TimerTimeout()/MsgReceivePulse()
with CReceive().

Anything I’m doing wrong here? I have the feeling that maybe the call of
TimerTimeout is not good here.
Thanks in advance
Markus

2

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9d6fal$mbj$1@inn.qnx.com…

In my application, I’m having problems guaranteeing real-time behavior. I
have a periodic interrupt of a timer board at a frequency of 1KHz. I’m not
able to keep the response time < 1ms, even on GHz PCs. My process is the
only one that runs priority 63. The only system calls I’m making are:
[snip]
Anything I’m doing wrong here? I have the feeling that maybe the call of
TimerTimeout is not good here.
Thanks in advance
Markus

Hello, this is my finding I posted to this news group in January…
As far as I know this issue was not solved.

Pavol

Pavol Kycina
Microstep-HDO, s.r.o.
Bratislava, Slovakia

In order to be able to divide code between irq handler
and thread efficiently I was playing a bit with QNX RTP.

I tried to follow this rules:
thread “scheduled from handler” is high priority… 63
measure ellapsed time with ClockCycles
print data in other normal priority thread
use bare CPU board (no network, sound, SMM, …)
run program from boot-image (no filesystem, …)

My program does sth like this:

irq_handler () {
remember value of ClockCycles
return event to wake thread
}

thread() {
while(1){
InterruptWait()
remember value of ClockCycles
count min, max, average difference
}
}

main(){
while(1){
print counted values
}
}

And my findings are that sometimes it takes
almost !!! 1ms !!! from interrupt handler to thread.
(I measured it on 266MHz AMD K6)

The easiest way to make the difference large is to
start pidin on other console.

I am attaching my src code and also build file.














begin 600 qnx5.build
M6W-E87)C:#TN.B]S8FEN.B]U<W(O<V)I;CHO8FEN.B]U<W(O8FEN.B]L:6(Z
M+VQI8B]D;&PZ+V)O;W0O<WES70T6W9I<G1U86P]>#@V+&)I;W,@V-O;7!R
M97-S72!B;V]T(#T@>PT"7-T87)T=7M8FEO<RM<RV-&L@+78-"@E0051( M/2]P<F]C+V)O;W0Z+V)I;CHO=7-R+V)I;B!,1%],24)205)97U!!5$@]+W!R M;V,O8F]O=#HO;&EB.B]U<W(O;&EB.B]L:6(O9&QL('!R;V-N=&\-"GT-"@T* M6RMS8W)I<'1=("YS8W)I<'0@/2![#0H)9&5V8RUC;VX@+6XT("8-"B,)9&5V M8RUS97(X,C4P("U&("UE("8-"@ED979C+7-E<C@R-3@+64@)@T"0T*“7)E
M;W!E;BO9&5V+V-O;C$-"B@(”!;W-E<W-I;VY=(%!!5$@]+W!R;V,O8F]O
M="!E<V@@)@T"7)E;W!E;BO9&5V+V-O;C(-"B@("!;W-E<W-I;VY=(%!!
M5$@]+W!R;V,O8F]O="!E<V@@)@T"7)E;W!E;BO9&5V+W-E<C$-"B@("!;
MW-E<W-I;VY=(%!!5$@]+W!R;V,O8F]O="!E<V@@)@T?0T*#0I;=‘EP93UL
M:6YK72O9&5V+V-O;G-O;&4]+V1E=B]C;VXQ#0I;='EP93UL:6YK72O=7-R
M+VQI8B]L9’%N>"YS;RXQ/2]P<F]C+V)O;W0O;&EB8RYS;PT*#0IL:6)C+G-O
M(T*#0I;9&%T83UC;W!Y70T*9&5V8RUC;VX-"F1E=F,M<V5R.#(U,T97-H
M#0HC(’-P96-I9GD@97AE8W5T86)L97,@=&AA="!Y;W4@=V%N="!T;R!B92!A
M8FQE#0HC(‘1O(’)U;B!F<F]M('1H92!S:&5L;#H@(&5C:&\L(&QS+"!P:61I
M;BP@971C+BXN#0IE8VAO#0IL<PT<&ED:6X-"F-A=T*8W-"FER<5]T:6UE
E<@T*:7)Q7V1I9F8-"G1I;65R#0IS:'5T9&]W;@T*2-"@==
end

begin 600 irq_diff.c
M(VEN8VQU9&4@/’-T9&EO+F@^#0HC:6YC;‘5D92\<WES+VYE=71R:6YO+F@^ M#0HC:6YC;'5D92<WES+W-I9VEN9F\N:#X-“B-I;F-L=61E(#QI;G1T>7!E
M<RYH/@T*#0H-“G-T<G5C=”!S:6=E=F5N=”!E=F5N=#L-“FEN=EG;R](#$[
M#0H-“G-T871I8R!I;G0)“0D)“0D)9FQA9U]A=F<@/2P.PT*=6YS:6=N960@ M:6YT"0D)"6-?9&EF9E]M87@@/2P+”!C7V1I9F9?;6EN(#T@+3$L(&-?9&EF
M9E]A=F<@/2P.PT*=F]L871I;&4@=6EN=#8T7W0)"0EC7VYO=U]I:2](#[ M#0IS=&%T:6,@=6EN=#8T7W0)"0D)8U]N;W<@/2P+”!C7V]L9"](#L(&-?
M=&UP+”!S=6U?879G.PT*#0IC;VYS=”!S=’)U8W0@<VEG979E;G0J(&ES<E]H
M86YD;&5R*‘9O:60@F%R9RP@:6YT(&ED0T*>PT*“0T*“6-?;F]W7VEI(#T@
M0VQO8VM#>6-L97,H3L-"@D-"@ER971U<FXH)F5V96YT3L-“GT-”@T*=F]I
M9"H@:6YT7W1H<F5A9”@@=F]I9”J87)G*0T*>PT*"6EN="@("@("@("@ M("@("@("@("!R970[#0H)<W1R=6-T(’-C:&5D7W!A<F%M"7!A<F%M.PT*
M#0H)+R@:6YI8VEA;&EZ=6H@979E;G0-"@E324=%5E])3E127TE.250H(“9E
M=F5N=“D[#0H-”@DO+V5N86)L92!I+V@<’)I=FEL96=E#0H)<F5T(#T@5&AR
M96%D0W1L7W(H7TY43U]40U1,7TE/+”!.54Q,3L-"@EI9BAR970@/"P*7L- M"@D)<')I;G1F*").96UA;2!P<F%V82!N82!)3R!O<&5R86-I95QN(BD[#0H) M"6=O(#T@,#L-"@D)<F5T=7)N.PT*"7T-"@D-"@EP87)A;2YS8VAE9%]P<FEO M<FET>2](#8S.PT"7)E="](%-C:&5D4V5T7W(H,"P@,"P@4T-(141?3D]# M2$%.1T4L("9P87)A;2D[#0H):68H<F5T(#P@,"E[#0H)"7!R:6YT9B@B3F5P M;V1A<FEL;R!S82!Z;65N:70@<')I;W)I='5<;B(I.PT*"0EG;R](#[#0H) M"7)E='5R;CL-"@E]#0H-"@ER970@/2!);G1E<G)U<'1!='1A8V@H,"P@:7-R M7VAA;F1L97(L($Y53$PL(#L(#I.PT*"6EF*')E="(#I>PT*"0EP<FEN M=&8H(DYE;6]Z96T@<V$@<')I<&]J:70@;F$@<')E<G5S96YI95QN(BD[#0H) M"6=O(#T@,#L-"@D)<F5T=7)N.PT*"7T-"@T*"7=H:6QE*#$I>PT*"0E);G1E M<G)U<'1786ET*#L($Y53$PI.PT*“0D-”@D)8U]O;&0@/2!C7VYO=U]I:3L-
M"@D)8U]N;W<@/2!#;&]C:T-Y8VQE<R@I.PT"0EI9BAC7VYO=RF)B!C7V]L M9"E[#0H)"0EC7W1M<"](&-?;F]W("T@8U]O;&0[#0H)“0EI9BAC7W1M<”^ M(&-?9&EF9E]M87@I>PT*"0D)"69L86=?879G(#T@,#L-"@D)"0EC7V1I9F9? M;6%X(#T@8U]T;7[#0H)"0E](&5L<V4@:68H(&-?=&UP(#P@8U]D:69F7VUI
M;BE[#0H)"0D)8U]D:69F7VUI;B](&-?=&UP.PT*"0D)"69L86=?879G("]
M(#[#0H)"0E](&5L<V4@>PT*"0D)"6EF*&9L86=?879G(#T](#I>PT"0D)
M"0ES=6U?879G(#T@,#L-"@D)"0E]#0H)"0D)9FQA9U]A=F<KSL-"@D)"0ES
M=6U?879G("L](&-?=&UP.PT"0D)"6EF*&9L86=?879G(#T](#$P,#I>PT* M"0D)"0EC7V1I9F9?879G(#T@<W5M7V%V9RO(&9L86=?879G.PT*"0D)“0EF
M;&%G7V%V9R](#[#0H)“0D)?0T*“0D)?0T*“0E]#0H)?0T*?0T*#0H-“FUA
M:6XH0T>PT*“6EN=D)=&ED.PT*"7!T:')E861?8W)E871E*"F=&ED+”!.
M54Q,+”!I;G1?=&AR96%D+”!.54Q,*3L-”@EP<FEN=&8H(E1H<F5A9”!M82!I
M9”E9%QN(BP@=&ED*3L-"@T*"7=H:6QE*&=O*7L-"@D)<')I;G1F*")D:69F M(&IE(&UI;BXN+B5D(&%V9RXN+B5D(&UA>"XN+B5D(%QN(BP@8U]D:69F7VUI M;BP@8U]D:69F7V%V9RP@8U]D:69F7VUA>"D[#0H)"7-L965P*#(I.PT*"7T- M"@T*"7!R:6YT9B@B4')E<G5S96YI92!S:V]N8VEL;RP@87-I(&YE:F%K82!C 2:'EB85QN(BD[#0I]#0H-"@T*
end

3

Hi Pavol,
thanks a lot for this info and the code - this really seems like the cause
for my problems.
Did QSSL comfirm this to be a known bug?
I extended your program to log data and plot it with Matlab. You can see the
result at http://markus.ces.clemson.edu/delay.gif. I did some “pidins” and
at the end, a “chkfsys /”
My machine is 1.2 GHz, and I’m still having some 500usec delays.
Markus



“Pavol Kycina” <kycina@microstep-hdo.sk> wrote in message
news:64502DBEFA7ED311B4A0006008610AB648F458@mail.mshdo…

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9d6fal$mbj$> 1@inn.qnx.com> …
In my application, I’m having problems guaranteeing real-time behavior.
I
have a periodic interrupt of a timer board at a frequency of 1KHz. I’m
not
able to keep the response time < 1ms, even on GHz PCs. My process is the
only one that runs priority 63. The only system calls I’m making are:
[snip]
Anything I’m doing wrong here? I have the feeling that maybe the call of
TimerTimeout is not good here.
Thanks in advance
Markus


Hello, this is my finding I posted to this news group in January…
As far as I know this issue was not solved.

Pavol

Pavol Kycina
Microstep-HDO, s.r.o.
Bratislava, Slovakia

In order to be able to divide code between irq handler
and thread efficiently I was playing a bit with QNX RTP.

I tried to follow this rules:
thread “scheduled from handler” is high priority… 63
measure ellapsed time with ClockCycles
print data in other normal priority thread
use bare CPU board (no network, sound, SMM, …)
run program from boot-image (no filesystem, …)

My program does sth like this:

irq_handler () {
remember value of ClockCycles
return event to wake thread
}

thread() {
while(1){
InterruptWait()
remember value of ClockCycles
count min, max, average difference
}
}

main(){
while(1){
print counted values
}
}

And my findings are that sometimes it takes
almost !!! 1ms !!! from interrupt handler to thread.
(I measured it on 266MHz AMD K6)

The easiest way to make the difference large is to
start pidin on other console.

I am attaching my src code and also build file.











\

4

i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst case
of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds

the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you see is
directly related to smm mode on an x86. if you run the same tests on an arm
or ppc or sh4 you see much more consistent numbers. i can post some if you’d
like…

we are definitely definitely definitely interested in this feedback from
you and hard realtime is absolutely absolutely absolutely a priority for
us.

in fact we are doing even more work on handling priority inversion…
propogating priority up the chain of blocked events. and much more to
come!

(okay, so i’m in technical sales so i get biased a bit, but you know, you
grow to love this stuff pretty quick :slight_smile:

Pavol Kycina <kycina@microstep-hdo.sk> wrote:

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9d6fal$mbj$> 1@inn.qnx.com> …
In my application, I’m having problems guaranteeing real-time behavior. I
have a periodic interrupt of a timer board at a frequency of 1KHz. I’m not
able to keep the response time < 1ms, even on GHz PCs. My process is the
only one that runs priority 63. The only system calls I’m making are:
[snip]
Anything I’m doing wrong here? I have the feeling that maybe the call of
TimerTimeout is not good here.
Thanks in advance
Markus


Hello, this is my finding I posted to this news group in January…
As far as I know this issue was not solved.

Pavol

Pavol Kycina
Microstep-HDO, s.r.o.
Bratislava, Slovakia

In order to be able to divide code between irq handler
and thread efficiently I was playing a bit with QNX RTP.

I tried to follow this rules:
thread “scheduled from handler” is high priority… 63
measure ellapsed time with ClockCycles
print data in other normal priority thread
use bare CPU board (no network, sound, SMM, …)
run program from boot-image (no filesystem, …)

My program does sth like this:

irq_handler () {
remember value of ClockCycles
return event to wake thread
}

thread() {
while(1){
InterruptWait()
remember value of ClockCycles
count min, max, average difference
}
}

main(){
while(1){
print counted values
}
}

And my findings are that sometimes it takes
almost !!! 1ms !!! from interrupt handler to thread.
(I measured it on 266MHz AMD K6)

The easiest way to make the difference large is to
start pidin on other console.

I am attaching my src code and also build file.












begin 600 qnx5.build
M6W-E87)C:#TN.B]S8FEN.B]U<W(O<V)I;CHO8FEN.B]U<W(O8FEN.B]L:6(Z
M+VQI8B]D;&PZ+V)O;W0O<WES70T6W9I<G1U86P]>#@V+&)I;W,@V-O;7!R
M97-S72!B;V]T(#T@>PT"7-T87)T=7M8FEO<RM<RV-&L@+78-"@E0051( M/2]P<F]C+V)O;W0Z+V)I;CHO=7-R+V)I;B!,1%],24)205)97U!!5$@]+W!R M;V,O8F]O=#HO;&EB.B]U<W(O;&EB.B]L:6(O9&QL('!R;V-N=&\-"GT-"@T* M6RMS8W)I<'1=("YS8W)I<'0@/2![#0H)9&5V8RUC;VX@+6XT("8-"B,)9&5V M8RUS97(X,C4P("U&("UE("8-"@ED979C+7-E<C@R-3@+64@)@T"0T*“7)E
M;W!E;BO9&5V+V-O;C$-"B@(”!;W-E<W-I;VY=(%!!5$@]+W!R;V,O8F]O
M="!E<V@@)@T"7)E;W!E;BO9&5V+V-O;C(-"B@("!;W-E<W-I;VY=(%!!
M5$@]+W!R;V,O8F]O="!E<V@@)@T"7)E;W!E;BO9&5V+W-E<C$-"B@("!;
MW-E<W-I;VY=(%!!5$@]+W!R;V,O8F]O="!E<V@@)@T?0T*#0I;=‘EP93UL
M:6YK72O9&5V+V-O;G-O;&4]+V1E=B]C;VXQ#0I;='EP93UL:6YK72O=7-R
M+VQI8B]L9’%N>"YS;RXQ/2]P<F]C+V)O;W0O;&EB8RYS;PT*#0IL:6)C+G-O
M(T*#0I;9&%T83UC;W!Y70T*9&5V8RUC;VX-"F1E=F,M<V5R.#(U,T97-H
M#0HC(’-P96-I9GD@97AE8W5T86)L97,@=&AA="!Y;W4@=V%N="!T;R!B92!A
M8FQE#0HC(‘1O(’)U;B!F<F]M('1H92!S:&5L;#H@(&5C:&\L(&QS+"!P:61I
M;BP@971C+BXN#0IE8VAO#0IL<PT<&ED:6X-"F-A=T*8W-"FER<5]T:6UE
E<@T*:7)Q7V1I9F8-"G1I;65R#0IS:'5T9&]W;@T*2-"@==
end

begin 600 irq_diff.c
M(VEN8VQU9&4@/’-T9&EO+F@^#0HC:6YC;‘5D92\<WES+VYE=71R:6YO+F@^ M#0HC:6YC;'5D92<WES+W-I9VEN9F\N:#X-“B-I;F-L=61E(#QI;G1T>7!E
M<RYH/@T*#0H-“G-T<G5C=”!S:6=E=F5N=”!E=F5N=#L-“FEN=EG;R](#$[
M#0H-“G-T871I8R!I;G0)“0D)“0D)9FQA9U]A=F<@/2P.PT*=6YS:6=N960@ M:6YT"0D)"6-?9&EF9E]M87@@/2P+”!C7V1I9F9?;6EN(#T@+3$L(&-?9&EF
M9E]A=F<@/2P.PT*=F]L871I;&4@=6EN=#8T7W0)"0EC7VYO=U]I:2](#[ M#0IS=&%T:6,@=6EN=#8T7W0)"0D)8U]N;W<@/2P+”!C7V]L9"](#L(&-?
M=&UP+”!S=6U?879G.PT*#0IC;VYS=”!S=’)U8W0@<VEG979E;G0J(&ES<E]H
M86YD;&5R*‘9O:60@F%R9RP@:6YT(&ED0T*>PT*“0T*“6-?;F]W7VEI(#T@
M0VQO8VM#>6-L97,H3L-"@D-"@ER971U<FXH)F5V96YT3L-“GT-”@T*=F]I
M9"H@:6YT7W1H<F5A9”@@=F]I9”J87)G*0T*>PT*"6EN="@("@("@("@ M("@("@("@("!R970[#0H)<W1R=6-T(’-C:&5D7W!A<F%M"7!A<F%M.PT*
M#0H)+R@:6YI8VEA;&EZ=6H@979E;G0-"@E324=%5E])3E127TE.250H(“9E
M=F5N=“D[#0H-”@DO+V5N86)L92!I+V@<’)I=FEL96=E#0H)<F5T(#T@5&AR
M96%D0W1L7W(H7TY43U]40U1,7TE/+”!.54Q,3L-"@EI9BAR970@/"P*7L- M"@D)<')I;G1F*").96UA;2!P<F%V82!N82!)3R!O<&5R86-I95QN(BD[#0H) M"6=O(#T@,#L-"@D)<F5T=7)N.PT*"7T-"@D-"@EP87)A;2YS8VAE9%]P<FEO M<FET>2](#8S.PT"7)E="](%-C:&5D4V5T7W(H,"P@,"P@4T-(141?3D]# M2$%.1T4L("9P87)A;2D[#0H):68H<F5T(#P@,"E[#0H)"7!R:6YT9B@B3F5P M;V1A<FEL;R!S82!Z;65N:70@<')I;W)I='5<;B(I.PT*"0EG;R](#[#0H) M"7)E='5R;CL-"@E]#0H-"@ER970@/2!);G1E<G)U<'1!='1A8V@H,"P@:7-R M7VAA;F1L97(L($Y53$PL(#L(#I.PT*"6EF*')E="(#I>PT*"0EP<FEN M=&8H(DYE;6]Z96T@<V$@<')I<&]J:70@;F$@<')E<G5S96YI95QN(BD[#0H) M"6=O(#T@,#L-"@D)<F5T=7)N.PT*"7T-"@T*"7=H:6QE*#$I>PT*"0E);G1E M<G)U<'1786ET*#L($Y53$PI.PT*“0D-”@D)8U]O;&0@/2!C7VYO=U]I:3L-
M"@D)8U]N;W<@/2!#;&]C:T-Y8VQE<> R@I.PT> "0EI9BAC7VYO=RF)B!C7V]L M9"E[#0H)"0EC7W1M<"](&-?;F]W("T@8U]O;&0[#0H)“0EI9BAC7W1M<”^ M(&-?9&EF9E]M87@I>PT*"0D)"69L86=?879G(#T@,#L-"@D)"0EC7V1I9F9? M;6%X(#T@8U]T;7[#0H)"0E](&5L<V4@:68H(&-?=&UP(#P@8U]D:69F7VUI
M;BE[#0H)"0D)8U]D:69F7VUI;B](&-?=&UP.PT*"0D)"69L86=?879G("]
M(#[#0H)"0E](&5L<V4@>PT*"0D)"6EF*&9L86=?879G(#T](#I>PT"0D)
M"0ES=6U?879G(#T@,#L-"@D)"0E]#0H)"0D)9FQA9U]A=F<KSL-"@D)"0ES
M=6U?879G("L](&-?=&UP.PT"0D)"6EF*&9L86=?879G(#T](#$P,#I>PT* M"0D)"0EC7V1I9F9?879G(#T@<W5M7V%V9RO(&9L86=?879G.PT*"0D)“0EF
M;&%G7V%V9R](#[#0H)“0D)?0T*“0D)?0T*“0E]#0H)?0T*?0T*#0H-“FUA
M:6XH0T>PT*“6EN=D)=&ED.PT*"7!T:')E861?8W)E871E*"F=&ED+”!.
M54Q,+”!I;G1?=&AR96%D+”!.54Q,*3L-”@EP<FEN=&8H(E1H<F5A9”!M82!I
M9”E9%QN(BP@=&ED*3L-"@T*"7=H:6QE*&=O*7L-"@D)<')I;G1F*")D:69F M(&IE(&UI;BXN+B5D(&%V9RXN+B5D(&UA>"XN+B5D(%QN(BP@8U]D:69F7VUI M;BP@8U]D:69F7V%V9RP@8U]D:69F7VUA>"D[#0H)"7-L965P*#(I.PT*"7T- M"@T*"7!R:6YT9B@B4')E<G5S96YI92!S:V]N8VEL;RP@87-I(&YE:F%K82!C 2:'EB85QN(BD[#0I]#0H-"@T*
end

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

5

“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9d921e$bk0$1@inn.qnx.com…

Hi Pavol,
thanks a lot for this info and the code - this really seems like the cause
for my problems.
Did QSSL comfirm this to be a known bug?

Their inhouse measuremets showed some latencies.
(They say it’s related to SMM of x86 processors,
but that isn’t the area I have knowledge about.)

I extended your program to log data and plot it with Matlab. You can see
the
result at > http://markus.ces.clemson.edu/delay.gif> . I did some “pidins” and
at the end, a “chkfsys /”

I couldn’t connect to given web page, I will try later.

Pavol Kycina

6

“Randy Martin” <randy@qnx.com> wrote in message
news:9d9pvn$e3s$1@nntp.qnx.com…

i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you see
is
directly related to smm mode on an x86. if you run the same tests on an
arm
or ppc or sh4 you see much more consistent numbers. i can post some if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: Should we stick to old 486s, which don’t have SMM? :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol

7

my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable this and
let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk with
those vendors.

Pavol Kycina <kycina@microstep-hdo.sk> wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you see
is
directly related to smm mode on an x86. if you run the same tests on an
arm
or ppc or sh4 you see much more consistent numbers. i can post some if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?



Pavol

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

8

SMM or not, fact is I’m running the same code (with the appropriate
replacements) on QNX4 without problem. I think I’m not asking too much when
I’m asking for QNX6 perform as well as QNX6?
Markus

“Randy Martin” <randy@qnx.com> wrote in message
news:9dblev$ik8$2@nntp.qnx.com…

my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable this
and
let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk with
those vendors.

Pavol Kycina <> kycina@microstep-hdo.sk> > wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes
there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you
see
is
directly related to smm mode on an x86. if you run the same tests on an
arm
or ppc or sh4 you see much more consistent numbers. i can post some if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol



\

Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

9

Btw, what is SMM anyway? In a web search I got only “Shareware Music
Machine”, “Society for Marine Mamalogy” and the “Science Museum of
Minnesota”.
Markus


“Markus Loffler” <loffler@ces.clemson.edu> wrote in message
news:9dbnge$1qk$1@inn.qnx.com…

SMM or not, fact is I’m running the same code (with the appropriate
replacements) on QNX4 without problem. I think I’m not asking too much
when
I’m asking for QNX6 perform as well as QNX6?
Markus

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9dblev$ik8$> 2@nntp.qnx.com> …
my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable
this
and
let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk with
those vendors.

Pavol Kycina <> kycina@microstep-hdo.sk> > wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes
there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst
case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you
see
is
directly related to smm mode on an x86. if you run the same tests on
an
arm
or ppc or sh4 you see much more consistent numbers. i can post some
if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol



\

Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

10

In article <9dbnmm$22h$1@inn.qnx.com>, loffler@ces.clemson.edu says…

Btw, what is SMM anyway? In a web search I got only “Shareware Music
Machine”, “Society for Marine Mamalogy” and the “Science Museum of
Minnesota”.
Markus

System Management Mode - something implemented in the Pentiums, and
roughly co-equal with Virtual 8086 (i.e. real) mode.
The docs talk about the Pentium being able to be in one of 3 modes:

  1. Virtual 8086
  2. System Management
  3. Protected Mode (where QNX runs once started properly)

So, shifting to SMM mode is roughly the same as shifting to Real mode.
And because of “protection” issues, it appears that if the BIOS wants to
handle it, it can even lock out the OS from handling it!

“Markus Loffler” <> loffler@ces.clemson.edu> > wrote in message
news:9dbnge$1qk$> 1@inn.qnx.com> …
SMM or not, fact is I’m running the same code (with the appropriate
replacements) on QNX4 without problem. I think I’m not asking too much
when
I’m asking for QNX6 perform as well as QNX6?
Markus

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9dblev$ik8$> 2@nntp.qnx.com> …
my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable
this
and
let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk with
those vendors.

Pavol Kycina <> kycina@microstep-hdo.sk> > wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes
there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst
case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what you
see
is
directly related to smm mode on an x86. if you run the same tests on
an
arm
or ppc or sh4 you see much more consistent numbers. i can post some
if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol



\

Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579



\

–
Stephen Munnings
Software Developer
Corman Technologies Inc.

11

An excerpt from the Intel Docs:

SYSTEM MANAGEMENT MODE (SMM)
This chapter describes the Intel Architecture’s System Management Mode
(SMM) architecture.
SMM was introduced into the Intel Architecture in the Intel386™ SL
processor (a mobile specialized version of the Intel386™ processor). It
is also available in the Intel486™ processors
(beginning with the Intel486™ SL and Intel486™ enhanced versions) and in
the Intel Pentium ®
and P6 family processors. For a detailed description of the hardware that
supports SMM, refer
to the developer’s manuals for each of the Intel Architecture processors.
12.1. SYSTEM MANAGEMENT MODE OVERVIEW
SMM is a special-purpose operating mode provided for handling system-wide
functions like
power management, system hardware control, or proprietary OEM-designed
code. It is intended
for use only by system firmware, not by applications software or general-
purpose systems software.
The main benefit of SMM is that it offers a distinct and easily isolated
processor environ-ment
that operates transparently to the operating system or executive and
software applications.
When SMM is invoked through a system management interrupt (SMI), the
processor saves the
current state of the processor (the processor’s context), then switches
to a separate operating
environment contained in system management RAM (SMRAM). While in SMM, the
processor
executes SMI handler code to perform operations such as powering down
unused disk drives or
monitors, executing proprietary code, or placing the whole system in a
suspended state. When
the SMI handler has completed its operations, it executes a resume (RSM)
instruction. This
instruction causes the processor to reload the saved context of the
processor, switch back to
protected or real mode, and resume executing the interrupted application
or operating-system
program or task.
The following SMM mechanisms make it transparent to applications programs
and operating
systems:
• The only way to enter SMM is by means of an SMI.
• The processor executes SMM code in a separate address space (SMRAM)
that can be
made inaccessible from the other operating modes.
• Upon entering SMM, the processor saves the context of the interrupted
program or task.
• All interrupts normally handled by the operating system are disabled
upon entry into
SMM.
• The RSM instruction can be executed only in SMM.
SMM is similar to real-address mode in that there are no privilege levels
or address mapping.
An SMM program can address up to 4 GBytes of memory and can execute all
I/O and applicable
system instructions.

12

I don’t think that Randy stated that your problem was SMM. He did state
the Pavol’s problem was SMM; since your problem is not SMM then “your
problem” != “Pavols’ problem”. It seems that your thread has been
hijacked by Pavol/SMM :wink:

-----Original Message-----
From: Markus Loffler [mailto:loffler@ces.clemson.edu]
Posted At: Wednesday, May 09, 2001 8:26 AM
Posted To: os
Conversation: TimerTimeout()
Subject: Re: TimerTimeout()


SMM or not, fact is I’m running the same code (with the appropriate
replacements) on QNX4 without problem. I think I’m not asking too much
when
I’m asking for QNX6 perform as well as QNX6?
Markus

“Randy Martin” <randy@qnx.com> wrote in message
news:9dblev$ik8$2@nntp.qnx.com…

my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable
this

and

let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk
with
those vendors.

Pavol Kycina <> kycina@microstep-hdo.sk> > wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes
there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst
case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what
you

see

is
directly related to smm mode on an x86. if you run the same tests
on an
arm
or ppc or sh4 you see much more consistent numbers. i can post some
if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable
it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol



\

Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579

13

“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C90441EC@exchangecal.hq.csical.com…

I don’t think that Randy stated that your problem was SMM. He did state
the Pavol’s problem was SMM; since your problem is not SMM then “your
problem” != “Pavols’ problem”. It seems that your thread has been
hijacked by Pavol/SMM > :wink:

I wouldn’t call it hijacking, just wanted to share my experience with 1KHz
processing.

Pavol

14

Sorry Pavol, I didn’t mean to imply that anyone in particular did the
hijacking (although I can clearly see that I did imply that re-reading
my post). Your post was perfectly appropriate, I just felt the need to
clarify that there are two different things going on in this thread.

-----Original Message-----
From: Pavol Kycina [mailto:kycina@microstep-hdo.sk]
Posted At: Thursday, May 10, 2001 12:35 AM
Posted To: os
Conversation: TimerTimeout()
Subject: Re: TimerTimeout()


“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C90441EC@exchangecal.hq.csical.com…

I don’t think that Randy stated that your problem was SMM. He did
state
the Pavol’s problem was SMM; since your problem is not SMM then “your
problem” != “Pavols’ problem”. It seems that your thread has been
hijacked by Pavol/SMM > :wink:

I wouldn’t call it hijacking, just wanted to share my experience with
1KHz
processing.

Pavol

15

It looks like 98% that his problem is mine. Or the other way around, as long
as Pavols program does not show better latencies, my stuff can’t work.
Markus

“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C90441EC@exchangecal.hq.csical.com…

I don’t think that Randy stated that your problem was SMM. He did state
the Pavol’s problem was SMM; since your problem is not SMM then “your
problem” != “Pavols’ problem”. It seems that your thread has been
hijacked by Pavol/SMM > :wink:

-----Original Message-----
From: Markus Loffler [mailto:> loffler@ces.clemson.edu> ]
Posted At: Wednesday, May 09, 2001 8:26 AM
Posted To: os
Conversation: TimerTimeout()
Subject: Re: TimerTimeout()


SMM or not, fact is I’m running the same code (with the appropriate
replacements) on QNX4 without problem. I think I’m not asking too much
when
I’m asking for QNX6 perform as well as QNX6?
Markus

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9dblev$ik8$> 2@nntp.qnx.com> …
my laptop suffers from SMM … i have no way of disabling it.
many of the hardened PC vendors have custom boards where they disable
this
and
let you finely control pci latencies/timings and other things.
if i were to do any hard realtime work on an x86 i would first talk
with
those vendors.

Pavol Kycina <> kycina@microstep-hdo.sk> > wrote:

“Randy Martin” <> randy@qnx.com> > wrote in message
news:9d9pvn$e3s$> 1@nntp.qnx.com> …
i’m not part of kernel team but i will post some thoughts…

yes, we have run your code and much more thorough analysis. and yes
there
are some latencies that we are fixing.
if i run your code on a p350 which is my tes laptop, i see a worst
case

Is your laptop “SMM free”? Or did you disable it?

of 53000 ticks between handler->thread
at 2.8 nanosecs per tick this is ~130 microseconds
the average is ~1500 ticks, or ~4.2 microseconds.

there are some latency things we are working on, but some of what
you
see
is
directly related to smm mode on an x86. if you run the same tests
on an
arm
or ppc or sh4 you see much more consistent numbers. i can post some
if
you’d
like…

Ok, I have heard about SMM on x86, but is there any way do disable
it?
(other than soldering on motherboard)
Or are there any boards which don’t use it?
:wink: > Should we stick to old 486s, which don’t have SMM? > :wink:
Shouldn’t we use x86s for “hard-realtime”, just other platforms?


Pavol



\

Randy Martin > randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems > www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579