Are there plans to make QNET cross platform?

[Armin_Steinhoff1]

Mario Charest wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0B643.7F2E45E2@web_.de…


Kevin Stallard wrote:

What would I do with PVM?

With PVM you would simply solve your problem in a convenient way >

huh? Can I do open(“/net/somewhere/dev/ser1”) with PVM?
Can I write a file on a different machine with open/read/write/close?

That’s not the focus of PVM.

I mean it does sound extremly usefull at user application level, but
it doesn’t solve the problem at the OS level.

I don’t see here problems at the OS level … the basic problme was
simple message passing between different CPU architectures, which is not
possible; not to talk about communication with QNX4 or other OSes.

Armin

[Armin_Steinhoff1]

Chris McKillop wrote:

What does QNX/QNET already? Does it allow communication between QNX6
systems with different CPU architectures? Does it allow communication
between QNX4 and QNX6 ??


It only doesn’t support communication between CPUs of different endians

Bad enough

I use qnet to stream audio from realplayer on my x86 PC to my iPaq (ARM)
over 802.11 all the time at home. Nice, portable, wireless internet radio. >
And once the resmgr layer is endian “aware” this won’t even be an issue.

Is QNET able to do broadcasting? (IP multicast .. )

Cheers

Armin

chris

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

[Mario_Charest1]

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE10268.1D471446@web_.de…

Mario Charest wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0B643.7F2E45E2@web_.de…


Kevin Stallard wrote:

What would I do with PVM?

With PVM you would simply solve your problem in a convenient way >

huh? Can I do open(“/net/somewhere/dev/ser1”) with PVM?
Can I write a file on a different machine with open/read/write/close?

That’s not the focus of PVM.

I mean it does sound extremly usefull at user application level, but
it doesn’t solve the problem at the OS level.

I don’t see here problems at the OS level …

I see a huge one, what if my program want to send data on the
serial port of a machine on the network that’s of different
endienness. My understanding of PVM is that it’s of no help
in these cases.

What if I want to spawn a file on another machine?
What if I want to get a list of processes on another machine.?
What if I want to kill a process on another node?

the basic problme was simple message passing between different
CPU architectures,

That’s not whas I understood from Kevin’s original post.

• Mario

[Kevin_Stallard1]

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0B643.7F2E45E2@web_.de…

Kevin Stallard wrote:

What would I do with PVM?

With PVM you would simply solve your problem in a convenient way >
Not hardly…I can’t start and stop process, I can’t open resources across

the net …It isn’t convient. QNET is lightyears ahead of it. No I can’t
talk to different OS’s, but I don’t care about that anyway.

It adds overhead to what QNX already does.

What does QNX/QNET already? Does it allow communication between QNX6
systems with different CPU architectures? Does it allow communication
between QNX4 and QNX6 ??

Nope!

I don’t care about different OS’s, I care about speed and flexibility..PVM
is none of these. It is a hack. Pure and simple hack and an excuse for IPC
that is both complex and relies upon a protocol that isn’t lightweight nor
easy to use. It relies on UDP…my understanding of UDP is that you can’t
even guarantee delivery of messages. UDP uses connectionless sockets. I
don’t need any more uncertanty in my systems.

I want lean and mean. PVM looks like an after-thought for the poor
blokes
that have to deal with MS and Linux > > .

No … I see here only a poor ‘bloke’ (?) which have to realize
communication between two QNX6 machines with different architectures > > )

Turns out QNET does this just fine…

QSSL didn’t make it an after thought and so it is faster.

PVM communication (after setup of a connection) is based on a lean and
secure UDP protocol. What is the base of QNET?? How could QNET be
faster??

Did you really ask those last two questions? You’re kidding right? How
could QNET be faster?

