advice please!

QNX Newsgroups (Archives) qdn.public.qnxrtp.advocacy
1

hi,all

We will build a conrtol system ,and the demand of the realtimeness and
stability is very high.The system consists of 20 industrial PCs,
which will be connected by network adapter.(however,it maybe
unreasonable,but we have no enough money,and want tomake a try ) The control
cycle time is about 1.3 milliscend,that is we have only 1.3 milliscend to
transfer data from one node to others,inluding the date processing on every
nodes.It must be mentioned that the data transfered from one node to others
is about 20 bytes every time.Among the control cycle time the transfer frome
one node to another may happen 20 times,and some of them can be paralleled.


We choose QNX as the OS for the control system above.But as a greenhand i
can’t conclude that QNX will be fit for the system.So i wish you give me a
hint and help me out .Give me any advice will be good.

Thank you beforehand!

2

“ycao” <ycao@mail.ipp.ac.cn> wrote in message
news:9ehvn0$psc$1@inn.qnx.com…

hi,all

We will build a conrtol system ,and the demand of the realtimeness and
stability is very high.The system consists of 20 industrial PCs,
which will be connected by network adapter.(however,it maybe
unreasonable,but we have no enough money,and want tomake a try ) The
control
cycle time is about 1.3 milliscend,that is we have only 1.3 milliscend to
transfer data from one node to others,inluding the date processing on
every
nodes.It must be mentioned that the data transfered from one node to
others
is about 20 bytes every time.Among the control cycle time the transfer
frome
one node to another may happen 20 times,and some of them can be
paralleled.

First issue, 1.3 millisecond is and odd time. That means unless you got

some extra
hardware to generate a interrupt every 1.3 millisecons you may only be able
to
loop every 1.5 ms 1 ms or 500 us (500 us is the small resolution for timed
event).
But in general 1ms cycle is not really a problem (although some precaution
are required)

As for sending 20 bytes every 1ms on a network that should not be a problem,
that
equals to 20k/sec per nodes, times 20 nodes if they all send at the same
time to each other that’s
400k/sec. On 10mbits it could be tight but 100mbits shouldn’t have any
problem.
However beware, a network with 20 PC is not very deterministic, it may be
very difficult if not
impossible to guaranty 100% success. That doesn’t have anything to do with
QNX but rather it’s the nature of Ethernet.

We choose QNX as the OS for the control system above.But as a greenhand
i
can’t conclude that QNX will be fit for the system.So i wish you give me a
hint and help me out .Give me any advice will be good.

Thank you beforehand!












\

3

“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9eiu8c$flf$1@inn.qnx.com…

As for sending 20 bytes every 1ms on a network that should not be a
problem,
that
equals to 20k/sec per nodes, times 20 nodes if they all send at the same
time to each other that’s
400k/sec. On 10mbits it could be tight but 100mbits shouldn’t have any
problem.
However beware, a network with 20 PC is not very deterministic, it may be
very difficult if not
impossible to guaranty 100% success. That doesn’t have anything to do
with
QNX but rather it’s the nature of Ethernet.

With 20 transmitters trying to put out a packet every 1 ms collisions are
going to kill you. It doesn’t matter how little data there is in each
packet. Also, don’t forget to add in size of headers for each packet.

As Mario said, it isn’t QNX that’s the problem, its Ethernet. In this one
situation I can say that Ethernet IS deterministic. I can determin that
before you even try it, it won’t work on 10 Mbps Ethernet. You can probibly
get away with it on 100 Mbps Ethernet. But with so many transmitters
transmitting so often and regurally I would recommend trying 16 Mbps token
ring instead.

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122

4

ycao wrote:

hi,all

We will build a conrtol system ,and the demand of the realtimeness and
stability is very high.The system consists of 20 industrial PCs,
which will be connected by network adapter.(however,it maybe
unreasonable,but we have no enough money,and want tomake a try ) The control
cycle time is about 1.3 milliscend,that is we have only 1.3 milliscend to
transfer data from one node to others,inluding the date processing on every
nodes.It must be mentioned that the data transfered from one node to others
is about 20 bytes every time.Among the control cycle time the transfer frome
one node to another may happen 20 times,and some of them can be paralleled.

