slide1
Download
Skip this Video
Download Presentation
Achieving Realtime Capabilities in Ethernet Networks by Edge-Coloring

Loading in 2 Seconds...

play fullscreen
1 / 26

Achieving Realtime Capabilities in Ethernet Networks by Edge-Coloring - PowerPoint PPT Presentation


  • 97 Views
  • Uploaded on

Achieving Realtime Capabilities in Ethernet Networks by Edge-Coloring of Communication Conflict-Multigraphs. Frank Dopatka [email protected] http://www.bs.informatik.uni-siegen.de/. Institute of Operating Systems and Distributed Systems University of Siegen, Germany.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Achieving Realtime Capabilities in Ethernet Networks by Edge-Coloring ' - donnel


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

Achieving Realtime Capabilities

in Ethernet Networks

by Edge-Coloring

of Communication Conflict-Multigraphs

Frank Dopatka

[email protected]

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

slide2

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
slide3

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
slide4

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 ?
slide5

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!

slide6

slide 6

Survey of our Approach

slide7

slide 7

I: Generate Communication Lines

Given networking infrastructure with tree-topology...

slide8

slide 8

I: Generate Communication Lines

...with switches, their ports, and devices.

slide9

slide 9

I: Generate Communication Lines

Line-topology emulated: 3-port-hubs → minimize packet delays

slide10

slide 10

I: Generate Communication Lines

R1b

R1a

Given requirement R1: dev12 sends to dev17

slide11

slide 11

I: Generate Communication Lines

R1b

R1a

Choosing 1 root-distributor at first for all requirements...

slide12

slide 12

I: Generate Communication Lines

R1b

R1a

R1b

R1a

and acquire uplinks from each device to the root-distributor...

slide13

slide 13

I: Generate Communication Lines

1

1

1

1

1

1

concatenation of 2 uplinks → CL 1

slide14

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.

slide15

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

slide16

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 :-)

slide17

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 !

slide18

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 !

slide19

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

slide20

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

slide21

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

slide22

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
slide23

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!

slide24

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
slide25

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
ad