One thing it is not is a bloated, inflexible, complex, hard to use subset of
a even more bloated, hard to use complex protocol suite that everyone
happens to try to use for everything because they haven’t got any other
choice. I can open a any QNX resource on the net with one call?! Then I
get everything the entire TCP/IP suite pretends to be plus some. I can’t do
with TCP/IP+PVM what I can do with QNET. And don’t remind me again about
talking different OS’s. I’m not using different OS’s I don’t want to use
different OS’s. Besides TCP/IP requires a lot more configuration and
logistics supprot than QNET does. I just give QNET a hostname and
everything else is taken care of. TCP/IP requires IP address assignments,
and DNS support (through hosts file). QNET just requires a name. Talk
about simple.

BTW … are there implementation of QNET for shared memory systems,
Myrinet, Gigabit Ethernet or other communication media??

Not yet…but it isn’t very far away. devn.fd is a start, I can see a
devn.cpci being created…and I don’t imagine its that far away. QNET’s
predisesor was using a scsi driver in Zitech’s backplane to talk between
CPU’s…I can see QNET being used on a cPCI backplane. Eliminating the
need to manage the complexity of using shared memory over the PCI bus would
be a plus.

And I am not linking different OS’s.. I’m a QNX kind
of guy and all my systems (if I have anything to say about it) will and
will
always be QNX based…I just wanted to see if I could use a hybrid of
processors and link them via QNET.

Message passing by PVM allows to communicate between different operating
systems (QNX4-QNX6) and between system with different CPU architectures.

Both is until now NOT possible with QNET.

So what? I don’t want to use other OS’s…it can across CPU architectures
it turns out.

Ok, so there are more issues to the virtual machine concept than is
covered
by transparent IPC,

Wrong … there are at first library calls for transparent message
passing and based on it service calls for running the virtual machine.

but I would bet that making all CPU’s resources
transparent across the net is is 70% to 80% of that.

PVM is simply a system independent message passing library … plus
management function for the VM.

Yeah, I know…that’s all it is, thats why I don’t like it.

I do a pretty good job of managing parallel resources on my own, thank
you very much!

Oh .. thank you for your reply >

Further more, if I can avoid TCP/IP, I will.

So you should not use QNET > > )

What? How in the world is my dislike of TCP/IP in any way related to why I
then should not use QNET? How does that make sense?

I have what could be classified as an unfounded dislike of TCP/IP, but
I dislike it
none-the-less. I’m glad I have it so I can write this note, and post it
so
everyone can read. But I’m not going to use it as the main protocol for
any
multi CPU embedded system I design/write, unless that embedded system
needs
to talk across networks.

So PVM isn’t the answer…and thus my question remains.

> )

Cheers

Armin



Kevin

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CDFADF5.492B2669@web_.de…


Kevin Stallard wrote:

Hi 'yall,

I am under the impression that QNET isn’t currently able to speak to
QNX
nodes that are not of the same endianness.

PVM supports communication between nodes of different architectures
(endianness ..)

If this is true, is this going
to change? Seems a flag could be part of a QNET header in some way
indicating what order the data is in and do conversions only if
necessary
(unlike TCPIP where all traffic is put in netowrk byte order).

PVM is available at > http://www.sf.net/projects/openqnx

Cheers

Armin




Thanks,

Kevin

[Kevin_Stallard1]

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0BBE6.AD311964@web_.de…

Just to make it clear: QNET doesn’t support transparent message passing
between different CPU architectures!!

Yes it does. You can talk to a PPC from x86.

A clean implementation of transparent message passing between different
CPU architecture would be to convert the contens of the send buffers to
the ‘external data representation’ (RPC) if the architecture of the
receiver
is unknown.

Uhhmm…seems that TCP have these ntohs, ntohl, htons and htonl functions
that do this. If I use TCP/IP to talk to differnet CPU architectures, I
have to use these functions before I place binary data on the wire or take
it off the wire…how is that transparent?

Kevin

At the receiving site must be signaled that the received buffer comes
from a side with a different architecture, which means the buffer
contens should be in an ‘external data representation’.

Armin