We choose QNX as the OS for the control system above.But as a greenhand i
can’t conclude that QNX will be fit for the system.So i wish you give me a
hint and help me out .Give me any advice will be good.

As Mario and Bill already mentioned the problem isn’t QNX … it’s
Ethernet !

An alternative network could be PROFIBUS (an industrial fieldbus)
at a speed at 12Mb/s. The communication should be done at DP-level
using one computer as a network master and the rest working as
slaves.

The polling time with 19 slaves is in the range of 200-300
microseconds … so it must be possible that all slaves can
communicate to each others in the time frame of 1ms.

Fieldbuses are designed for fast responses …

Armin

http://www.steinhoff-automation.com

5

“Bill Caroselli” <Bill@Sattel.com> wrote in message
news:9ejat8$nn8$1@inn.qnx.com…

“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9eiu8c$flf$> 1@inn.qnx.com> …
As for sending 20 bytes every 1ms on a network that should not be a
problem,
that
equals to 20k/sec per nodes, times 20 nodes if they all send at the same
time to each other that’s
400k/sec. On 10mbits it could be tight but 100mbits shouldn’t have any
problem.
However beware, a network with 20 PC is not very deterministic, it may
be
very difficult if not
impossible to guaranty 100% success. That doesn’t have anything to do
with
QNX but rather it’s the nature of Ethernet.


With 20 transmitters trying to put out a packet every 1 ms collisions are
going to kill you. It doesn’t matter how little data there is in each
packet. Also, don’t forget to add in size of headers for each packet.


As Mario said, it isn’t QNX that’s the problem, its Ethernet. In this one
situation I can say that Ethernet IS deterministic. I can determin that
before you even try it, it won’t work on 10 Mbps Ethernet. You can
probibly
get away with it on 100 Mbps Ethernet. But with so many transmitters
transmitting so often and regurally I would recommend trying 16 Mbps token
ring instead.

I though token ring wasn’t availabe on QNX6? If it would, i guess
it would be more expensive (from the original post cost seems to
be a concern).

One option (if possible) would be to have one node poll all the other to
prevent
collision.

One other possibility would be to use broadcast that way each nodes
wouldn’t have to send the data 20 times to every other nodes. Also with
broadcast you may be able to reduce collision by cascading the broadcast:
node 1 send the data when node 2 received it it send it, when node 3
received
it it sends it, etc…

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122


\

6

Mario Charest <mcharest@antispam_zinformatic.com> wrote:

“Bill Caroselli” <> Bill@Sattel.com> > wrote in message
news:9ejat8$nn8$> 1@inn.qnx.com> …
“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9eiu8c$flf$> 1@inn.qnx.com> …
As for sending 20 bytes every 1ms on a network that should not be a
problem,
that
equals to 20k/sec per nodes, times 20 nodes if they all send at the same
time to each other that’s
400k/sec. On 10mbits it could be tight but 100mbits shouldn’t have any
problem.
However beware, a network with 20 PC is not very deterministic, it may
be
very difficult if not
impossible to guaranty 100% success. That doesn’t have anything to do
with
QNX but rather it’s the nature of Ethernet.


With 20 transmitters trying to put out a packet every 1 ms collisions are
going to kill you. It doesn’t matter how little data there is in each
packet. Also, don’t forget to add in size of headers for each packet.


As Mario said, it isn’t QNX that’s the problem, its Ethernet. In this one
situation I can say that Ethernet IS deterministic. I can determin that
before you even try it, it won’t work on 10 Mbps Ethernet. You can
probibly
get away with it on 100 Mbps Ethernet. But with so many transmitters
transmitting so often and regurally I would recommend trying 16 Mbps token
ring instead.

I though token ring wasn’t availabe on QNX6? If it would, i guess
it would be more expensive (from the original post cost seems to
be a concern).

Right, there are no plans at this time to support token ring on QNX6…

Chris

One option (if possible) would be to have one node poll all the other to
prevent
collision.

