question about the hard realtime network!

hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

I learned that SBS’s Broadcast MEMORY and VMIC’s Reflective memory may
achieve hard realtime data transprotation among many nodes. But the bad
thing is that they have no Support Software under QNX platform.I don’t know
the difficult to write a driver by myself.

Does any one have such an experience or recommend a hardware that has the
QNX driver directly.

Thanks!


ycao

ycao,

I know about a company called Ziatech -now belongs to Intel-, has a
propietary design for multiprocesor applications (STD) 32 for fast
applications, and they also have QNX drivers, they are changing by now their
products but could have something interesting for you.

http://www.ziatech.com/

Regards

Oscar E. Soto

Control Adaptable SA de CV
Tel: +52 (81) 8340·0006
Fax: +52 (81) 8340·0014

“ycao” <ycao@mail.ipp.ac.cn> escribió en el mensaje
news:am7lkg$sni$1@inn.qnx.com

hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

I learned that SBS’s Broadcast MEMORY and VMIC’s Reflective memory may
achieve hard realtime data transprotation among many nodes. But the bad
thing is that they have no Support Software under QNX platform.I don’t
know
the difficult to write a driver by myself.

Does any one have such an experience or recommend a hardware that has the
QNX driver directly.

Thanks!


ycao

ycao wrote:

hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

Yes it is. I’ve done it. It might not be fast enough for some
particular application you have in mind, but it is predictable, and is
therefore hard real-time. Real-time, in general, has no relationship to
speed, only to predictability.

Rennie

Mario Charest wrote:

Ethernet with less then 2 computers connected via cross cable is in my
opinion not predictable from one computer point of view.

2 ethernet adapters, connected with a crossover cable, using a realtime
compatible network adapter (see below) running in full-duplex, is
deterministic:

packet time = memcpy to queue + memcpy to card + interrupt latency (on
B2B packets) + transmission time at given data rate + interrupt latency
at remote computer + scheduling latency at remote computer + memcpy from
card to queue + memcpy from queue to application buffer.

In order to evaluate whether the network adapter is realtime
“compatible”, you have to study the data sheet to make sure it doesn’t
do things like defer interrupts (a common practice, used to increase
throughput at the expense of latency). Certainly, putting together a
deterministic 2 node network using ethernet, is non-trivial, but it is
doable. Deterministic ethernet with more than 2 nodes, requires that the
switch must use a deterministic arbitration scheme, and that you know
what it is, and what its worst case latency is (in practice, this is
essentially impossible).

The basic problem to be overcome is not fleet, but the hardware.

Rennie

“ycao” <ycao@mail.ipp.ac.cn> wrote in message
news:ame1p8$hoq$1@inn.qnx.com

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3D8876FB.3000808@csical.com> …
ycao wrote:
hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

As Rennie said, speed as nothing to do with predicatbility nor realtime.


Yes it is. I’ve done it. It might not be fast enough for some
particular application you have in mind, but it is predictable, and is
therefore hard real-time. Real-time, in general, has no relationship to
speed, only to predictability.

Ethernet with less then 2 computers connected via cross cable is in my
opinion not predictable from one computer point of view.

Rennie


Predictable?

I test the performance of QNX’s message passing across the net with the
I/O output Card and the mutlti-channel oscillograph. The data of the
test
shows that most of the time the performace is stable , but it may be
worse
occasionally.

Well that is not a very good test, even with a predictable medium you may
get “unstable” througput, they are lots of variable to consider, like other
processes running on the machines.

The network card are 3C905B.That is i connect the nodes through Ethernet.
This may bring collision.

Depends how you configure the network.

I think that even i connect the nodes with the FDDI , the performence
may
become more predictable . But the average is not better than the
Ethernent ( Now the message is just 100bytes orso).

100 bytes is actually pretty bad since you are not using the full packet
size, hence you will NEVER get near the theoretical throughput. Each
ethernet packet has close to 30 bytes of overhead. Thus to send a packet of
100 bytes ethernet will have to send 130 bytes, that is not a very efficient
ratio. If you send 1500 bytes the 30 bytes overhead is far less
significant. If you want to reduce the handkshaking (thus likely hood of
collision) you can look at netraw or UPD and come up with a protocol
optimized for your application.

But I want the communication faster and stabler!

You can probably do so with shared memory type of devices, but these are a
LOT more expensive then networkcard. You are talking 3000$ US dollars here,
per card.

