Igor Kovalenko <kovalenko@attbi.com> wrote:
“Robert Krten” <> nospam83@parse.com> > wrote in message
news:amrdak$6ve$> 1@inn.qnx.com> …
[snip]
Oh Igor.
vent
Instead of shitting all over everything, why don’t you come up with
a better way? Can you come up with something that uses message passing
for open() that won’t suck? As you no doubt know, QNX is a message
passing
OS. Yes, that means that it passes messages. A message from the client
to the server. And back. Yes, these are small messages. Yes, small
messages incur an overhead. It’s easy to say “I’ve said this sucks and
no one has fixed it”. But unless you come up with “I’ve said this sucks,
and here’s a really good way to fix it, why haven’t you implemented this?”
you’re just pissing into the wind! This point too has been raised
multiple
times, but I have yet to see any reply from > kovalenko@attbi.com > that
suggests anything better. Xiaodan has told you what the problems are,
I could point you to a MUCH earlier thread when I was arguing over this with
jgarvey. So no, I did not learn this from xtang. If you want to make a point
make sure you have one. That was not a public group unfortunately.
I made my points based on what is available to me.
and you just quoted his reply and claimed, in a “revelation from god/Igor”
kind of way, to have “found the reason” – he already knows about it:
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.
/vent
See? Venting is easy. Solving the problems is much harder.
I don’t see where he’s saying that issue is with slowness of message passing
on small buffers.
As I understood it, the thread was talking about copying lots of small
files across a network. This involves name resolution, which involves
lots of open()s with small messages.
more ventage
If you’re so “disillusioned” with QNX, then maybe you should use Windows?
I’m like so totally sure it’s an all round “better” OS. Or linux?
Why are you wasting your time complaining about QNX, when there must
surely be much better OS’s around? After all, I’m sure all
problems have been solved under all other OS’s except QNX. I just
love the idea of digging deep into the kernel to install device
drivers – yummy. Or using an OS that has a “flavour of the day”
based on which 12 year old MS-DOS hacker just wrote a device driver for
it using polling in the kernel – yummy creamy double-plus good. Or have
an
“open source team” of rabid monkeys running around making 75 different
(incompatible) kernel versions that are all trying to piss over each other
as the “next standard” – faaaaaabulous.
(That was sarcasm for those who missed it).
/ventage
This is typical mumbo-jumbo QNX zealots like to say. Most of the time I hear
this from people who never bothered to read a single good book on Unix
kernel design and just blindly believe that QNX does everything ‘the right
way’ while everyone else is just dumb to understand it. Unless you’re
prepared to defend every word you’re saying with substantiated arguments, it
only makes you look ridiculous.
Let’s not get into personal attacks. I’ve worked on iRMX86, iRMX286, VAX/VMS,
Unix, Xenix, and Linux, to name a few. Let me “defend” my points:
o rebuilding the kernel and digging deep into the kernel was the method used
to install device drivers in my experience.
o ALSA is a classic example; the devctl() passes a pointer to something in
the client’s address space, causing the driver to root around in the client’s
address space at kernel level.
o several projects I’ve been peripherally involved with needed to get support
for various linux packages, which depended on different (incompatible) versions
of the kernel.
o I’ve seen drivers where they were ported from single-user MS-DOS mode with
polling, in the kernel.
Your experience may be different; those are my experiences.
:-/
I’m not going to apologize for defending the QNX OS – it’s a damn good
OS.
Put up, or make constructive suggestions. Please!
I believe I did. Furthermore, they apparently were implemented (quietly,
without ever acknowledging the problem) for next QNX versions. From
unofficial sources, next version will use 64k blocks for I/O internally.
Current one does 128 x MsgWrite(512 bytes) and then does MsgReply(). Is that
so ‘damn good’?
Sounds like the problem is fixed. Let’s move on.
Now to the message passing. I do have constructive suggestions. Wait until
tomorrow, you should see a white paper on QNXZone.
Where is it? Please post when it appears.
Cheers,
-RK
–
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.