The API I am talking about is the “endian_swap()” in
/usr/include/gulliver.h >
It pass in a pointer, a “structure instruction string”, maybe a length,
and return you a swapped structure…

I don’t envy the guy who has to keep that up to date?

I never though it through before, but I like the TCP/IP method of
putting
everything on the net in a predefined order much better than I did
yesterday.

Remember application suppose to not aware of local/remote satuation,
you almost suggest EVERY message send/receive/reply have to do that.

Even if we only do it on cross network case, for “same endian” nodes,
it is still a waste. Especially consider Little Endian talk to LE
node.

-xtang

[Bill_Caroselli_Q-TPS]

Bot it’s nice to see a heated argument where I’m not one of the people being
attacked.

I think you folks are arguing apples and oranges. First, let me say I
haven’t looked at PVM. But I think I get it.

QNET is useful to extend the OS to other CPUs. And it is the best (only?)
way to do that.

PVM is useful for sending data from one user written application to another
user written application on a different CPU.

I’m not a big fan of TCP. I think if I had to write a new application that
needed to talk to a non-QNX box I would look seriously at PVM.

On the other hand, I have used UDP extensively. I like the idea of a
defined packet size as opposed to a stream. And the issues of not being
“reliable” simply means that your application can not be COMPLETELY brain
dead. But let’s face it. Who does any kind of I/O without checking for
successful completion of the I/O operation. If I were writing an
application to communicate with another application through a serial port I
would still want the other application to ACK in some way each transmission.

OK. That’s my $0.0391 Canadian worth.

[Bill_Caroselli_Q-TPS]

What is XDR?

“Rennie Allen” <rallen@csical.com> wrote in message
news:3CE0D9B4.6090704@csical.com…

Firstly, I agree that QNET is light-years ahead of PVM; however, Armin
was refering to XDR which is a more complete solution to endianess

[Sean_Boudreau1]

External data representation. RFC1832. Used by RPC, for example.

-seanb

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:
: What is XDR?

: “Rennie Allen” <rallen@csical.com> wrote in message
: news:3CE0D9B4.6090704@csical.com…
:>
:> Firstly, I agree that QNET is light-years ahead of PVM; however, Armin
:> was refering to XDR which is a more complete solution to endianess

[Bill_Caroselli_Q-TPS]

Thank you.

“Sean Boudreau” <seanb@qnx.com> wrote in message
news:abrkak$qju$1@nntp.qnx.com…

External data representation. RFC1832. Used by RPC, for example.

: What is XDR?

[Armin_Steinhoff1]

Kevin Stallard wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0B643.7F2E45E2@web_.de…


Kevin Stallard wrote:

What would I do with PVM?

With PVM you would simply solve your problem in a convenient way >
Not hardly…I can’t start and stop process,

Wrong … you can start and stop processes dynamically

I can’t open resources across the net

True ..

…It isn’t convient.

It depends on your concrete needs … but you have not to use it

QNET is lightyears ahead of it.

BTW … PVM has a development history of ~10 years.

No I can’t talk to different OS’s, but I don’t care about that anyway.


It adds overhead to what QNX already does.

What does QNX/QNET already? Does it allow communication between QNX6
systems with different CPU architectures? Does it allow communication
between QNX4 and QNX6 ??

Nope!

I don’t care about different OS’s, I care about speed and flexibility..PVM
is none of these. It is a hack. Pure and simple hack and an excuse for IPC
that is both complex and relies upon a protocol that isn’t lightweight nor
easy to use. It relies on UDP…my understanding of UDP is that you can’t
even guarantee delivery of messages. UDP uses connectionless sockets. I
don’t need any more uncertanty in my systems.

It’s hard to take your statements seriously
You now what ‘secure UDP (based) protocol’ means?

I want lean and mean. PVM looks like an after-thought for the poor
blokes
that have to deal with MS and Linux > > .