what is RapidIO?













\

Ethernet can only be deterministic if you can guarantee that there are NO
COLLISIONS!

How can you argue against that point.

“ycao” <ycao@mail.ipp.ac.cn> wrote in message
news:ame1p8$hoq$1@inn.qnx.com

“Rennie Allen” <> rallen@csical.com> > wrote in message
news:> 3D8876FB.3000808@csical.com> …
ycao wrote:
hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

Yes it is. I’ve done it. It might not be fast enough for some
particular application you have in mind, but it is predictable, and is
therefore hard real-time. Real-time, in general, has no relationship to
speed, only to predictability.

Rennie


Predictable?

I test the performance of QNX’s message passing across the net with the
I/O output Card and the mutlti-channel oscillograph. The data of the
test
shows that most of the time the performace is stable , but it may be
worse
occasionally.

The network card are 3C905B.That is i connect the nodes through Ethernet.
This may bring collision.

I think that even i connect the nodes with the FDDI , the performence
may
become more predictable . But the average is not better than the
Ethernent ( Now the message is just 100bytes orso).

But I want the communication faster and stabler!


what is RapidIO?













\

In QNX 4 I was able to avoid collisions in very busy networks by having 2
lans and using them both almost as half duplex.

There was a busy file server and many (about 60) workstation clients. By
futzing with the advertised media rate on the network drivers I was able to
force all outbound traffic from the file server onto Lan 1 and force all
outbound traffic from the clients onto Lan 2. Yet, in the event of a Lan
failure FLEET still worked quite nicely, routing ALL traffic through the one
remaining Lan. (BTW, for anyone trying this, in order for FLEET to work
well with two lans you must reduce the -n & -t parameters. Otherwise it
takes too long to fall over to the other An.)

When things got real busy there was a very noticeable improvement in
throughput over any other scheme that allowed many collisions, even with 2
lans.

How can I configure QNX 6 to behave similarly?

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:amfjsk$n45$1@inn.qnx.com

Ethernet can only be deterministic if you can guarantee that there are NO
COLLISIONS!

How can you argue against that point.

“Rennie Allen” <rallen@csical.com> wrote in message
news:3D8876FB.3000808@csical.com

ycao wrote:
hi,all,

I have a question here:

QNX’s message passing across the net isn’t fast enough to build a
predictable hard realtime net.

Yes it is. I’ve done it. It might not be fast enough for some
particular application you have in mind, but it is predictable, and is
therefore hard real-time. Real-time, in general, has no relationship to
speed, only to predictability.

Rennie

Predictable?

I test the performance of QNX’s message passing across the net with the
I/O output Card and the mutlti-channel oscillograph. The data of the test
shows that most of the time the performace is stable , but it may be worse
occasionally.

The network card are 3C905B.That is i connect the nodes through Ethernet.
This may bring collision.

I think that even i connect the nodes with the FDDI , the performence may
become more predictable . But the average is not better than the
Ethernent ( Now the message is just 100bytes orso).

But I want the communication faster and stabler!


what is RapidIO?

In our experience 2 LANs are great when there are no troubles but if 1 LAN
gets disconnected then you get close to periodic NET delays upwards to 10
seconds as NET tries to re-acquire the failed LAN. So much for the F in
FLEET.

Did you experience this Bill? Used -t2 -n2 by the way.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:amfkje$nrq$1@inn.qnx.com

In QNX 4 I was able to avoid collisions in very busy networks by having 2
lans and using them both almost as half duplex.

There was a busy file server and many (about 60) workstation clients. By
futzing with the advertised media rate on the network drivers I was able
to
force all outbound traffic from the file server onto Lan 1 and force all
outbound traffic from the clients onto Lan 2. Yet, in the event of a Lan
failure FLEET still worked quite nicely, routing ALL traffic through the
one
remaining Lan. (BTW, for anyone trying this, in order for FLEET to work
well with two lans you must reduce the -n & -t parameters. Otherwise it
takes too long to fall over to the other An.)

When things got real busy there was a very noticeable improvement in
throughput over any other scheme that allowed many collisions, even with 2
lans.

How can I configure QNX 6 to behave similarly?

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amfjsk$n45$> 1@inn.qnx.com> …
Ethernet can only be deterministic if you can guarantee that there are
NO
COLLISIONS!

How can you argue against that point.
\

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

In QNX 4 I was able to avoid collisions in very busy networks by having 2
lans and using them both almost as half duplex.

