“Chris McKillop” <cdm@qnx.com> wrote in message
news:a30j7f$dea$2@nntp.qnx.com…
Biting the hand that feeds you !! Wow !!
I didn’t think I was doing that all.
Me neither,
Igor Kovalenko <kovalenko@home.com> wrote:
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:a30ilv$dea$> 1@nntp.qnx.com> …I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver that
doesn’t run reliably on an SMP system should QNX take the blame? To the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probablyI was quite specific Chris. It can be taken as far as QSSL products go.
Everything shipped as a standard OS component is clearly your
responsibility. The phrelay surely is.
Yes, I know. And I am not trying to say that it shouldn’t be our problem,
it most certainly is.
chris
\
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
“Mario Charest” <goto@nothingness.com> wrote in message
news:a2s978$1jh$1@inn.qnx.com…
SMP has been flaky, and I wouldn’t be surprise if it gets dropped.
Hi Mario,
I haven’t used SMP yet, but this seams like a really big statement to be
just slipped between the line of another post.
What kind of flaky?
QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of dropping
SMP? IF there were any truth to this peope have the right to know sooner
rather than later.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Chris McKillop” <cdm@qnx.com> wrote in message
news:a30ilv$dea$1@nntp.qnx.com…
I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver that
doesn’t run reliably on an SMP system should QNX take the blame? To the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface. It’s a bug and I am sure you have reported it (right?).If the problems are the apps and not the OS, that can only imply that the
apps aren’t properly protecting data with semiphores. Is that the nature of
the apps’ probelms that have been found and fixed so far? If not, then it
seams like the apps are misbehaving because of flaky SMP features.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:a33s87$b7i$1@inn.qnx.com…
“Mario Charest” <> goto@nothingness.com> > wrote in message
news:a2s978$1jh$> 1@inn.qnx.com> …SMP has been flaky, and I wouldn’t be surprise if it gets dropped.
Hi Mario,
I haven’t used SMP yet, but this seams like a really big statement to be
just slipped between the line of another post.
Yeah, I probably have overstate it. It’s definely not bad at all. It’s
flaky but
with very small flakes 
What kind of flaky?
With 6.1 it would crash very often, but as Chris said a patch was issue to
fix that.
Then there was phrelay, then qnet in 6.2 beta, but I that’s what beta are
for
QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of
dropping
SMP? IF there were any truth to this peope have the right to know sooner
rather than later.
I don’t think QSSL has any desire to drop it. I just said I wouldn’t be
surprise
that’s very different. I made that statement based on the fact that since a
few
component of the OS didn’t work well on SMP that tells me (SMP or
the specified component) have low priority at QSSL. If it has low priority
it could mean they may get dropped for higher priority or for more
lucrative
options/feature set (remember what happens to Xwindows under QNX4)
Of course now that QSSL is targeting Telecom, SMP seems like a prerequisite.
Do I sound like i’m trying to minimize my statement. You bet I do…
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
\
QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of
dropping
SMP? IF there were any truth to this peope have the right to know sooner
rather than later.
No plans to drop SMP. It’s now a major differentiator for us in the high
end of the telecommunications space. We have lots of work going on there.
Alec.
Never mind. I posted this before I read the rest of this thread.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:a33s87$b7i$1@inn.qnx.com…
“Mario Charest” <> goto@nothingness.com> > wrote in message
news:a2s978$1jh$> 1@inn.qnx.com> …SMP has been flaky, and I wouldn’t be surprise if it gets dropped.
Hi Mario,
I haven’t used SMP yet, but this seams like a really big statement to be
just slipped between the line of another post.What kind of flaky?
QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of
dropping
SMP? IF there were any truth to this peope have the right to know sooner
rather than later.–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
\
Previously, Bill Caroselli wrote in qdn.public.qnxrtp.advocacy:
SMP has been flaky, and I wouldn’t be surprise if it gets dropped.
QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of dropping
SMP?
While I can’t speak for QSSL, I can say with high confidence that SMP
isn’t going to go away. One of the big new markets that QNX is playing
in is Telecom, and in that market embedded does not mean small. In many
cases it means SMP, and not just dual CPU SMP, but more often quad CPU
and 8 CPU SMP systems. Those high-end routers and intelligent internet
devices eat SMP for breakfast.
…and that in nushell makes SMP table stakes. It’s not going anywhere.
Cheers,
Camz.
ps. SMP is also quite effective at finding all the threading issues/bugs in
your code SO much faster than on a single CPU machine.
–
Martin Zimmerman camz@passageway.com
Camz Software Enterprises www.passageway.com/camz/qnx/
QNX Programming & Consulting
Very well said.
–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
“Marc Rudolph” <mrudolph@nonospam.com> wrote in message
news:a2sdoo$4k2$1@inn.qnx.com…
Well, this could degenerate into a flame war, considering nto 1.0, nto
2.0,
rtp 6.0 etc. But that’s not the point. Your statement is true, but not
very
helpful. I’m not a customer of M$ (at least not for embedded stuff). The
fact that their embedded offerings suck has no bearing on my reality. My
reality is that QSSL has been the vendor of choice, and I’m getting the
impression that QSSL isn’t interested in my needs, and would actually
prefer
me to go away.I don’t want to go away, because QNX 6 is very nice, it has lots of
features
we like and need, it’s reliable, it works well, the support is reasonably
good etc. But I’m not emotional about it - there are things wrong too -
performance is not great, development tools are even worse, and most of
all,
there is no information from QSSL that is ever going to get better, that
they have a plan, that they even care. Ok, so maybe I am emotional - too
many late nights recently >The bottom line is, as much as we like QNX, and want to use it, we need
some
business direction for the future. There comes a time when management
wants
to see a business case for using some technology, not just a technical
case.
If us techies have no info to provide a case, we will end up with a new
technology. That’s the unemotional bottom line.Marc
speaking only for myself, of course.
To say, “the apps are flakey, not the SMP” is a little disengineous since
most of the apps are not multi-threaded. If I’ve written an app that runs
multiple threads and it fails on an SMP system, then most likely I’m failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
“any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system.” I would invite you to
provide counter-examples if I’m wrong.
cheers,
Kris
“Bill Caroselli” <qtps@earthlink.net> wrote in message
news:a33sqe$btq$1@inn.qnx.com…
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:a30ilv$dea$> 1@nntp.qnx.com> …
I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver
that
doesn’t run reliably on an SMP system should QNX take the blame? To
the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface. It’s a bug and I am sure you have reported it (right?).If the problems are the apps and not the OS, that can only imply that the
apps aren’t properly protecting data with semiphores. Is that the nature
of
the apps’ probelms that have been found and fixed so far? If not, then it
seams like the apps are misbehaving because of flaky SMP features.–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
\
Kris Warkentin <kewarken@qnx.com> wrote:
To say, “the apps are flakey, not the SMP” is a little disengineous since
most of the apps are not multi-threaded. If I’ve written an app that runs
multiple threads and it fails on an SMP system, then most likely I’m failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
“any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system.” I would invite you to
provide counter-examples if I’m wrong.
A single-threaded app that has an ISR will work fine on a single CPU box
but may fail dramatically on an SMP box. 
Cheers,
-RK
cheers,
Kris
“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:a33sqe$btq$> 1@inn.qnx.com> …
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:a30ilv$dea$> 1@nntp.qnx.com> …
I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how far
do you take such a notion? If someone external to QNX does a driver
that
doesn’t run reliably on an SMP system should QNX take the blame? To
the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps and
services in general. The fact is that your phrelay issue would probably
happen on an non-SMP kernel as well, just harder to get the problem to
surface. It’s a bug and I am sure you have reported it (right?).If the problems are the apps and not the OS, that can only imply that the
apps aren’t properly protecting data with semiphores. Is that the nature
of
the apps’ probelms that have been found and fixed so far? If not, then it
seams like the apps are misbehaving because of flaky SMP features.–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
\
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Kris Warkentin <kewarken@qnx.com> wrote:
To say, “the apps are flakey, not the SMP” is a little disengineous since
most of the apps are not multi-threaded. If I’ve written an app that runs
multiple threads and it fails on an SMP system, then most likely I’m failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
“any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system.” I would invite you to
provide counter-examples if I’m wrong.
Although I am sure there are some cases (like rk pointed out), generally
this sort of statement is true. However, we do have many things that are
multi-threaded and this has tended to be where the problems existed. For
instance, phrelay is threaded, qnet is threaded and you can get some odd
effects when there is a client-server model as well (voyager).
chris
\
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Alright. I wasn’t including ISR’s in the list of ordinary, run of the mill,
application tasks but I suppose one needs to consider these sort of things
on QNX when all your drivers are running as ordinary (if privileged) apps.
Anyone else care to educate me further? I’ve often found that a strong
(even if erroneous) statement gets plenty of informative response.
Cheers,
Kris
“Robert Krten” <nospam91@parse.com> wrote in message
news:a343nf$gta$1@inn.qnx.com…
Kris Warkentin <> kewarken@qnx.com> > wrote:
To say, “the apps are flakey, not the SMP” is a little disengineous
since
most of the apps are not multi-threaded. If I’ve written an app that
runs
multiple threads and it fails on an SMP system, then most likely I’m
failing
to protect things properly. If a normal, run of the mill, single
threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
“any single threaded app which works on a single CPU system should
ALWAYS
work on a correctly implemented multi CPU system.” I would invite you
to
provide counter-examples if I’m wrong.A single-threaded app that has an ISR will work fine on a single CPU box
but may fail dramatically on an SMP box. >Cheers,
-RKcheers,
Kris
“Bill Caroselli” <> qtps@earthlink.net> > wrote in message
news:a33sqe$btq$> 1@inn.qnx.com> …
“Chris McKillop” <> cdm@qnx.com> > wrote in message
news:a30ilv$dea$> 1@nntp.qnx.com> …
I understand both your and Igor’s perspective that “a user” doesn’t
care if it is QNX’s SMP or an app that sucks on SMP. However, how
far
do you take such a notion? If someone external to QNX does a driver
that
doesn’t run reliably on an SMP system should QNX take the blame? To
the
user it would seem that the SMP kernel causes the problems with the
driver,
not the other way around. Same can be said about multithreaded apps
and
services in general. The fact is that your phrelay issue would
probably
happen on an non-SMP kernel as well, just harder to get the problem
to
surface. It’s a bug and I am sure you have reported it (right?).If the problems are the apps and not the OS, that can only imply that
the
apps aren’t properly protecting data with semiphores. Is that the
nature
of
the apps’ probelms that have been found and fixed so far? If not, then
it
seams like the apps are misbehaving because of flaky SMP features.–
Bill Caroselli – 1(626) 824-7983
Q-TPS Consulting
QTPS@EarthLink.net
\Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.
Mario Charest wrote:
Do I sound like i’m trying to minimize my statement. You bet I do…
Glad to hear this, since this whole SMP thread started when I made (what
I thought was a very non-controversial statement) that one could count
on SMP support for the next 10 years or so (after that it will probably
be quantum computer support that everyone will be clamoring for
“Chris McKillop” <cdm@qnx.com> wrote in message
news:a30j7f$dea$2@nntp.qnx.com…
[snip]
And, just for the record, I was a QNX customer/user/developer for nearly
5 years before I came to work for QNX. From autonomous robotic vehicles
to
embedded sensor systems for mining research to high-speed vision systems
for industrial control and manufacturing (hi wayne!).chris
D’Oh! You caught me lurching, Chris.
Wayne
Camz,
nice to hear these statements from you …
and just remembering the legendary SMP thread!
Igor and Armin will read twice…
Cheers, Jutta
Martin Zimmerman wrote:
Previously, Bill Caroselli wrote in qdn.public.qnxrtp.advocacy:
SMP has been flaky, and I wouldn’t be surprise if it gets dropped.QSSL, can you confirm or (hopfully) deny any thoughts whatsoever of dropping
SMP?While I can’t speak for QSSL, I can say with high confidence that SMP
isn’t going to go away. One of the big new markets that QNX is playing
in is Telecom, and in that market embedded does not mean small. In many
cases it means SMP, and not just dual CPU SMP, but more often quad CPU
and 8 CPU SMP systems. Those high-end routers and intelligent internet
devices eat SMP for breakfast.…and that in nushell makes SMP table stakes. It’s not going anywhere.
Cheers,
Camz.ps. SMP is also quite effective at finding all the threading issues/bugs in
your code SO much faster than on a single CPU machine.–
Martin Zimmerman > camz@passageway.com
Camz Software Enterprises > www.passageway.com/camz/qnx/
QNX Programming & Consulting
Kris,
With the provision that any program with an interrupt handler
is, at least potentially, multi-threaded.
Previously, Kris Warkentin wrote in qdn.public.qnxrtp.advocacy:
To say, “the apps are flakey, not the SMP” is a little disengineous since
most of the apps are not multi-threaded. If I’ve written an app that runs
multiple threads and it fails on an SMP system, then most likely I’m failing
to protect things properly. If a normal, run of the mill, single threaded
app is failing on an SMP system then there is something wrong with the
system. One could probably make a blanket statement to the effect that,
“any single threaded app which works on a single CPU system should ALWAYS
work on a correctly implemented multi CPU system.” I would invite you to
provide counter-examples if I’m wrong.cheers,
Kris
–
Mitchell Schoenbrun --------- maschoen@pobox.com
Previously, Kris Warkentin wrote in qdn.public.qnxrtp.advocacy:
Alright. I wasn’t including ISR’s in the list of ordinary, run of the mill,
application tasks but I suppose one needs to consider these sort of things
on QNX when all your drivers are running as ordinary (if privileged) apps.
Anyone else care to educate me further? I’ve often found that a strong
(even if erroneous) statement gets plenty of informative response. >
Well it is always possible that a library function might hide some thread
creation, but in this case, like the case of QNX supplied utilities,
SMP should work, or the mud is in QNX’s eye.
Mitchell Schoenbrun --------- maschoen@pobox.com
And, just for the record, I was a QNX customer/user/developer for nearly
5 years before I came to work for QNX. From autonomous robotic vehicles
to
embedded sensor systems for mining research to high-speed vision systems
for industrial control and manufacturing (hi wayne!).chris
D’Oh! You caught me lurching, Chris.
hahaha, knew I would!
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
D’Oh! You caught me lurching, Chris.
Wayne
Quit drawing attention to the lurkers!!