Andrea Forni wrote: > Hi all, > > for the first: I'm sorry for my english... > > I have linux kernel 2.6.10.0, RTAI 3.1 and rtnet 0.8.3. > > I'm realizing a communication between a node master and a node slave: slave > send > > n (in this case n=200) message to master with a similar code: >
...
>
> I organise tdma.conf file in this mode:
>
>
> # Primary master
> master:
> ip 10.0.0.3
> cycle 1000
> slot 0 200
> slot 2 600
>
>
> # Slave A
> slave:
> ip 10.0.0.1
> slot 10 0
"slot 0 0" would be fine here as well (it will make the slot succeed the
sync frame immediately - and safely).
> slot 2 400
>
> I would that the slave send two message (RT) to master in one cycle of TDMA.
> I hope to read that, for example :
>
>
>
> time event
>
> 0 synchronization TDMA
> 10 slave(10.0.0.3) send a message to master(10.0.0.1)
> 200 master receive a message from slave
> 400 slave send a message to master
> 600 master receive a message from slave
> 1000 synchronization TDMA
> 1010 slave(10.0.0.3) send a message to master(10.0.0.1)
> 1200 master receive a message from slave
> 1400 slave send a message to master
> 1600 master receive a message from slave
> 2000 synchronization TDMA
> .
> .
> .
> .
> .
>
> in the reality I have this situation:
>
> time event
>
> 0 synchronization TDMA
> 10 slave(10.0.0.3) send a message to master(10.0.0.1)
> 200 master receive a message from slave
> 1000 synchronization TDMA
> 1010 slave(10.0.0.3) send a message to master(10.0.0.1)
> 1200 master receive a message from slave
> 2000 synchronization TDMA
> .
> .
> .
> .
> .
>
>
> I'm searching to do a control in an automation system and I need to send a
> message to master very quickly (100-150us for the moment), for this motif I
> do the tests above...
> I read in old mails (and I verify this) that a cycle of 600us is stressfull
> for the network,but for my situation I must to send a message in shorter
> time(100-150us), for this
> I would to poll a node more than one time in the cycle.
If you have a well defined communication pattern, optimisation is
feasible. E.g. you don't have to keep the cycle period that low, you
could also duplicate the slot pattern several times in a longer cycle.
This saves load due the generating and consuming the sync frame.
Also, you could consider writing an optimised RTmac discipline if you
always have a poll/reply pattern between two nodes. I mean, currently a
node is sending time-triggered, but it would also be possible to
implement a policy that is message-trigged ("send next frame in slot X
after receiving some specific frame"). In order to get informed about
application data exchange also at RTmac/discipline level, encapsulating
such payload into RTmac frames would be required (just like tunnelled
non-RT data gets encapsulated). This may reduce the management overhead
by avoiding to schedule a polling reply according to strict time slots.
BTW, do you plan to use more than two stations in your final setup?
Jan
signature.asc
Description: OpenPGP digital signature
