“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).
But not the type of IDE Raid you will find integrate in motherboard.
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.
In the context of low cost IDE Raid (High-point, Promise) it is the case.
That is the type of product I beleive Kris was talking about.
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 */
Ha! Ok, so, when you use embedded Neutrino, it is no longer Neutrino,
but ‘embedded Momentics’? Ok, I know, I know…
It really does not matter, but I was under the impression that Nto was
the kernel, Nto + other was RTP 6.x.x.x.x.x.x…z, and so on.
Humm…, sinze we had Quantum (that is QNX , Photon, Neutrino, I
wonder if the nezt eddition should be somewhat related to quarkz and
such (they are more eluzive than Neutrinoz, and more fundamental too).
Oh well…
(I was just talking to a friend of mine from Spain, and he carries a
very strong ‘z’ sound with his speaking. So we were laughing at our
accents and troubles with the english language, etc. )
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.
I’m convinced that any influence of the hardware is avoided when I
compare the loading time of a Python application under QNX6.2, Linux and
Windows.
I change only removable disks of the same type containing the different
operating systems … the Python application is exactly the same.
Different is only the OS and the IO system when a compare the loading
time … and it’s abvious that the IO subsystem of QNX6.2 is very slow
compared with Linux and Windows.
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.
When I look at the red LED of the disc activity … the file IO system
is always heavely active even if there is allocated a huge disc cache.
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.
Would be great
Cheers
Armin
Like proving who’s ego is bigger maybe?
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? >
I’m convinced that any influence of the hardware is avoided when I
compare the loading time of a Python application under QNX6.2, Linux and
Windows.
I change only removable disks of the same type containing the different
operating systems … the Python application is exactly the same.
Different is only the OS and the IO system when a compare the loading
time … and it’s abvious that the IO subsystem of QNX6.2 is very slow
compared with Linux and Windows.
Remember that QNX doesn’t support lazy binding nor (properly) paging from
disk. I’d imagine that Linux doesn’t in fact load the entire binary from
disk into memory, rather just the pages it needs, and it wouldn’t bother
doing symbol resolution unless you set the LD_BIND_NOW environment variable.
I’m still on Q4, so all that is ahead of me. I’m not smiling. When we port
if our application slows down by even 2-3% I’ll be screaming! You try frame
grabbing fully 640x480 color images and analyzing the image for defects in
18ms … every 18ms (3300 per minute).
Hopefully the hardware will be fast enough by the time you upgrade to
make up for the differences
Armin <> a-steinhoff@web.de> > wrote:
I’m convinced that any influence of the hardware is avoided when I
compare the loading time of a Python application under QNX6.2, Linux and
Windows.
I change only removable disks of the same type containing the different
operating systems … the Python application is exactly the same.
Different is only the OS and the IO system when a compare the loading
time … and it’s abvious that the IO subsystem of QNX6.2 is very slow
compared with Linux and Windows.
Remember that QNX doesn’t support lazy binding nor (properly) paging from
disk. I’d imagine that Linux doesn’t in fact load the entire binary from
disk into memory, rather just the pages it needs, and it wouldn’t bother
doing symbol resolution unless you set the LD_BIND_NOW environment variable.
As people discussed in IRC, set the sticky bit on your binaries and dlls
would help a lot.
I am curious, (that is, if you are still following), which way did you
go? And why?
regards…
Miguel.
Jun wrote:
Hi all,
We are looking for a RTOS for our new product. After looking at some
commecial RTOSs such as VxWorks, Win CE, QNX, Linux(maybe this is not a real
RTOS), we may go with
Linux or QNX.
Can anybody tell me why you switch from Linux to QNX or
from QNX to Linux?
I am wondering why Bill Gates does not want to adopt some good ideas in
their RTOS!
I am curious, (that is, if you are still following), which way did you
go? And why?
regards…
Miguel.
Jun wrote:
Hi all,
We are looking for a RTOS for our new product. After looking at some
commecial RTOSs such as VxWorks, Win CE, QNX, Linux(maybe this is not a real
RTOS), we may go with
Linux or QNX.
Can anybody tell me why you switch from Linux to QNX or
from QNX to Linux?
I am wondering why Bill Gates does not want to adopt some good ideas in
their RTOS!
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.
My opinion, constructive this time, is that there are certain things in the
OS that should be written in asm. I gained substantial speed improvements
just by writing my own asm memmove() function.
I’ve leave out all the other editorializing. Everyone knows how I feel
about the gnu compiler.
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 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.
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amq63j$ah9$> 1@inn.qnx.com> …
Wasn’t there some discussion about re-introducing a ‘sin ve’ into RTP? Is
that going to happen? It should, hands down.
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.
It makes sense that copying one large file across qnet is going to take
a lot shorter time than recursively copying numerous short files. There
are many more control messages to be sent.
Now I’m not claiming that pfm is doing this in as efficient manner as it
could be, but you see my point.
But even on qnx4 doing something like
tar -cf - srcdir | (cd destdir; on -f10 tar -xvf -)
was much faster than cp -cRvp . Perhaps pfm should use a similar
mechanism?
Yes, definitely faster. How much faster really depended on the file sizes.
Lots of little files was slow because of all the control messages, as you
point out above. A few big files and that was lost in the noise.
It always bothered me that I couldn’t make it faster in QNX4. Heaven knows
I tried. The overhead of VC creates, prefix lookups, more VC creates,
open/creat calls, etc. was something beyond my control, and fundamental to
the entire Q4 design.
“Armin” <> a-steinhoff@web.de> > wrote in message
news:> 3D8B9C9F.8070205@web.de> …
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.
That is sad.
Granted, filesystem, performance sucks too, but it is equally bad in
all cases, so it is irrelevant.
I’m guessing you are talking Q6 and I don’t know how it compares to Q4
performance. Once upon a time Q4 Fsys was one of the fastest things going,
but it was optimized for hardware which is now long obsolete. A major
redesign is long overdue, starting with the on-disk format. I should know.
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.
Darn! I jumped into the middle of this thread and until now I thought that
was the topic. OK, feel free to ignore me for another 5 years.
“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:> 3D8E4DA2.2070006@attbi.com> …
My opinion, constructive this time, is that there are certain things in
the
OS that should be written in asm. I gained substantial speed improvements
just by writing my own asm memmove() function.
That’s the sort of thing danh used to do “back in the day”. I remember the
significant improvements he brought to QNX2 with his hand-tweaked memcpy.
I’ve leave out all the other editorializing. Everyone knows how I feel
about the gnu compiler.
I’m still on Q4, so all that is ahead of me. I’m not smiling. When we port
if our application slows down by even 2-3% I’ll be screaming! You try frame
grabbing fully 640x480 color images and analyzing the image for defects in
18ms … every 18ms (3300 per minute).
Yes, definitely faster. How much faster really depended on the file sizes.
Lots of little files was slow because of all the control messages, as you
point out above. A few big files and that was lost in the noise.
It always bothered me that I couldn’t make it faster in QNX4. Heaven knows
I tried. The overhead of VC creates, prefix lookups, more VC creates,
open/creat calls, etc. was something beyond my control, and fundamental to
the entire Q4 design.
Now you share my pain
QNET (FLEET the same) is not orianted into file system. NFSv2, v3 is way
more faster. The fact is NFS “know” they are dealing with “Files”, QNET
don’t
open() (prefix lookup) is VERY VERY expansive operation, which is beyond
QNET’s control. Do a lot of cross network open() (like copy small files)
is killing performance.
I have tried everything including combine small packets into a big one,
but then we need “multi-threaded” cp, otherwise, it won’t help more.
Being said that, seeking performance improve is still a major task for
all of us in QSS.
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amq5oa$a7t$> 1@inn.qnx.com> …
“Igor Kovalenko” <> kovalenko@attbi.com> > wrote in message
news:> 3D8E4DA2.2070006@attbi.com> …
My opinion, constructive this time, is that there are certain things in
the
OS that should be written in asm. I gained substantial speed
improvements
just by writing my own asm memmove() function.
Someone told me they get 3x the speed by using MMX instruction to perform
memcpy!!!
I am curious, (that is, if you are still following), which way did you
go? And why?
regards…
Miguel.
Jun wrote:
Hi all,
We are looking for a RTOS for our new product. After looking at some
commecial RTOSs such as VxWorks, Win CE, QNX, Linux(maybe this is not a real
RTOS), we may go with
Linux or QNX.
Can anybody tell me why you switch from Linux to QNX or
from QNX to Linux?
I am wondering why Bill Gates does not want to adopt some good ideas in
their RTOS!
I got almost 6x speed improvements over 6.01a by just coding memmove() in
asm. No MMX needed. The gcc compiler just doesn’t produce good code. I
think the real problem was that after each byte moved, it kept checking to
see if it won yet or not. I took that part out. ;~}
William A. Flowers <> wflowers_NOSPAM@insightcontrol.com> > wrote:
It always bothered me that I couldn’t make it faster in QNX4. Heaven
knows
I tried. The overhead of VC creates, prefix lookups, more VC creates,
open/creat calls, etc. was something beyond my control, and fundamental
to
the entire Q4 design.
Now you share my pain >
Share it? Oh no. More like passed it on. That pain is behind me now.
I’ve got other thorns in my side these days. (OW!)
QNET (FLEET the same) is not orianted into file system. NFSv2, v3 is way
more faster. The fact is NFS “know” they are dealing with “Files”, QNET
don’t >
Yep. Shoulda, woulda, coulda been different. But none of us designing Q4
(myself included) were forward thinking enough (by a decade) to see the
requirement for ultimate network filesystem performance.
open() (prefix lookup) is VERY VERY expansive operation, which is beyond
QNET’s control. Do a lot of cross network open() (like copy small files)
is killing performance.
Too bad it wasn’t made better in Q6.
I have tried everything including combine small packets into a big one,
but then we need “multi-threaded” cp, otherwise, it won’t help more.
Being said that, seeking performance improve is still a major task for
all of us in QSS.
> The raw transfer rate
, Photon, Neutrino, I
