260 likes | 269 Views
This paper explores the use of edge-coloring techniques to achieve real-time capabilities in Ethernet networks, merging the demands of Automation Technology with the trend towards Ethernet. The approach is independent of existing hardware and supports switches, hubs, and decentralized periphery. The paper presents a 4-step approach for a restricted problem class and provides first results demonstrating the feasibility of the proposed approach.
E N D
Achieving Realtime Capabilities in Ethernet Networks by Edge-Coloring of Communication Conflict-Multigraphs Frank Dopatka Frank.Dopatka@uni-siegen.de http://www.bs.informatik.uni-siegen.de/ Institute of Operating Systems and Distributed Systems University of Siegen, Germany PDCN 2006: Parallel and Distributed Computing and Networks, 15.02.2006
Aim: merge demands of Automation Technology with the trend towards Ethernet • TDMA instead of CSMA/CD: • industrial-realtime & asynchronous time-slots • compatibility vs. speed... slide 2 Ethernet in Automation Technology ? • Idea: one network from ERP- & office-area (SAP) to the field-devices (sensors, actuators) • Ethernet: widely-used, easy to use & low cost; • CSMA/CD → non-deterministic behaviour • Automation Technology: determinism, cyclic communication, min. cycle-time, less payload, min. delay & jitter, decentral periphery
SIEMENS • in-house realtime 4-port switch ASICs • → in-house; 4-ports; packet delays • Beckhoff Automation • standard Ethernet NICs with special • HW-connectors • data transmitted like shifting register • → no real Ethernet any more slide 3 Existing Solutions • Bernecker+Rainer (B&R) • standard Ethernet hubs & central manager → no concurrent communication; only RT-members
slide 4 Aim of our Work • develop an approach, independent from existing hardware • support: switches and/or hubs → distributors, half- & full-duplex transmission, decentral periphery → concurrent communication • using a top-down strategy: • - tree-based infrastructure is given • - requirements of the devices (QoS-requests) are given • previously well-known requirements of the devices are e.g.: • - Who sends how many data to whom and when ? • - What is maximum delay and jitter ?
slide 5 Aim of our Work • first results for a restricted problem-class: • - unicast-addressing → Communication Line (CL): sender → receiver • - uniform packet-size (Ethmin: less payload) • - transmission at each production cycle: no priorization • - neither delay, nor jitter in distributors, devices & cables our scientific contribution: We designed a 4-step-approach for this restricted problem-class by using known algorithms!
slide 6 Survey of our Approach
slide 7 I: Generate Communication Lines Given networking infrastructure with tree-topology...
slide 8 I: Generate Communication Lines ...with switches, their ports, and devices.
slide 9 I: Generate Communication Lines Line-topology emulated: 3-port-hubs → minimize packet delays
slide 10 I: Generate Communication Lines R1b R1a Given requirement R1: dev12 sends to dev17
slide 11 I: Generate Communication Lines R1b R1a Choosing 1 root-distributor at first for all requirements...
slide 12 I: Generate Communication Lines R1b R1a R1b R1a and acquire uplinks from each device to the root-distributor...
slide 13 I: Generate Communication Lines 1 1 1 1 1 1 concatenation of 2 uplinks → CL 1
2 4 2 3 4 3 5 2 8 7 7 9 6 9 8 5 6 4 6 5 5 4 5 5 slide 14 I: Generate Communication Lines 1 1 1 1 1 1 Each CL is stored by using an attribution-technique. The root-node is not needed any more.
slide 15 I: Generate Communication Lines 1 2 4 3 4 2 3 5 2 8 7 7 9 6 1 9 8 5 1 6 4 6 1 5 1 1 5 4 5 5 conflict : at least 2 CL share 1 port → common resource our aim : schedule the conflicts → temporal separation:TDMA
slide 16 II: Build Conflict Multigraph for each Switch 1 2 4 3 4 2 3 5 2 8 7 7 9 6 1 9 8 5 1 6 4 6 1 5 1 1 5 4 5 5 Why is each switch independent ? → Tree topology ! → Schedules can be synchronized after generation :-)
slide 17 II: Build Conflict Multigraph for each Switch 1 2 4 3 4 2 3 5 2 8 7 7 9 6 1 9 8 5 1 6 4 6 1 5 1 1 5 4 5 5 Independency of the switches: 2 CL in 1 switch have a conflict, or they never have !
slide 18 II: Build Conflict Multigraph for each Switch 1 2 4 3 4 2 3 5 2 8 7 7 9 6 1 9 8 5 1 6 4 6 1 5 1 1 5 4 5 5 Independency of the switches: A conflict raises never or in exactly one order in the network !
6 1 5 3 2 ports → nodes of the graph 4 CLs → edges of the graph 9 8 7 slide 19 II: Build Conflict Multigraph for each Switch 4 2 1 3 4 2 3 5 8 7 7 9 6 1 9 8 5 6
6 1 5 3 Color 1: 2 4 Color 2: 9 Color 3: 8 7 slide 20 III: Greedy-Edge-Coloring Heuristics WHILE (not all edges colored) x := any non-colored edge M := set of neighbor-edges from x color(x) := lowest color not present in M END WHILE
6 1 5 3 2 1 3 2 4 9 8 7 slide 21 IV: Calculate the Schedule 1 3 7 2 5 8 4 6 9
slide 22 First Results • We generated 32 random conflict-graphs each with • - 4 / 5 / 6 / 8 / 12 / 16 / 24 / 32 ports • - 2000 / 4000 / 8000 / 16000 randomized CLs • →greedy-coloring on 2.4Ghz Intel P4-Laptop • 4000 CLs in a switch can be calculated in 3 sec.: O(n2) • Time complexity with constant amount of CLs reduces logarithmical with the amount of ports ! • → lower „density“ of the graph • → easier to find next free color for greedy
slide 23 First Results Problems with odd amount of nodes/ports & circles in graph: 12% more colors than theoretical lower bound on average... otherwise 0.1% more colors on average But: - cyclic transmission unusual in Automation Technology - 5-port-switch: only 2 CLs at the same time anyway!
slide 24 Conclusion • We found a method for a restricted problem-class: • - unicast-addressing • - uniform packet-size - sending at each cycle • - neither delay, nor jitter • schedules nearby theoretically best-case results if no odd amount of ports are used • non-realtime traffic options can be added by additional time-slots
slide 25 Conclusion & Future Work • include more common cases → relax restrictions • - multicasting & multiple packet sizes • - sending at each 2nd, 3rd,... cycle • - handle delay & jitter • improve the coloring by usage of known additional heuristics • → only necessary for distributers with most colors • consider, where the schedule is enforced • - inside the switches & dev-polling („Laptops allowed“) • - using external arbiters & dev-polling („standard hardware“) - enforcing inside the devices („fast“) • → consequences for the generation of the schedules • simulate industrial case scenarios with own framework
Thank you for your Attention! Any Questions?