No … I see here only a poor ‘bloke’ (?) which have to realize
communication between two QNX6 machines with different architectures > > )

Turns out QNET does this just fine…

OK … tell me what is the root of that discussion?

QSSL didn’t make it an after thought and so it is faster.

PVM communication (after setup of a connection) is based on a lean and
secure UDP protocol. What is the base of QNET?? How could QNET be
faster??

Did you really ask those last two questions? You’re kidding right? How
could QNET be faster?

One thing it is not is a bloated, inflexible, complex, hard to use subset of
a even more bloated, hard to use complex protocol suite that everyone
happens to try to use for everything because they haven’t got any other
choice. I can open a any QNX resource on the net with one call?! Then I
get everything the entire TCP/IP suite pretends to be plus some. I can’t do
with TCP/IP+PVM what I can do with QNET. And don’t remind me again about
talking different OS’s. I’m not using different OS’s I don’t want to use
different OS’s. Besides TCP/IP requires a lot more configuration and
logistics supprot than QNET does. I just give QNET a hostname and
everything else is taken care of. TCP/IP requires IP address assignments,
and DNS support (through hosts file). QNET just requires a name.

I never heard that the global name space of QNET is working.

Talk about simple.

However … I never heard such nonsens about a cluster middleware (PVM)
which support up to 192 systems for fast parallel computing.

Ok … forget my proposal. If QNET is great for you … use it

But try to avoid to make statements about technologies you don’t know.

And BTW … QNET is only a product and it must be possible to compare it
with other solutions and discuss its strenght and weaknesses in a
rational way

Cheers

Armin

[Armin_Steinhoff1]

“Bill Caroselli (Q-TPS)” wrote:

Bot it’s nice to see a heated argument where I’m not one of the people being
attacked.

As you know Bill … there is a life before and after QNET

I think you folks are arguing apples and oranges. First, let me say I
haven’t looked at PVM. But I think I get it.

PVM has really nice concepts .. but it is now ~10 years ‘young’
It would be nice if QNET could use some concepts of HARNESS, the
follow-up system of PVM.

Armin

QNET is useful to extend the OS to other CPUs. And it is the best (only?)
way to do that.

PVM is useful for sending data from one user written application to another
user written application on a different CPU.

I’m not a big fan of TCP. I think if I had to write a new application that
needed to talk to a non-QNX box I would look seriously at PVM.

On the other hand, I have used UDP extensively. I like the idea of a
defined packet size as opposed to a stream. And the issues of not being
“reliable” simply means that your application can not be COMPLETELY brain
dead. But let’s face it. Who does any kind of I/O without checking for
successful completion of the I/O operation. If I were writing an
application to communicate with another application through a serial port I
would still want the other application to ACK in some way each transmission.

OK. That’s my $0.0391 Canadian worth.

[Armin_Steinhoff1]

Rennie Allen wrote:

Kevin Stallard wrote:

Uhhmm…seems that TCP have these ntohs, ntohl, htons and htonl functions
that do this. If I use TCP/IP to talk to differnet CPU architectures, I
have to use these functions before I place binary data on the wire or take
it off the wire…how is that transparent?

Firstly, I agree that QNET is light-years ahead of PVM;

That’s really brave But what’s the base of your opinion?

however, Armin
was refering to XDR which is a more complete solution to endianess
problems than anything I have heard planned for QNET at this point (it
has a standardized meta language that describes the format of the data -
but does assume little endian within an octet - which is XDR’s
concession to efficiency).

The use of XDR is also optional with PVM …

That said, I’m with you and I think the
overhead of XDR’s more generalized solution would be inappropriate for
IPC in an operating system like QNX where lean and mean is the order of
the day.

So it should only be used when it is neccessary … se above.

One can always use XDR to communicate outside of the QNX
“computer” (where the QNX “computer” can be more than 1 node of
differing processor types).

That was the initial issue … when I remember rigth.

Cheers

Armin

Rennie

[Armin_Steinhoff1]

