Karl Reichert wrote: > Hi, > > I'm thinking about how to notice single collisions on ethernet ATM: > > As I remember IEEE902.3u, Media Independent Interface MII sends a notice to > Medium Access Controller MAC only, if excessive collisions occur, which means > more than 15 collisions without any successfull sending in between. > > What might by fine for CSMA/CD is a problem for TDMA in RTnet to my mind. As > one can only notice excessive collisions, there is no chance to notice a > collision only happening from time to time, e.g. because gap between TDMA > slots is to short for occuring sending jitters. > > So I figured out two solutions to get single collisions, anyway: > 1. Capture complete traffic with wireshark. If one checks when frames are > sent, delayed frames point to a collision occured before which leads to a > delayed 2nd try. > 2. Connect an oscilloscope to cable and trigger on JAM signal. > > So let's discuss those ideas: > Problem with 1st one is, that it's not really possible to find the difference > between a frame sent later because of sender's jitter and one because of > collision occured. The MII state machine tries to send a frame again within > nano or microseconds. Jitter on sender's side is around 10 microsends. So > there is no really way to see what's the deal with those delayed frames. > 2nd one should work, what do others say? > > Or is there a way how RTnet can signalize a single collision to system/upper > layers? How did the developers tested their implementation, e.g. run speed > tests, for a single collision?
First, we don't do that tight schedules here which may trigger collisions on shared media. Second, collisions do not yet occur when some larger slots overlap at the end (and if you use hubs, switches resolve them anyway). There is still that "CS" (Carrier Sense) which prevents B from sending while A is transmitting. That's valid for the slot time being larger than the slot jitter. So, what you have to know about your nodes are their worst-case slot scheduling jitters in order to lay out the TDMA configuration in a safe manner. Finally, TDMA is mainly about deterministic load management these days, specifically when using switched networks. It allows you to schedule the RTnet-related load "away" from other timed critical jobs on the receiving nodes (time-triggered design) and to confine the peak packet rates every participant has to handle. Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________ RTnet-users mailing list RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users