Current QNX RtP QNET status...

Fred · January 21, 2001, 12:36am

Does the native QNX RtP is working or not ?

We are currently installing a QNX RtP lab
and someone from the last conference told me
that it doesn’t work as supposed ?

That it crash often every 10-15 minutes.

Is that true?

We used to use QNX4 networking for the old lab,
since we move on to RtP, I would like to use the same thing.

Is that feasible ?

e.g.
ln -s //4/home //1/home

for instance.

Thank you!

Fred.

Chris_Foran2 · January 22, 2001, 4:59am

According to:

http://qdn.qnx.com/news/releases/releasenotes.html

where it includes qnet:
"…some components in this distribution are not necessarily of “release
quality” "

qnet is working, but sometimes there are problems. You might try using a
hard link instead of a soft, if you can. Just a guess on my part though.
When you say it crashes, do you mean just the networking goes down?
TCP/IP and qnet? Just qnet?

I think what you want to do should be fine. qnet is now using names instead
of node numbers as in QNX4 networking.

“Fred” <fprog@users.sourceforge.net> wrote in message
news:94dahu$r8a$1@inn.qnx.com…

Does the native QNX RtP is working or not ?

We are currently installing a QNX RtP lab
and someone from the last conference told me
that it doesn’t work as supposed ?

That it crash often every 10-15 minutes.

Is that true?

We used to use QNX4 networking for the old lab,
since we move on to RtP, I would like to use the same thing.

Is that feasible ?

e.g.
ln -s file://4/home file://1/home

for instance.

Thank you!

Fred.

\

Fred · February 10, 2001, 7:33am

Chris Foran wrote in message <94geej$nj4$1@inn.qnx.com>…

According to:

http://qdn.qnx.com/news/releases/releasenotes.html

where it includes qnet:
"…some components in this distribution are not necessarily of “release
quality” "

qnet is working, but sometimes there are problems. You might try using a
hard link instead of a soft, if you can. Just a guess on my part though.
When you say it crashes, do you mean just the networking goes down?
TCP/IP and qnet? Just qnet?

I think what you want to do should be fine. qnet is now using names
instead
of node numbers as in QNX4 networking.

We decided to use NFS through a Suse Linux Gateway/Firewall,
that host the link to the outside world and the home directories.
QNET wasn’t simply enough stable…

It often happens for instance that qnet and nfs crash altogheter
when accessing for instance a nfs/qnet other machine.

Currently, we mostly use nfs/qnet to arrange the new Arcom ELAN-104NC
boards we have at hand, but it often happens that our Pentium III crash
completely (RESET button is the only thing that works), while the Arcom
board
doesn’t. Most of the time the machine accessing a qnet resource crash
while the qnet client doesn’t. Sometime both crash, sometimes it works
for 5 minute then crash.

I wouldn’t even call QNET of Beta quality, it stinks compare to the
high-level
reliability of QNET for QNX4. I don’t know who designed/wrote
QNET for QNX4, but I would be surprise it’s the same person
that wrote it for RtP ?!

Anyway, in my point of view, QNET for RtP should really go through
some severe modification in order to have all the usefulness
and all the fun and pleasure we had to use QNET similar network under QNX4.

5-10 minutes compare to intensive 6 months usage, what a compromise !

Anyway, all this to say that me and most likely many other QNX users
would really appreciate a really good quality, reliable QNET driver.

Sincerly,
Fred.

Does the native QNX RtP is working or not ?

We are currently installing a QNX RtP lab
and someone from the last conference told me
that it doesn’t work as supposed ?

That it crash often every 10-15 minutes.

Is that true?

We used to use QNX4 networking for the old lab,
since we move on to RtP, I would like to use the same thing.

Is that feasible ?

e.g.
ln -s file://4/home file://1/home

for instance.

Thank you!

Fred.

\

Jose_Luis · February 10, 2001, 10:22am

On Sat, 2001-02-10, “Fred” <fprog@users.sourceforge.net> wrote:

I wouldn’t even call QNET of Beta quality, it stinks compare to the
high-level
reliability of QNET for QNX4. I don’t know who designed/wrote
QNET for QNX4, but I would be surprise it’s the same person
that wrote it for RtP ?!

If you are talking about Qnet released in September 2000, I agree. But
the Patch A version is more stable. Not perfect, but definitely more stable.

I don’t know if QNX4 native networking and Qnet were developed by the
same or different people. It was surely developed on different hardware
(obviously Qnet on newer, faster CPUs). You may not notice a significative
difference in performance on current Pentium III machines, but on older
hardware (486s) QNX4’s native networking is a lot faster than Qnet.

Anyway, in my point of view, QNET for RtP should really go through
some severe modification in order to have all the usefulness
and all the fun and pleasure we had to use QNET similar network under QNX4.

If the issue is reliability, Qnet does not need radical changes. If the issue is
performance, I don’t know. And if it were so, may be the number of people using
embedded targets based on slow CPUs is not big enough to justify the cost of
a “severe modification”.

One last thing: even after Patch A, Qnet’s “global names” feature is still missing…

Saludos,

Jose Luis

Warren_Peece1 · February 12, 2001, 5:44pm

Give it some time. QNET addresses many issues prevalent with QNX4’s FLEET
networking, and seeing as how they’re developing it from scratch I’m not
surprised there are a few issues that need to be worked out. In the end I’m
certain they’ll have an extremely reliable, flexible implementation. This is
just my opinion, but I for one am glad they started over (ever seen a QNX4
network driver source?).