There was a busy file server and many (about 60) workstation clients. By
futzing with the advertised media rate on the network drivers I was able to
force all outbound traffic from the file server onto Lan 1 and force all
outbound traffic from the clients onto Lan 2. Yet, in the event of a Lan
failure FLEET still worked quite nicely, routing ALL traffic through the one
remaining Lan. (BTW, for anyone trying this, in order for FLEET to work
well with two lans you must reduce the -n & -t parameters. Otherwise it
takes too long to fall over to the other An.)

Interesting…

I image you could play the netmap, so that C → S have lan 1, and S → C
have lan 2.
But how do you make it works in the event of say lan 2 is down ? Didn’t
S lost all connections to C ? Or you dynamicly add C’s lan 1 Mac
address into S’s netmap ?

When things got real busy there was a very noticeable improvement in
throughput over any other scheme that allowed many collisions, even with 2
lans.

How can I configure QNX 6 to behave similarly?

Unfortunatly you can’t. The best it can do is 30 client on one
lan, and another 30 on another lan. (It seems possiable with
a little twick though).

Is this important these days ? Could a smart switch solve the
similar problem ?

-xtang



“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amfjsk$n45$> 1@inn.qnx.com> …
Ethernet can only be deterministic if you can guarantee that there are NO
COLLISIONS!

How can you argue against that point.

Well no. With one LAN out of commission and -t2 -n2 you should get an error
pretty quickly. If there was a 10 second something it sounds like it may
have been your application.

Admittedly, with -t2 -n2 there were a fair about of false errors. Our
applications was written to be forgiving enough for this though. Bottom
line was that the end result was better then without using -t2 -n2 AND you
eliminate all those damn collisions. Well except for cases of multiple
clients colliding with each other getting back to the server. Most of the
time our clients only spoke when spoken to. The unsolicited messages were
rare enough as to be essentially inconsequential.

“Brown, Richard” brownr_aecl_ca@127.0.0.1 wrote in message
news:amfpu7$r3p$1@inn.qnx.com

In our experience 2 LANs are great when there are no troubles but if 1 LAN
gets disconnected then you get close to periodic NET delays upwards to 10
seconds as NET tries to re-acquire the failed LAN. So much for the F in
FLEET.

Did you experience this Bill? Used -t2 -n2 by the way.

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amfkje$nrq$> 1@inn.qnx.com> …
In QNX 4 I was able to avoid collisions in very busy networks by having
2
lans and using them both almost as half duplex.

There was a busy file server and many (about 60) workstation clients.
By
futzing with the advertised media rate on the network drivers I was able
to
force all outbound traffic from the file server onto Lan 1 and force all
outbound traffic from the clients onto Lan 2. Yet, in the event of a
Lan
failure FLEET still worked quite nicely, routing ALL traffic through the
one
remaining Lan. (BTW, for anyone trying this, in order for FLEET to work
well with two lans you must reduce the -n & -t parameters. Otherwise it
takes too long to fall over to the other An.)

When things got real busy there was a very noticeable improvement in
throughput over any other scheme that allowed many collisions, even with
2
lans.

How can I configure QNX 6 to behave similarly?

“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:amfjsk$n45$> 1@inn.qnx.com> …
Ethernet can only be deterministic if you can guarantee that there are
NO
COLLISIONS!

How can you argue against that point.


\

Hi Xiaodan

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:amg057$2lj$1@nntp.qnx.com

Interesting…

I image you could play the netmap, so that C → S have lan 1, and S → C
have lan 2.
But how do you make it works in the event of say lan 2 is down ? Didn’t
S lost all connections to C ? Or you dynamicly add C’s lan 1 Mac
address into S’s netmap ?

This was with FLEET, not TCP/IP. The magic was QSSL’s not mine. Good work

guys. It required lying to the driver about the advertised media rate. If
one LAN was 10 times the speed of the other LAN Net would force (coerce,
persuade, whatever) all the traffic from Node X to Node Y through the faster
LAN even though they were both “up”.

But if one LAN was flagged as down, all traffic got routed through the only
available LAN. No media rate check was made (I assume). Anyway this is how
it was explained to me by the infamous Andrew Boyd. Boy I miss him.


How can I configure QNX 6 to behave similarly?

Unfortunatly you can’t. The best it can do is 30 client on one
lan, and another 30 on another lan. (It seems possiable with
a little twick though).

