which way to go? Linux or QNX?

bridged with qdn.public.qnxrtp.advocacy
Post Reply
Armin

Re: File system performance?

Post by Armin » Fri Sep 20, 2002 11:19 am

camz@passageway.com wrote:
Colin Burgess <cburgess@qnx.com> wrote:

tar -cf - srcdir | (cd destdir; on -f10 tar -xvf -)


was much faster than cp -cRvp . Perhaps pfm should use a similar mechanism?


I've *NEVER* trusted the recursive mode of the cp command,
So you can't trust any copy and paste actions of pfm ??
it never seems to
behave the same way on two different OSs. So I *ALWAYS* use that tar trick.
Until now ... I haven't seen similar problems between Linux and M$Windows.

Armin
Cheers,
Camz.

Mario Charest

Re: which way to go? Linux or QNX?

Post by Mario Charest » Fri Sep 20, 2002 1:02 pm

Now is the speed/size difference so great that it can justify couple
thousand dollars on the compiler? For some people maybe. I bet that for
majority it is not. The reality is that lot of people use open source code
in their projects and that trend will probably grow. Then how about time
needed to work around compatibility issues when working with non-GNU
toolchains? It all comes down to the question of what time is more
important - human time or computer time. I don't think computer time is
worth $30/hour... Coumputer time also tends to become cheaper, while human
time tends to become more expensive.

I remember about 10 years ago, by boss got a new computer it was a 386,
don`t remember the speed though, but it was high tech at the time. Most of
the software people had 286, compile C program was taking very long. First
thing I try was try compiling the project on the 386. It compile almost 3
times faster. We all went to the boss and beg for new 386 machines,
thinking how much more efficient we could be. He told me that if I could
prove that the time saved by the speed of the 386 could justify the cost he
would by them. So I wrote a script that log the start and stop time of
compilation, at the end of the week we knew how much time the machine spent
compiling project. I don`t recall the exact number but I beleive it would
have taken something like 10 years to get a return on the investements.
Hence we all got to keep our 286, that is until the boss got himself a 486
and a lucky programmer got the 386 ;-)
My opinion is that it is not worth the effort right now for QNX to get
saddled with switching compiler. There are much more interesting things to
be done. Many of them would not be even possible in QNX4.
Quite true. I`` love to get the speed of Watcom, but I bought a faster
machine to run QNX6 and got over it.
-- igor

"Chris McKillop" <cdm@qnx.com> wrote in message
news:amdl0d$4av$3@nntp.qnx.com...
"Bill Caroselli \(Q-TPS\)" <QTPS@earthlink.net> wrote:
You can't "DEVELOP" in 16 mb.


You could - but why bother doing the work to make it possible when a
COTS
PC today comes with 10-20x that much memory? And because of the nature
of
gcc and related tools, they will be slow with so little memory. This is
one of the only things I miss from QNX4 - the speed and efficency of the
compiler. Although, watcom wasn't too fast when you fed it C++ with a
lot of templates.

chris


"Chris McKillop" <cdm@qnx.com> wrote in message
news:amc0vj$4gv$1@nntp.qnx.com...
All that aside, new development on QNX4 has ended. There won't be
any
new
device drivers written unless someone pays for it. This alone can
be
a
show
stopper. But if you can develop an application with generic off
the
shelf
components then QNX4 is my choice. I can develop a sophisticated
application with graphics and networking using QNX4 in 16 MB. I
can't
(hardly) log in in text mode in QNX6 in 16 MB.


And I can't find a COTS PC today with less then 128M, most come with
256M.
And the implication you are making is that Neutrino is unable to run
in
a
system with networking, graphics, and applications in less then 16M.
This
is untrue. Check http://qnxzone.com/eQip/ - a full PDA environment
with
kernel, flash filesystem, serial drivers, audio system, networking,
system services (hotswap and the like), photon, handwriting
recognition,
PDA front-end and a webbrowser running in about 12M. This is stock
Neutrino and Photon 2 with no effort to reduce memory useage.




--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I
get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/



Guest

Re: File system performance?

Post by Guest » Fri Sep 20, 2002 3:09 pm