One other possibility would be to use broadcast that way each nodes
wouldn’t have to send the data 20 times to every other nodes. Also with
broadcast you may be able to reduce collision by cascading the broadcast:
node 1 send the data when node 2 received it it send it, when node 3
received
it it sends it, etc…

\

Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122


\

7

You can do this with Ethernet, however, it will be very expensive. In
order to get determinism from Ethernet it would be necessary to have
each PC have 20 ethernet cards (20 cards should be possible with a
combination of PCI and USB ethernet cards). Ethernet is only
deterministic in a point to point configuration,. USB is deterministic
in a multi-point configuration so using USB as the bus for ethernet
adapters will work.

You would need to wire the system like this

1
20 --/|-- 2
19 --|\ / | \ /|-- 3
18–|/\ \ | / /|–4
17+/\ \ \ | / / //+5
16-----------------------6
15+// / / | \ \ /+7
14–|/ / | \ /|–8
13–|/ \ | / |–9
12–|/–10
11

Obviously, I can’t show all the connections in ASCII graphics, but you
get the idea (each machine has a point to point connection with each
other machine).

Now, if the above seems ridiculous, I agree, and if you are using QNX6
you better off using a deterministic network (20 Mbit arcnet would be
ideal, if you can find the hardware, you would then need to write a
20Mbit arcnet driver for Qnet - QSSL should be able to supply just about
everything you need to do this, as they support 20Mbit arcnet on QNX4).
Note, however, that you system may not meet the 1.3 millisecond deadline
during a bus reconfiguration cycle on 20Mbit arcnet, which, if memory
serves, is about 5ms (i.e. your system may not work during the time when
nodes are being taken off-line or brought on-line - this may - or may
not - be a problem for you - and can be solved by having dual networks).

Another important point is that you will want to use QNX native
networking, as TCP/IP does not carry kernel level priority information
and is therefore unsuitable for distributed real-time systems (i.e.
priority inversion can - and will - occur on a system-wide basis).

Right now (given the maturity of QNX6 wrt deterministic networking) I
would suggest using QNX4. Given the right networking hardware your
project would be easily doable in QNX4 (in fact there simply isn’t a
better O/S in the world for doing what you want to do).

-----Original Message-----
From: ycao [mailto:ycao@mail.ipp.ac.cn]
Posted At: Wednesday, May 23, 2001 8:40 PM
Posted To: advocacy
Conversation: advice please!
Subject: advice please!


hi,all

We will build a conrtol system ,and the demand of the realtimeness
and
stability is very high.The system consists of 20 industrial PCs,
which will be connected by network adapter.(however,it maybe
unreasonable,but we have no enough money,and want tomake a try ) The
control
cycle time is about 1.3 milliscend,that is we have only 1.3 milliscend
to
transfer data from one node to others,inluding the date processing on
every
nodes.It must be mentioned that the data transfered from one node to
others
is about 20 bytes every time.Among the control cycle time the transfer
frome
one node to another may happen 20 times,and some of them can be
paralleled.


We choose QNX as the OS for the control system above.But as a
greenhand i
can’t conclude that QNX will be fit for the system.So i wish you give me
a
hint and help me out .Give me any advice will be good.

Thank you beforehand!

8

“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9ejhoc$s2p$1@inn.qnx.com…

“Bill Caroselli” <> Bill@Sattel.com> > wrote in message
news:9ejat8$nn8$> 1@inn.qnx.com> …
“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9eiu8c$flf$> 1@inn.qnx.com> …
As for sending 20 bytes every 1ms on a network that should not be a
problem,
that
equals to 20k/sec per nodes, times 20 nodes if they all send at the
same
time to each other that’s
400k/sec. On 10mbits it could be tight but 100mbits shouldn’t have
any
problem.
However beware, a network with 20 PC is not very deterministic, it may
be
very difficult if not
impossible to guaranty 100% success. That doesn’t have anything to do
with
QNX but rather it’s the nature of Ethernet.


With 20 transmitters trying to put out a packet every 1 ms collisions
are
going to kill you. It doesn’t matter how little data there is in each
packet. Also, don’t forget to add in size of headers for each packet.


