Previously, Bill Caroselli (Q-TPS) wrote in qdn.public.qnxrtp.advocacy:
Write a utility that reads sequentially through an entire hard drive, QNX4
is faster.
Write a utility that lseek()s and reads backwards through an entire hard
drive, QNX4 is faster.
While I disagree about the current importance of this Bill,
it does send my hackles up. I think it is well known that
QSSL does not like the performance of their QNX 6 I/O. The
overall structure was redesigned from QNX 4 to deal with a
natty problem, that in QNX 4 it was very hard to deal with
things like SCSI scanners and tape drives, or Fibre channel
networking capabilities. The problem for QNX 4 is that the
drivers were on the bottom of the stack so to speak and
support other than straight disk I/O had to be added to
Fsys. QNX 6 turned the stack upside down so that a driver
requests support from below for, say a file system. This is
all well and good, but apparently the first implementation
required a lot of extra copying of data, which once you get
your caching straight, causes most differences in the speed
of file systems. Good old DOS which copied data data
directly from hardware to your buffer had great throughput.
So as a consequence, QSSL decided to NOT release the interface
specifications. This was because they were going to fix
things real soon now, and they didn’t want people, I guess
like me, complaining that they changed things. This was
true even though I literally begged and promised that I would
not complain.
So here we are, how many years later? Still no new I/O system,
apparently because the important customers don’t really care,
and still no specs. Yak yak yak.
Mitchell Schoenbrun --------- maschoen@pobox.com
Mario Charest wrote:
I realized this when a customer of mine expressed releif hearing QNX6
was using GCC. But then again he is worry that QNX is too depend
on IBM for eclipse (he related some story were IBM decided to
change directory and abandon lots of 3rd party in the process)
Yes, IBM could change direction, but since they have open sourced their
entire contribution, I don’t think QSSL has a lot of risk associated
with Eclipse (it sure is a lot better than anything they could have
achieved alone).
I think that IBM is really bearing the risk. This is just one of their
skirmishes with Sun, and the worst that can happen to QSSL is that they
end up with an IDE that doesn’t have the same level of support as the
leading Java workbench (whatever that might be). That puts them a long
way ahead of where they were (which was no IDE at all).
IMO I think Eclipse has a good chance of becoming the leading
environment in a couple of years, if this happens, then QSSL wins really
big (i.e. it would put them light years ahead of WindRiver in the tools
department, and with an OS that is already light years ahead, I think we
would see QSSL and WindRiver switch market positions).
Rennie
“Bill Caroselli (Q-TPS)” wrote:
First of all I was only comparing QNX4 & QNX6.
Write a utility that reads sequentially through an entire hard drive, QNX4
is faster.
Write a utility that lseek()s and reads backwards through an entire hard
drive, QNX4 is faster.
May be … but also the handling of interrupts takes more CPU power for
QNX6 than for QNX4.
This is visible when I run a PROFIBUS-DP slave board under QNX4 or QNX6
… the interrupt load is very high if the slave board is the single
slave (not the standard case) in a DP network (interrupts every
20-30us). Both resource managers running mainly the same code … but
the CPU load is much higher with QNX6.
Is the optimization of the interrupt handling on the to-do list of
QSSL ?
Armin
Compile a project of 100 or more modules averaging 1000 lines each, QNX4 is
faster.
Do a memmove() of a million bytes a thousand times, QNX4 is faster.
Don’t even consider the time it takes to read through a directory and open()
1000 files and close them. QNX4 is faster.
All of these tests were done on three different hardware platforms for both
QNX4 and QNX6.
“Dmitri Poustovalov” <> pdmitri@sympatico.ca> > wrote in message
news:absja1$96v$> 1@inn.qnx.com> …
Which way? Only number I’ve seen came from Dedicated Systems.
http://www.dedicated-systems.com/Encyc/BuyersGuide/RTOS/evaluations/login.as
p
has a few reports RTOSes including VxWorks5.3/pSOS2/QNX4 report and QNX6
one. Since
Bill Caroselli (Q-TPS) wrote:
And let’s fact it, QNX4 did NOT have multi-thread support.
It only pretended to.
Glad to hear you referring to QNX4 in the past tense (your making
progress - I’d guess you’re at step 6 in the 12 step “get off of QNX4”
program 
Maybe unlike you, my customer was
not willing to pay for writing something that had planned obsolescence.
I bet they don’t want to pay for anything to be written under Windows
then
Bill Caroselli (Q-TPS) wrote:
QNX4 is dead. You know it and I know it. QSSL will never enhance it again.
But it is a far superior product for “new” system development. LONG LIVE
QNX4. It is what I am recommending to anyone starting new development.
OK, maybe step 4 is a better guess
Compile a project of 100 or more modules averaging 1000 lines each, QNX4
is
faster.
That’s not the OS that’s GCC.
But GCC is the only compiler available so that I’d count it as part of OS
then.
It has big negative impact to applications quality if we compare it with
watcom
which in turn also is the only compiler available for QNX4.
cheers,
Igor
“Igor Levko” <no_spam@nihrena.net> wrote in message
news:ac0fuk$8pp$1@inn.qnx.com…
Compile a project of 100 or more modules averaging 1000 lines each,
QNX4
is
faster.
That’s not the OS that’s GCC.
But GCC is the only compiler available so that I’d count it as part of
OS
then.
It has big negative impact to applications quality if we compare it with
watcom
which in turn also is the only compiler available for QNX4.
Not only it is the only compiler but it’s a dead compiler.
Watcom gave up on QNX, Metroworks gave up on QNX4 and 6.
I doubt we’ll see the same problem with gcc. I now think
gcc strengh far outweights it’s weakness.
I realized this when a customer of mine expressed releif hearing QNX6
was using GCC. But then again he is worry that QNX is too depend
on IBM for eclipse (he related some story were IBM decided to
change directory and abandon lots of 3rd party in the process)
cheers,
Igor
“Mario Charest” <goto@nothingness.com> wrote in message
news:ac0gi5$962$1@inn.qnx.com…
“Igor Levko” <> no_spam@nihrena.net> > wrote in message
news:ac0fuk$8pp$> 1@inn.qnx.com> …
Compile a project of 100 or more modules averaging 1000 lines each,
QNX4
is
faster.
That’s not the OS that’s GCC.
But GCC is the only compiler available so that I’d count it as part
of
OS
then.
It has big negative impact to applications quality if we compare it with
watcom
which in turn also is the only compiler available for QNX4.
Not only it is the only compiler but it’s a dead compiler.
Watcom gave up on QNX, Metroworks gave up on QNX4 and 6.
I doubt we’ll see the same problem with gcc. I now think
gcc strengh far outweights it’s weakness.
I realized this when a customer of mine expressed releif hearing QNX6
was using GCC. But then again he is worry that QNX is too depend
on IBM for eclipse (he related some story were IBM decided to
change directory and abandon lots of 3rd party in the process)
That is kind of neat to hear. A lot of the time, we only hear bad things
about free software and the GPL. It’s cool that your customer realizes that
the advantage of free software is that you aren’t slave to a vendor and that
the code CAN’T be taken away on the whim of some behemoth like IBM or
Microsoft.
cheers,
Igor
\
Just FYI:
We always want to use GCC, with all our systems. Of course, we don’t
develop either on or for Intel boxes so there are fewer choices, and
GCC is really one of the best out there. People always complain about
GCC on Intel, but that is irrelevant to us. We’re happy happy happy
with QNX’s use of Open Source, and it’s definitely a primary factor in
our decision to work with them. Having a portable compiler is really a
critical factor for us.
In my experience, any use of proprietary tools will eventually come
around and bite you in the butt, somehow. Obviously you can’t always
avoid them, but it’s always been worth the hassle to us to do so where
we can.
For example, someone mentioned Eclipse: even if IBM completely dumps it,
it’s Open Source and there are enough companies working with it now that
it will probably survive. If it were proprietary and IBM gave up on it,
life could get very messy.
FWIW, I’ve been hearing really good things about GCC 3.1 in terms of
both compilation speed and code generation quality. YMMV, I haven’t
tried it.
–
Paul D. Smith <pausmith@nortelnetworks.com> HASMAT–HA Software Mthds & Tools
“Please remain calm…I may be mad, but I am a professional.” --Mad Scientist
These are my opinions—Nortel Networks takes no responsibility for them.
“Mario Charest” <goto@nothingness.com> wrote in message
news:abuujs$4f3$1@inn.qnx.com…
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:abuha8$oj4$> 1@inn.qnx.com> …
What is your hardware?
Dell Inspiron 7500 and dual celeron.
The difference is QNX6 uses DMA which makes a HUGE difference.
Note that 6.2 is slightly better at using/detecting DMA depending on your
chipset.
It’s possible that if QNX6 isn’t using DMA that’s it’s slower then
QNX4, I don’t know.
OK. That makes sense. I’m still running 6.1a. How can I tell if DMA is
working?
“Mitchell Schoenbrun” <maschoen@pobox.com> wrote in message
news:Voyager.020515175046.20829B@node1…
While I disagree about the current importance of this Bill,
it does send my hackles up. I think it is well known that
QSSL does not like the performance of their QNX 6 I/O. The
overall structure was redesigned from QNX 4 to deal with a
natty problem, that in QNX 4 it was very hard to deal with
things like SCSI scanners and tape drives, or Fibre channel
networking capabilities. The problem for QNX 4 is that the
drivers were on the bottom of the stack so to speak and
support other than straight disk I/O had to be added to
Fsys. QNX 6 turned the stack upside down so that a driver
requests support from below for, say a file system. This is
all well and good, but apparently the first implementation
required a lot of extra copying of data, which once you get
your caching straight, causes most differences in the speed
of file systems. Good old DOS which copied data data
directly from hardware to your buffer had great throughput.
So as a consequence, QSSL decided to NOT release the interface
specifications. This was because they were going to fix
things real soon now, and they didn’t want people, I guess
like me, complaining that they changed things. This was
true even though I literally begged and promised that I would
not complain.
So here we are, how many years later? Still no new I/O system,
apparently because the important customers don’t really care,
and still no specs. Yak yak yak.
OK Mitch. You can let you hackles down now.
I know about what you are saying. I understand it and agree with it in
theory. And if they were coming back from time to time and saying that they
were working on the speed issue I would be quiet about it. But instead, as
you imply, they seem to think people are satisfied with it.
My only original point was that QNX6 is across the board slower than QNX4.
And I have a hard time calling that an “improvement”. I do like working
with threads. And let’s fact it, QNX4 did NOT have multi-thread support.
It only pretended to.
Like you, and Robert Krten I’ve had requests from hardware vendors to write
drivers for their disk controllers but can not do so until QSSL is done
defining their API for the file system. Maybe unlike you, my customer was
not willing to pay for writing something that had planned obsolescence.
“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE37A10.CCA97AE7@web_.de…
May be … but also the handling of interrupts takes more CPU power for
QNX6 than for QNX4.
This is visible when I run a PROFIBUS-DP slave board under QNX4 or QNX6
… the interrupt load is very high if the slave board is the single
slave (not the standard case) in a DP network (interrupts every
20-30us). Both resource managers running mainly the same code … but
the CPU load is much higher with QNX6.
Because of the multi-threading I can understand a context switch being
somewhat longer. But it should not be much longer. Can you give a number
of how much longer? 50% 100% 200%
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CE38420.4010104@csical.com…
Bill Caroselli (Q-TPS) wrote:
And let’s fact it, QNX4 did NOT have multi-thread support.
It only pretended to.
Glad to hear you referring to QNX4 in the past tense (your making
progress - I’d guess you’re at step 6 in the 12 step “get off of QNX4”
program >
QNX4 is dead. You know it and I know it. QSSL will never enhance it again.
But it is a far superior product for “new” system development. LONG LIVE
QNX4. It is what I am recommending to anyone starting new development.
“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ac0m2q$dgn$1@inn.qnx.com…
“Mario Charest” <> goto@nothingness.com> > wrote in message
news:abuujs$4f3$> 1@inn.qnx.com> …
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:abuha8$oj4$> 1@inn.qnx.com> …
What is your hardware?
Dell Inspiron 7500 and dual celeron.
The difference is QNX6 uses DMA which makes a HUGE difference.
Note that 6.2 is slightly better at using/detecting DMA depending on
your
chipset.
It’s possible that if QNX6 isn’t using DMA that’s it’s slower then
QNX4, I don’t know.
OK. That makes sense. I’m still running 6.1a. How can I tell if DMA is
working?
don’t know how. I just know DMA is working for me cause it way faster 
I beleive looking at the sloginfo could tell you if the driver is started
with verbose (not sure).
I don’t do steps. I take the elevator.
“Rennie Allen” <rallen@csical.com> wrote in message
news:3CE38E74.3000003@csical.com…
OK, maybe step 4 is a better guess >
Like you, and Robert Krten I’ve had requests from hardware vendors to
write
drivers for their disk controllers but can not do so until QSSL is done
defining their API for the file system. Maybe unlike you, my customer was
not willing to pay for writing something that had planned obsolescence.
On the other side of the coin Bill don’t forget there are DDK for network
which wasn’t available for QNX4.
The QNX4 stuff for filesystem was very difficult to work with.
You may have been one of the few to be able to do something with
it but in general things have improved on that end with QNX6.
Some of us are still waiting for some DDK to come up but the
overall situation is definitely better!!!
“Bill Caroselli (Q-TPS)” wrote:
“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE37A10.CCA97AE7@web_.de…
May be … but also the handling of interrupts takes more CPU power for
QNX6 than for QNX4.
This is visible when I run a PROFIBUS-DP slave board under QNX4 or QNX6
… the interrupt load is very high if the slave board is the single
slave (not the standard case) in a DP network (interrupts every
20-30us). Both resource managers running mainly the same code … but
the CPU load is much higher with QNX6.
Because of the multi-threading I can understand a context switch being
somewhat longer. But it should not be much longer. Can you give a number
of how much longer? 50% 100% 200%
It’s hard to say … I would estimate it’s in the range of 50%
(The relationship of the CPU load and the interrupt load is not liniar
…)
Armin
I’m not QSSL but I’m guessing that anything more than 15-20% more is a sign
that something isn’t right.
“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE618F9.98632E01@web_.de…
“Bill Caroselli (Q-TPS)” wrote:
Because of the multi-threading I can understand a context switch being
somewhat longer. But it should not be much longer. Can you give a
number of how much longer? 50% 100% 200%
It’s hard to say … I would estimate it’s in the range of 50%
(The relationship of the CPU load and the interrupt load is not liniar