Armin <a-steinhoff@web.de> wrote:
camz@passageway.com wrote:
I've *NEVER* trusted the recursive mode of the cp command,

So you can't trust any copy and paste actions of pfm ??
Armin, what are you smoking, we aren't even talking about pfm any more!
We are comparing the cp -R option with a clever trick using tar and pipes.

it never seems to
behave the same way on two different OSs. So I *ALWAYS* use that tar trick.

Until now ... I haven't seen similar problems between Linux and M$Windows.
Stop smoking that stuff! Windows doesn't even have a cp OR tar command,
so of course you wouldn't see this problem.

Cheers,
Camz.

Miguel Simon

Re: which way to go? Linux or QNX?

Post by Miguel Simon » Fri Sep 20, 2002 7:48 pm

Hi...

Mario Charest wrote:
Quite true. I`` love to get the speed of Watcom, but I bought a faster
machine to run QNX6 and got over it.
That is a great line. :)

Trade-off's. You'll hate them, but you will also learn to live with
them. I think that everyone would agree that QNX6 will only improve.
For example, I wonder when the next kernel release will take place?
Incidentally, how can I tell what is the current kernel version?

Keep hanging around Mario, do not go away just yet. Many have learned
quite a bit over the years by reading your answers to questions from
every one, including myself. You and many others have a lot to offer,
and every one appreciates that. The same goes for every one in your
list, and even those not in your least.

Regards...

Miguel.

Armin

Re: File system performance?

Post by Armin » Fri Sep 20, 2002 10:09 pm

camz@passageway.com wrote:
Armin <a-steinhoff@web.de> wrote:

camz@passageway.com wrote:

I've *NEVER* trusted the recursive mode of the cp command,


So you can't trust any copy and paste actions of pfm ??
because it seems to use a recursive cp command ...
Armin, what are you smoking, we aren't even talking about pfm any more!
No ... only YOU are talking about the cp and tar commands.
Collins statement was also related to pfm and underlaying copy mechanism!
We are comparing the cp -R option with a clever trick using tar and pipes.
YOU are comparing it ... not "we" (what ever it means). I"m talking
about the behavior of copy/paste action between QNET nodes.
it never seems to
behave the same way on two different OSs. So I *ALWAYS* use that tar trick.


Until now ... I haven't seen similar problems between Linux and M$Windows.


Stop smoking that stuff! Windows doesn't even have a cp OR tar command,
But it supports copy/paste as QNX and Linux does. And BTW ... Windows
has a copy command.


Armin

Igor Kovalenko

Re: File system performance?

Post by Igor Kovalenko » Sat Sep 21, 2002 6:40 pm

"Armin" <a-steinhoff@web.de> wrote in message
news:3D8B9C9F.8070205@web.de...
camz@passageway.com wrote:
Armin <a-steinhoff@web.de> wrote:

camz@passageway.com wrote:

I've *NEVER* trusted the recursive mode of the cp command,


So you can't trust any copy and paste actions of pfm ??

because it seems to use a recursive cp command ...

Armin, what are you smoking, we aren't even talking about pfm any more!

No ... only YOU are talking about the cp and tar commands.
Collins statement was also related to pfm and underlaying copy mechanism!

We are comparing the cp -R option with a clever trick using tar and
pipes.

YOU are comparing it ... not "we" (what ever it means). I"m talking
about the behavior of copy/paste action between QNET nodes.

it never seems to
behave the same way on two different OSs. So I *ALWAYS* use that tar
trick.


Until now ... I haven't seen similar problems between Linux and
M$Windows.


Stop smoking that stuff! Windows doesn't even have a cp OR tar command,

But it supports copy/paste as QNX and Linux does. And BTW ... Windows
has a copy command.
What a lovely discussion, I like the technical depth and width of
arguments...

Windows and QNX 'copy command' is nothing but a dumb interface to underlying
I/O subsystem. The cp utility is nothing but dumb interface to the same I/O
subsystem. The tar utility is yet another dumb interface to the same I/O
subsystem. They all end up doing open/read/write. By 'dumb' I mean that they
don't try to be clever and just do that.