As Mario said, it isn’t QNX that’s the problem, its Ethernet. In this
one
situation I can say that Ethernet IS deterministic. I can determin that
before you even try it, it won’t work on 10 Mbps Ethernet. You can
probibly
get away with it on 100 Mbps Ethernet. But with so many transmitters
transmitting so often and regurally I would recommend trying 16 Mbps
token
ring instead.

I though token ring wasn’t availabe on QNX6? If it would, i guess
it would be more expensive (from the original post cost seems to
be a concern).

One option (if possible) would be to have one node poll all the other to
prevent
collision.

One other possibility would be to use broadcast that way each nodes
wouldn’t have to send the data 20 times to every other nodes. Also with
broadcast you may be able to reduce collision by cascading the broadcast:
node 1 send the data when node 2 received it it send it, when node 3
received
it it sends it, etc…

How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and 10mb/s
would be enough…

  • igor
9

How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and
10mb/s
would be enough…

This is a common misunderstanding. Any system where there is a shared
medium (in the case of the switch it is the switch fabric), has
contention (not collisions, true, but effectively the same from a
determinism standpoint), and therefore requires an arbitration
mechanism. What separates a deterministic network from a non
deterministic network is not the absence of contention (there is always
contention) but a standard time-bounded method for resolving contention
for all possible states in the system. If someone published a
“deterministic Ethernet switch specification” with bounded contention
resolution, then Ethernet would be deterministic (I have heard that
there is work being done in this direction).

I suspect that you are correct in saying that a switch would work, but
I can’t say for sure, and being able to say for sure is very important
when talking determinism. I don’t know who’s switch your using, and most
switch vendors don’t publish their internal arbitration scheme, and it’s
latencies. The PCI bus on your computer has contention, but in the case
of PCI, latency timers are tunable. Even with tunable latency timers
getting the required determinism out of the bus can sometimes prove
challenging for naive users. With vendor X’s switch and no idea (or
control of) what’s happening inside, you would be unable to guarantee
worst case switch fabric contention latencies.

Rennie

10

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.advocacy:

How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and 10mb/s
would be enough…

Note that store and forward switches will increase the latency.



Mitchell Schoenbrun --------- maschoen@pobox.com

11

Rennie Allen wrote:

You can do this with Ethernet, however, it will be very expensive. In
order to get determinism from Ethernet it would be necessary to have
each PC have 20 ethernet cards (20 cards should be possible with a
combination of PCI and USB ethernet cards).

Weird idea =:-/

Ethernet is only
deterministic in a point to point configuration,