Hi Mario,

Mario Charest wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE10268.1D471446@web_.de…


Mario Charest wrote:

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CE0B643.7F2E45E2@web_.de…


Kevin Stallard wrote:

What would I do with PVM?

With PVM you would simply solve your problem in a convenient way >

huh? Can I do open(“/net/somewhere/dev/ser1”) with PVM?
Can I write a file on a different machine with open/read/write/close?

That’s not the focus of PVM.

I mean it does sound extremly usefull at user application level, but
it doesn’t solve the problem at the OS level.

I don’t see here problems at the OS level …

I see a huge one, what if my program want to send data on the
serial port of a machine on the network that’s of different
endienness.

You are showing a strength of QNET and at the same time
a big weakness.

My understanding of PVM is that it’s of no help in these cases.

Not directly … you could use a message handler which does the ‘local’
actions (open, R/W) on another ‘physical host’. Not a big issue ..

What if I want to spawn a file on another machine?

pvm_spawn → on a default host (on any arbitrary host), on a special
architecture(x86, PPC,..) or on a defined host (e.g. listed in
/etc/hosts)

BTW, there is ‘no other machine’ … you have a ‘single logical machine’

What if I want to get a list of processes on another machine.?

pvm_gettid, pvm_mytid, pvm_getinst (also pvm_bufinfo) … related to a
named ‘task group’ (member of a task group can be hosted on different
machines .. single logical machine)

What if I want to kill a process on another node?

pvm_kill(tid) … it doesn’t matter where the task is running ..

the basic problme was simple message passing between different
CPU architectures,

That’s not whas I understood from Kevin’s original post.

OK … take it easy

Armin

[Rennie_Allen2]

Armin Steinhoff wrote:

That’s really brave > > But what’s the base of your opinion?

Oh I don’t know if it’s that brave… this is a NG hosted at qnx.com
after all; perhaps if this was on the PVM group it might be considered
brave

Well, there is one basic attribute of PVM that makes it completely
useless for anything I would ever undertake, and that is, that it does
not (and can not, in an efficient manner) preserve message priority
across nodes.

There are many other respects in which QNET is far better, most of which
have been covered by other posters.

Rennie

[Armin_Steinhoff1]

Rennie Allen wrote:

Armin Steinhoff wrote:

That’s really brave > > But what’s the base of your opinion?

Oh I don’t know if it’s that brave… this is a NG hosted at qnx.com
after all; perhaps if this was on the PVM group it might be considered
brave >

Well, there is one basic attribute of PVM that makes it completely
useless for anything I would ever undertake, and that is, that it does
not (and can not, in an efficient manner) preserve message priority
across nodes.

The message tag can be used to prioritize messages (at application
level).

There are many other respects in which QNET is far better,

First of all … PVM isn’t against QNET! (Sounds like you are a little
bit 'obsessed ) You are also comparing completely different concepts.

PVM is an application layer LIBRARY and not a network API!

The definition of PVM isn’t bound to a specific network media. The
version available at ‘openqnx’ is just a version which is based on
TCP/IP (UDP) … and this version is directly useable FOR QNX.

It is also possible to use the PVM for different media like shared
memory, myrinet, cross bar switches und of course for QNET.

An implementation of PVM which is using native message passing of QNX
and QNET is on my to-do list

But you have not to use it … even it is based on QNET

most of which have been covered by other posters.

I have no idea why they believe that they have to argue angainst PVM …
it’s just a piece of useful software FOR QNX.

Armin

[Kris_Warkentin1]

“Armin Steinhoff” <a-steinhoff@web_.de> wrote in message
news:3CEA34A9.A29EDA92@web_.de…

First of all … PVM isn’t against QNET! (Sounds like you are a little
bit 'obsessed > > ) You are also comparing completely different concepts.
^^^^^^^

Well done Armin old chap. Very witty. applause

Kris “wishes he had gotten to use it first” Warkentin