Copy/paste of files between QNET nodes sucks because I/O over QNET sucks,
not because filesystem performance is misteriously slower using pfm than
using cp or tar. I have a case when QNET is 5x slower on copying a file than
FTP. Granted, filesystem, performance sucks too, but it is equally bad in
all cases, so it is irrelevant. True, tar makes things faster because it
reduces number of *remote* read/write requests (at the expense of more
*local* read/write requests). So what? It is off-topic.

Whatever people are smoking, both cp and tar are *applications*, it is silly
to point that Windows 'does not have them'. Applications are not property of
OS (although M$ might think otherwise). They can be written and they have
been written. I have tar on Windows and surely it does come with copy and
xcopy.

Come on guys. Long pause in flamewars should not be replaced by discussions
as shallow and boring as this. We do have higher goals, don't we? Like
proving who's ego is bigger maybe? :p

Cheers,
-- igor

Chris McKillop

Re: which way to go? Linux or QNX?

Post by Chris McKillop » Sun Sep 22, 2002 6:46 am

Trade-off's. You'll hate them, but you will also learn to live with
them. I think that everyone would agree that QNX6 will only improve.
For example, I wonder when the next kernel release will take place?
Incidentally, how can I tell what is the current kernel version?
uname -a

For example, on my machine it is...

QNX bigbox 6.2.1 2002/09/17-16:53:13EDT x86pc x86

...on most machines for people outside of QSS it will be 6.2.0.

chris

--
Chris McKillop <cdm@qnx.com> "The faster I go, the behinder I get."
Software Engineer, QSSL -- Lewis Carroll --
http://qnx.wox.org/

Armin

Re: File system performance?

Post by Armin » Sun Sep 22, 2002 1:35 pm

Igor Kovalenko wrote:
"Armin" <a-steinhoff@web.de> wrote in message
news:3D8B9C9F.8070205@web.de...

[ clip ..]
What a lovely discussion, I like the technical depth and width of
arguments...

Windows and QNX 'copy command' is nothing but a dumb interface to underlying
I/O subsystem. The cp utility is nothing but dumb interface to the same I/O
subsystem. The tar utility is yet another dumb interface to the same I/O
subsystem. They all end up doing open/read/write. By 'dumb' I mean that they
don't try to be clever and just do that.

Copy/paste of files between QNET nodes sucks because I/O over QNET sucks,
not because filesystem performance is misteriously slower using pfm than
using cp or tar. I have a case when QNET is 5x slower on copying a file than
FTP. Granted, filesystem, performance sucks too, but it is equally bad in
all cases, so it is irrelevant. True, tar makes things faster because it
reduces number of *remote* read/write requests (at the expense of more
*local* read/write requests). So what? It is off-topic.

Whatever people are smoking, both cp and tar are *applications*, it is silly
to point that Windows 'does not have them'. Applications are not property of
OS (although M$ might think otherwise). They can be written and they have
been written. I have tar on Windows and surely it does come with copy and
xcopy.

Come on guys. Long pause in flamewars should not be replaced by discussions
as shallow and boring as this. We do have higher goals, don't we?
Yes ... e.g. to have a convenient Eclipse. It takes more than 1 MINUTE
to load Eclipse on a 200MB and 700Mhz system.

It makes no sense to blame Eclipse (Java) for this as long as the file
system is amazingly slow.

I pointed out in my initial statement that there are similar problems
with the loading of Python based applications from a _LOCAL_ file
system. (I able to compare the loading time directly with the time
needed under Linux and Windows)

I also didn't link the copy/paste problem with the file system
performance because it is mixed up with the QNET protocol
Like proving who's ego is bigger maybe? :p
I don't have such problems ... but I dislike this flashy waffleing about
'smoking'

Cheers

Armin
Cheers,
-- igor


Igor Kovalenko

Re: File system performance?

Post by Igor Kovalenko » Sun Sep 22, 2002 11:09 pm

Armin wrote:
Come on guys. Long pause in flamewars should not be replaced by
discussions
as shallow and boring as this. We do have higher goals, don't we?


Yes ... e.g. to have a convenient Eclipse. It takes more than 1 MINUTE
to load Eclipse on a 200MB and 700Mhz system.

