Karl Reichert wrote: > Jan Kiszka wrote: >> 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 >> > > So you are not interested testing the speed of RTnet system to the limits? ;) > Of course this would be very hardware and load specific, but it's good to > know in general!
So much to do, so little time... ;) Lacking the need to drive RTnet close to media barriers (CPU/OS barriers yet came earlier), these detail tests remain undone. Good that you came along. :) > > The motivation for asking this question was not because I intend to set the > slot gaps damn small but to test my own implementation (hardware and > software, whole system under load) and get some values to give the user hints > which cycle lengths with which loads and sizes of frames and which offset > setting are critical, which are known to work ... > So to keep it short, is there any other way to find single collisions then my > idea? And especially, do you have anything in mind how to also notice those > back off delays caused my carrier sense? Because these are not noticable by > any JAM signal which is only sent if collision already occured but not if a > sender backs off because of someone else's sending. Maybe some NICs / MIIs are chatty enough to reveal some internal states and statistics, but I can't help with more concrete hints. There might be hardware-based measurement/analysis tools available (e.g. around Ethernet Powerlink, IIRC), but they surely cost real money. 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