No … it depends on the media side. If you use an Ethernet switch
with 20 ports this configuration will be working deterministic (if
you don’t consider some effects caused by the 'priority queueing).

. USB is deterministic
in a multi-point configuration so using USB as the bus for ethernet
adapters will work.

USB is in no way deterministic.

[ graphic clipped ]

Obviously, I can’t show all the connections in ASCII graphics, but you
get the idea (each machine has a point to point connection with each
other machine).

Now, if the above seems ridiculous, I agree,

… ditto!!

and if you are using QNX6
you better off using a deterministic network (20 Mbit arcnet would be
ideal, if you can find the hardware, you would then need to write a
20Mbit arcnet driver for Qnet - QSSL should be able to supply just about
everything you need to do this, as they support 20Mbit arcnet on QNX4).
Note, however, that you system may not meet the 1.3 millisecond deadline
during a bus reconfiguration cycle on 20Mbit arcnet, which, if memory
serves, is about 5ms

AFAIK … the time of the reconfiguration can be in the range of
seconds. And it is done by the ARCnet chip and can’t be controlled
by software!

(i.e. your system may not work during the time when
nodes are being taken off-line or brought on-line - this may - or may
not - be a problem for you - and can be solved by having dual networks).

The reconfiguration happens always if the token get lost … because
of switching a station on/off and cabling problems (sometimes
realy a nightmare…).

Another important point is that you will want to use QNX native
networking, as TCP/IP does not carry kernel level priority information
and is therefore unsuitable for distributed real-time systems (i.e.
priority inversion can - and will - occur on a system-wide basis).

Right now (given the maturity of QNX6 wrt deterministic networking) I
would suggest using QNX4.

Hm, think twice … in the case of QNX4 you will get ARCnet, but you
will loose a lot other nice things (thread support, DLL support
a.s.o )

However … also a good solution would be to use reflective memory
interfaces in a star configuration, but more cost effective is a
PROFIBUS based solution. With PROFIBUS you can switch on and off
work stations with no negative effects on the communication.

Armin

12

Igor Kovalenko wrote:

“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9ejhoc$s2p$> 1@inn.qnx.com> …

[…]

One other possibility would be to use broadcast that way each nodes
wouldn’t have to send the data 20 times to every other nodes. Also with
broadcast you may be able to reduce collision by cascading the broadcast:
node 1 send the data when node 2 received it it send it, when node 3
received
it it sends it, etc…


How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and 10mb/s
would be enough…

Yes … switches are collision free, but the remainig problem is the
‘802.1p priority queueing’ … that means a very active port with a
high priority can kill the determinismn of the communication.

Armin

13

“Rennie Allen” <RAllen@csical.com> wrote in message
news:D4907B331846D31198090050046F80C904A3E5@exchangecal.hq.csical.com…

How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and
10mb/s
would be enough…

This is a common misunderstanding. Any system where there is a shared
medium (in the case of the switch it is the switch fabric), has
contention (not collisions, true, but effectively the same from a
determinism standpoint), and therefore requires an arbitration
mechanism. What separates a deterministic network from a non
deterministic network is not the absence of contention (there is always
contention) but a standard time-bounded method for resolving contention
for all possible states in the system.

You mean that switch can’t pass traffic from every port to every other port
at the same time? Aren’t there fully-meshed switches, or they are called
differently?

If there aren’t, look at this. Motorola makes a cPCI chassis with fully
meshed 100Mb/s ethernet backplane, all you need to do is insert SBCs with
built-in ethernet (I think that chassis takes up to 16 SBCs) and they can
talk to each other all at the same time. It is called PXP1000 and also has
two gigabit ethernet ports.

Of course there’s contention if 19 nodes all send packets to 1, but with
short packets (we’re talking 20 bytes here) they would all fit into NIC’s
receive buffer and as long as they can be all sucked up in one cycle there
should not be a problem.

If someone published a
“deterministic Ethernet switch specification” with bounded contention
resolution, then Ethernet would be deterministic (I have heard that
there is work being done in this direction).

I believe 100VG-Anylan is deterministic. And I think Corman sells hardware
with QNX drivers.
Purists will of course tell that it is not ethernet.

I suspect that you are correct in saying that a switch would work, but
I can’t say for sure, and being able to say for sure is very important
when talking determinism. I don’t know who’s switch your using, and most
switch vendors don’t publish their internal arbitration scheme, and it’s
latencies. The PCI bus on your computer has contention, but in the case
of PCI, latency timers are tunable. Even with tunable latency timers
getting the required determinism out of the bus can sometimes prove
challenging for naive users. With vendor X’s switch and no idea (or
control of) what’s happening inside, you would be unable to guarantee
worst case switch fabric contention latencies.

I would think that switches are either store-and-forward in which case they
compensate insufficient switching fabric with memory, or fully meshed. Does
anyone know better?

  • Igor
14

“Mario Charest” <mcharest@antispam_zinformatic.com> wrote in message
news:9ejhoc$s2p$1@inn.qnx.com…

I though token ring wasn’t availabe on QNX6? If it would, i guess
it would be more expensive (from the original post cost seems to
be a concern).

OK. I wasn’t aware of that. I don’t use it. I just assumed that they had
ported at least some of their TR drivers by now.

One option (if possible) would be to have one node poll all the other to
prevent collision.

One other possibility would be to use broadcast that way each nodes
wouldn’t have to send the data 20 times to every other nodes. Also with
broadcast you may be able to reduce collision by cascading the broadcast:
node 1 send the data when node 2 received it it send it, when node 3
received it it sends it, etc…

WOW. Did I misunderstand the original post. I thought that 20 nodes would
send a packet every ms. If 20 nodes are sending a packet to 19 other nodes
every ms, then all bets really are off. Unless as Mario says, you use
broadcast packets.

The idea of implementing a token in software isinteresting and could work.
Now this is where realtime software really comes in. You have to keep those
turn around latencies way down.

Here is a method that I used in QNX 4 when there where many Ethernet
transmitters. It assumes that one node is functioning as a file/data
server. All nodes have two lans. On each node you adjust the advertised
media rate of each lan so that all inbound traffic to the server is on one
lan and all outbound traffic from the server is on the other lan.

I don’t know if RTP lets you play with advertised media rates to perfer one
route over another. In fact, I’m not sure that RTP will allow multiple
routes to other nodes. Since all RTP traffic sits on top of IP, I don’t
know how you play with the routing tables. I guess that each node would
have to address its packets to the appropriate interface IP address. That’s
a bummer because it puts the burdon on the application rather than the OS.

Good luck.

\

Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122

15

USB is in no way deterministic.

USB has deterministic modes of operation (Isochronous modes).

AFAIK … the time of the reconfiguration can be in the range of
seconds. And it is done by the ARCnet chip and can’t be controlled

by software!

No, not seconds. On 2.5Mbit Arcnet it was in the range of 10’s of
milliseconds. This was improved for 20Mbit Arcnet and, I believe, it is
in the single digits.

The reconfiguration happens always if the token get lost … because
of switching a station on/off and cabling problems (sometimes

realy a nightmare…).

Determinism is independant of fault tolerance. How the system reacts
during a cable fault is outside the scope of a discussion on
deterministic networks.

Hm, think twice … in the case of QNX4 you will get ARCnet, but you
will loose a lot other nice things (thread support, DLL support

a.s.o )

What is most important, reliable distributed real-time behavior, or the
latest, current fashion, me-too features ?

However … also a good solution would be to use reflective memory
interfaces in a star configuration, but more cost effective is a

PROFIBUS based solution. With PROFIBUS you can switch on and off
work stations with no negative effects on the communication.

Profibus is token passing just like Arcnet, and suffers bus
reconfigurations in exactly the same way (although the time may be
smaller, do you know what it is ?).

16

“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9ejqt1$4a7$1@inn.qnx.com…

How about to use a 20-port switch?
I thought switched full duplex ethernet does not have collisions and
10mb/s
would be enough…

That could work.

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122

17

“Rennie Allen” <RAllen@csical.com> wrote in message

[lots-o-good-stuff deleted]

What he said! What are the risks of being “late” say only occasionally. I
would write an applicatino that just transmits garbage packets at a rate
similar to what you expect your real application to write. And run an hour
long test. Even if everything is perfect, there is no guarantee that it
will always be perfect. However, I would say thaht an hour is long enough
to get an idea of what life would be like 99.9% of the time. If you can
live with the results, you have a solution.

Here’s a possible second step. Gradually decrease the period until your
system does finally fall on its face. Add back in a liberal difference.
That should show you just what your configuration is capable of.

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122

18

“Igor Kovalenko” <kovalenko@home.com> wrote in message
news:9ekam6$dae$1@inn.qnx.com…

If there aren’t, look at this. Motorola makes a cPCI chassis with fully
meshed 100Mb/s ethernet backplane, all you need to do is insert SBCs with
built-in ethernet (I think that chassis takes up to 16 SBCs) and they can
talk to each other all at the same time. It is called PXP1000 and also has
two gigabit ethernet ports.

Cool.

I believe 100VG-Anylan is deterministic. And I think Corman sells hardware
with QNX drivers.
Purists will of course tell that it is not ethernet.

I believe that this is long since been discontinued. YES! It was a nice
product.

–
Bill Caroselli - Sattel Global Networks
1-818-709-6201 ext 122

19

Rennie Allen <RAllen@csical.com> wrote:

You would need to wire the system like this

1
20 --/|-- 2
19 --|\ / | \ /|-- 3
18–|/\ \ | / /|–4
17+/\ \ \ | / / //+5
16-----------------------6
15+// / / | \ \ /+7
14–|/ / | \ /|–8
13–|/ \ | / |–9
12–|/–10
11

How about something more like

1
/
20 2
/
19 3
/
18 4
/
17 5
| |
16 6
| |
15 7
\ /
14 8
\ /
13 9
\ /
12 10
\ /
11

So instead of the connect network Rennie suggests, why not create
your own ring. Might actually be cheaper than a 20 port switch as
well, that is if you get 40 ne2000 clones. In effect you will get
20*10Mb/s worth of bandwidth and you will also get some determinism
since each ehternet cable will only have 2 computers talking on
it.

One problem that may be created with this is latency if you need
to get the data to each node in ~1ms, or every 1ms. Former may be
difficult, but the later would be no problem.


OR

Again depending up the uniqueness of the data, broadcast packets
may work, but if the machines are farely well clocked to each other
you will have 20 machines trying to output a broadcast packeti at
the same. Even with the random delay ethnernet cards may use for
re-broadcast, you could wind up with a lot of contention.

You would definately have to be smart about it. That is when machine
2 gets the broadcast UDP packet from 1, it will then send out its
datagram. When 3 receives 2’s datagram it sends out its and so
forth. Thus bringing a bit of determinism to ethernet
.

So without ACKs, and each machine waiting in turn to transmit its
data, you should wind up with very few collisions. Of course you
would have to make each machine smart enough to know if it waits

1ms for a packet an error probably occured. Of course when node
x does not receive a datagram from x+1 in a specific time it can

assume that its packet did not make it out to the rest of the
network, well at leat not to x+1. IOT, there are still going to be
issues, but you still might be able to use those cheap ne2000 cards
and a normal hub to achieve the data flow you require.


Last but not least, I wouldbe tempted to use UDP packets instead
of TCP, of course for the astute (sp?) broadcast implies UDP. Since
you expect data ever ~1ms, if you don’t get it you can then either
use the last value or send an error packet. Using TCP will just
double the number of packets being thrown around (ACK that is)

note: for those not familiar
node == machine
datagram == UDP packet


random thoughts on vicadan,
Tom

–
Thomas Emberson <Thomas@QNX.com>

20

Previously, Armin Steinhoff wrote in qdn.public.qnxrtp.advocacy:

Why do you build a physical ring??? Building a logical ring using
a token passing protocol (token bus) makes more sense, it’s much
cheaper and is using just a standard bus architecture!!

Define ‘standard bus architecture’, if you are talking about 20
ethernet cards into a 20 port high bandwith switch solution, that
may be more expensive. Of course we have not asked how much the
programmers tims is worth compared to the purchase of an expensive
switch.

One problem that may be created with this is latency if you need
to get the data to each node in ~1ms, or every 1ms. Former may be
difficult, but the later would be no problem.

Spend 100us to transfer a packet from one node to the other … it
will take 20 times 100us = 2ms to distribute the information and you
have 20
times a point of failure =:-/

Again, it depends on how quickly you need the information, as my
last point stated. Read closely as I alreay mentioned that caveat.

OR
Again depending up the uniqueness of the data, broadcast packets …
[ clip …]

Comment:
use the MAP protocol before you fiddle around with UDP packets.

That ‘wheel’ is already invented > :slight_smile:

So you are suggesting adding even more traffic to a net work that
is already congested. I thought the whole point to the general
discussion was to make it possible to get all data to all the nodes
while spending as little money as possible. I might be a bit rusty,
but it doesn’t matter what protocols you use for routing or computer
discovery, large area networks, whatever, when you send data via
broadcast, it is by default using UDP packets, no?.

The whole point is, name another method to get the same 20 data
sets to 19 other computers reliably using ne2000 cards and a simple
20 port hub? With out getting into a lot of math, even if each
computer need to send slightly different information to each of
the other computers, bundling the information into a single packet
it would be more effiecient to packet it into a single packet
20*20<1500.

What’s wrong with UPD packets anyway, right tool for the right job.
When I have to tighten a small screw, I don’t pull out the impact
gun.

Tom