It makes no sense to blame Eclipse (Java) for this as long as the file
system is amazingly slow.

I pointed out in my initial statement that there are similar problems
with the loading of Python based applications from a _LOCAL_ file
system. (I able to compare the loading time directly with the time
needed under Linux and Windows)

I also didn't link the copy/paste problem with the file system
performance because it is mixed up with the QNET protocol
If you're using a modern EIDE or SCSI drive, you should get I/O
bandwidth of about 30-40Mb/sec. That is about same as you get under
Linux/Windows, because at this point the drives limit bandwidth sooner
than OS limits it. Accessing lot of small files is different story,
that's where most impact from filesystem comes I think. Not sure it
alone can explain the slowness of Eclipse though. Some important libc
functions like malloc() and memmove() have issues in QNX and that may
contribute quite a bit. Photon bindings for SWT may not be perfect...

Bottom line, it is complicated issue. Good news is, we have Chris
looking into it :) And there is rumor that 6.2.1 will have considerably
improved I/O performance.
Like proving who's ego is bigger maybe? :p


I don't have such problems ... but I dislike this flashy waffleing about
'smoking'
Expressions like 'What are you smoking' and 'Stop smoking that stuff'
are just north-american jokes. It does not imply anything real and often
used in friendly conversations, especially by younger folks. Think you
could forgive camz for being so informal? ;)

Cheers,
-- igor

phearbear

Re: which way to go? Linux or QNX?

Post by phearbear » Mon Sep 23, 2002 12:28 am

Miguel Simon wrote:
Hi...

Chris McKillop wrote:

For example, I wonder when the next kernel release will take place?
Incidentally, how can I tell what is the current kernel version?



uname -a

For example, on my machine it is...

QNX bigbox 6.2.1 2002/09/17-16:53:13EDT x86pc x86



Yes, I know this, but what about the kernel version? The above is the
version of the rtp which is 6.2.1 in your case, but it is my
understanding that the actual Nto kernel version is something like
2.1.1. Would this be correct? Then the question is: how could I tell
the actual version of Nto kernel (or does this question makes on sense)?

I think they changed all this, so now it all simply is Momentics.. err..
RTP.. err.. never mind, it all *is* , and it *is* 620, cause the
includes say so ;)
sys/neutrino.h : 61

#define _NTO_VERSION 620 /* version number * 100 */


/Johan
regards...

Miguel.



..on most machines for people outside of QSS it will be 6.2.0.

chris


Kris Warkentin

Re: File system performance?

Post by Kris Warkentin » Mon Sep 23, 2002 1:04 pm

One thing I haven't tried but I know some people who have had very good
results with it is IDE RAID. Lots of current motherboards support it and
are quite inexpensive. Then you get a couple cheap drives and stripe them
(RAID 0) and you get some pretty good throughput. As far as I know it's all
setup in the bios so the controller just presents an IDE drive to the
software (by which I mean you might have a good chance Neutrino would run
it)

cheers,

Kris

Rick Duff

Re: File system performance?

Post by Rick Duff » Mon Sep 23, 2002 2:03 pm

Igor Kovalenko wrote:
Armin wrote:
Come on guys. Long pause in flamewars should not be replaced by
discussions
as shallow and boring as this. We do have higher goals, don't we?


Yes ... e.g. to have a convenient Eclipse. It takes more than 1 MINUTE
to load Eclipse on a 200MB and 700Mhz system.

It makes no sense to blame Eclipse (Java) for this as long as the file
system is amazingly slow.

I pointed out in my initial statement that there are similar problems
with the loading of Python based applications from a _LOCAL_ file
system. (I able to compare the loading time directly with the time
needed under Linux and Windows)

I also didn't link the copy/paste problem with the file system
performance because it is mixed up with the QNET protocol


If you're using a modern EIDE or SCSI drive, you should get I/O
bandwidth of about 30-40Mb/sec. That is about same as you get under
Linux/Windows, because at this point the drives limit bandwidth sooner
than OS limits it. Accessing lot of small files is different story,
that's where most impact from filesystem comes I think. Not sure it
alone can explain the slowness of Eclipse though. Some important libc
functions like malloc() and memmove() have issues in QNX and that may
contribute quite a bit. Photon bindings for SWT may not be perfect...
You can make a huge tradeoff in startup speed (at the expense of later
performance), but turning off jit. It now starts up on my machine in
less than 10 seconds.

