Indeed, 1ms is the offset i put in the config file. One quick question though, if RTnet is guaranteed with jitter across the network of about few us why would anything below 1ms be a problem ?
Overload. If, typically on a rather slow system, you are still preparing your answer on the first Start of Frame when the next arrives, the communication may break down - especially during the initialisation phase. What are your round trip times without RTmac?
I browsed all the examples in /rtmac/example and came across several question, hoping you can help me. 1) I see that under TDMA, in order to send packages tdma_wait_sof is firstly called followed by the rt_socket_sendto. Please correctly me if I am wrong, so tdma_wait_sof waits ( process suspend ?) for its turn to transmit in the time slot ? just like how rt_task_wait_period in RTAI is meant to be ?
Almost correct. It waits on the Start of Frame packet received from the master (or on the transmission of this packet when running on the master itself). But, yes, it is much like rt_task_wait_period, it's just another timer source.
2) Another question would be, is it be possible that the packet size is too large that slot deadline is breached ? since it is written in LXRT, what happens if the slot is disoriented ?
Not really, but maybe on very slow devices (486 embedded boards with SMSC91111 are such candidates). By default, the slot offset is set to 200 us by the rtnet script. The physical transmission time of maximum-sized 1518 byte packets is below 130 us, typical packet setup times are a few 10 us + jitter. So, on *normal* systems (Pentium class), there will be no interference.
Note that too large UDP packets will be fragmented, thus mapped on succeeding TDMA frames.
3) May multiple 'thread' real-time task send packet to the same slot ? Maybe I should say, is it possible to squeeze multiple packet from different tasks to the same cycle slot time? How can I order the packets?
Squeezing is not possible, at least not with the current TDMA (could be worth a thought for the planned revision). You may order your packets by assigning priorities (SOCK_MAX_PRIO to SOCK_MIN_PRIO) using the IOCTL RTNET_RTIOC_PRIORITY.
Jan
------------------------------------------------------- This SF.Net email is sponsored by: GNOME Foundation Hackers Unite! GUADEC: The world's #1 Open Source Desktop Event. GNOME Users and Developers European Conference, 28-30th June in Norway http://2004/guadec.org _______________________________________________ RTnet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/rtnet-users