Is this important these days ? Could a smart switch solve the
similar problem ?

Sure it can. It just gets me. Once upon a time QSSL strove to me the best

and most efficient OS possible. Now the pat answer for almost everything is
throw hardware at it. Hardware is cheap enough. Well, hardware IS cheap
these days. But I’ve fallen out of love.

Don’t take it too personally. I’m still pretty impressed with QNX6
networking over QNX4. BUT . . . in QNX4 IPC across the net was completely
transparent (behaved identically to local IPC). IPC over the net in QNX6
does behave differently from local IPC.

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

Hi Xiaodan

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:amg057$2lj$> 1@nntp.qnx.com> …

Interesting…

I image you could play the netmap, so that C → S have lan 1, and S → C
have lan 2.
But how do you make it works in the event of say lan 2 is down ? Didn’t
S lost all connections to C ? Or you dynamicly add C’s lan 1 Mac
address into S’s netmap ?

This was with FLEET, not TCP/IP. The magic was QSSL’s not mine. Good work
guys. It required lying to the driver about the advertised media rate. If
one LAN was 10 times the speed of the other LAN Net would force (coerce,
persuade, whatever) all the traffic from Node X to Node Y through the faster
LAN even though they were both “up”.

But if one LAN was flagged as down, all traffic got routed through the only
available LAN. No media rate check was made (I assume). Anyway this is how
it was explained to me by the infamous Andrew Boyd. Boy I miss him.

Ah, the media rate trick. Yes, QNET also follow this rules.
If the media rate is very different, the “loadbalance” (the
default QOS) will only pick the fast one.

However, I am not sure how you can “lie” about media rate
on QNX6. Network drivers are quite sensitive about “rate
negotiation” these days.

By the way, you people who missed “ABOYD”, should be glad to
kown that he is back to QSS, and put his effort into QNET
right now :slight_smile: I will drag him into this group someday.

-xtang

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

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:amoeh8$dlv$> 1@nntp.qnx.com> …
By the way, you people who missed “ABOYD”, should be glad to
kown that he is back to QSS, and put his effort into QNET
right now > :slight_smile: > I will drag him into this group someday.


That is indeed great news. Welcome back Andrew!

Andrew is the one that got me involved in using QNX in the first place (V
2.15f). He spent 2 hours talking to me on the phone about it one day (my
dime on the phone call.) I knew without any doubt that he represented the
kind of company that I wanted to do business with. That and the fact that
after dealing with the stuffed shirts at IBM for 11 years, he was a welcome
change.

Are you the guy he said, “now, let’s turn to page 50, and read together, shall we?”
to? :slight_smile: :slight_smile:

Cheers,
-RK

Now, has anyone spoken to Bill Flowers lately? (Notice the long thread
about filesystem performance in the “advocacy” news group.)

Oh well, I can dream can’t I.


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.

“Xiaodan Tang” <xtang@qnx.com> wrote in message
news:amoeh8$dlv$1@nntp.qnx.com

By the way, you people who missed “ABOYD”, should be glad to
kown that he is back to QSS, and put his effort into QNET
right now > :slight_smile: > I will drag him into this group someday.

That is indeed great news. Welcome back Andrew!

Andrew is the one that got me involved in using QNX in the first place (V
2.15f). He spent 2 hours talking to me on the phone about it one day (my
dime on the phone call.) I knew without any doubt that he represented the
kind of company that I wanted to do business with. That and the fact that
after dealing with the stuffed shirts at IBM for 11 years, he was a welcome
change.

Now, has anyone spoken to Bill Flowers lately? (Notice the long thread
about filesystem performance in the “advocacy” news group.)

Oh well, I can dream can’t I.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:amq6io$as5$1@inn.qnx.com

“Xiaodan Tang” <> xtang@qnx.com> > wrote in message
news:amoeh8$dlv$> 1@nntp.qnx.com> …
Now, has anyone spoken to Bill Flowers lately? (Notice the long thread
about filesystem performance in the “advocacy” news group.)

Nope. Nobody wants to talk to me anymore. And all too often (for months at
a time) I’m too busy to even lurk in these groups. So unless someone sends
me an interrupt I completely miss these discussions.

Oh well, I can dream can’t I.

Yeah, like my dream of a life where I have time for fun and family (are they
separable?) without feeling like I’m ignoring my job. :frowning:


Bill Flowers
Clearwater, FL