Rick..
--
Rick Duff Internet: rick@astranetwork.com
Astra Network QUICS: rgduff
QNX Consulting and Custom Programming URL:
http://www.astranetwork.com
+1 (204) 987-7475 Fax: +1 (204) 987-7479

Mario Charest

Re: File system performance?

Post by Mario Charest » Mon Sep 23, 2002 2:14 pm

"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:amn3cj$nbj$1@nntp.qnx.com...
One thing I haven't tried but I know some people who have had very good
results with it is IDE RAID. Lots of current motherboards support it and
are quite inexpensive. Then you get a couple cheap drives and stripe them
(RAID 0) and you get some pretty good throughput. As far as I know it's
all
setup in the bios so the controller just presents an IDE drive to the
\
software (by which I mean you might have a good chance Neutrino would run
it)
No it would not since Neutrino doesn't go through the BIOS . The hardware
interface is very different then normal IDE

The performance increase isn't that great ;-) The raw transfer rate improves
quite a lot, but real life activity don't get speed up that much.
Futhermore you can't move a RAID setup to a different motherboard unless it
used the same chip. So if the motherboard dies you need to get a
replacement with exact same raid chip.
cheers,

Kris

Miguel Simon

Re: which way to go? Linux or QNX?

Post by Miguel Simon » Mon Sep 23, 2002 2:17 pm

Hi...

Chris McKillop wrote:
For example, I wonder when the next kernel release will take place?
Incidentally, how can I tell what is the current kernel version?



uname -a

For example, on my machine it is...

QNX bigbox 6.2.1 2002/09/17-16:53:13EDT x86pc x86
Yes, I know this, but what about the kernel version? The above is the
version of the rtp which is 6.2.1 in your case, but it is my
understanding that the actual Nto kernel version is something like
2.1.1. Would this be correct? Then the question is: how could I tell
the actual version of Nto kernel (or does this question makes on sense)?

regards...

Miguel.

..on most machines for people outside of QSS it will be 6.2.0.

chris

Igor Kovalenko

Re: File system performance?

Post by Igor Kovalenko » Mon Sep 23, 2002 6:56 pm

"Mario Charest" <postmaster@127.0.0.1> wrote in message
news:amn759$4nd$1@inn.qnx.com...
"Kris Warkentin" <kewarken@qnx.com> wrote in message
news:amn3cj$nbj$1@nntp.qnx.com...
One thing I haven't tried but I know some people who have had very good
results with it is IDE RAID. Lots of current motherboards support it
and
are quite inexpensive. Then you get a couple cheap drives and stripe
them
(RAID 0) and you get some pretty good throughput. As far as I know it's
all
setup in the bios so the controller just presents an IDE drive to the
\
software (by which I mean you might have a good chance Neutrino would
run
it)

No it would not since Neutrino doesn't go through the BIOS . The hardware
interface is very different then normal IDE
It depends. If the RAID is bridgeless (i.e., it exposes the IDE chips to the
host) then it might work (I understand some older DPT SCSI RAID cards worked
that way with NTO).

Most of SCSI RAID cards these days have a non-transparent bridge. Host will
only see the processor (usually i960 or SA1100 or Xscale lately) and SCSI
chips will be behind the bridge. I don't know about IDE RAIDs.
The performance increase isn't that great ;-) The raw transfer rate
improves
quite a lot, but real life activity don't get speed up that much.
Yes, bandwidth and TPS are different benchmarks. SCSI RAID systems usually
try to improve the TPS by using large cache (64Mb-128Mb). IDE versions are
mostly designed for bandwidth-greedy applications like video editing.
Futhermore you can't move a RAID setup to a different motherboard unless
it
used the same chip. So if the motherboard dies you need to get a
replacement with exact same raid chip.
Not always true. Some vendors support migration of RAID setups to newer
versions of their product.

-- igor

Post Reply

Return to “qdn.public.qnxrtp.advocacy”