1 / 25

Real-Time Communication in Multihop Networks

Real-Time Communication in Multihop Networks. Dilip D. Kandlur , IEEE Member, Kang G. Shin, IEEE Fellow, Domenico Ferrari, IEEE Fellow Presented by Spencer Crosswy. We want to guarantee time-constrained message delivery in multihop networks.

cooper
Télécharger la présentation

Real-Time Communication in Multihop Networks

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Real-Time Communication in Multihop Networks Dilip D. Kandlur, IEEE Member, Kang G. Shin, IEEE Fellow, Domenico Ferrari, IEEE Fellow Presented by Spencer Crosswy

  2. We want to guarantee time-constrained message delivery in multihop networks. • Why? Unpredictable message delay  Unpredictable task completion  Missed deadlines? • Schemes exist for best effort – no guarantees • Latency can grow as it propagates • Want a priori guarantees

  3. First, we define our environment. • Processors nodes connected by links • Links ingoing or outgoing • Links can be parallel • Distributed RTOS manages control, clock synchronization, global timebase

  4. Then, we define a time-constrained communication abstraction. • Communication requires resources: network bandwidth, buffer space, message-processing bandwidth, etc. • Users defined message requirements: source & destination, delivery time, size, etc. • Want RTOS to reserve resources based on requirements • All this encompassed by a channel

  5. Message generation is another user requirement – we need a model. • Assumed to be periodic (can model aperiodic) • Max message size = (bytes) Max message rate = (messages) Max burst size = (msg. bursts) (Min interarrival= = ) • Max # messages in = Channel

  6. What does it mean to guarantee message delivery? • logical generation time • Msg guaranteed delivered by

  7. The solution - establish a channel. • Select source-destination route • Compute worst-case delay and buffer req. for each link • Check total worst-case delay against max allowed delay • If delay OK, adjust link buffers for max allowed delay, and establish channel

  8. What affects worst-case delay?Other messages. • Real-time messages affect delay • Burst messages – aperiodic (outside model) • No innate restriction on which messages get handled first

  9. What affects worst-case delay?Scheduling algorithms. • Deadline Scheduling (dynamic at each link) • Earliest Due Date - optimal when deadline = beginning of next period • Bad - priority depends on arrival order • Fixed-Priority Scheduling (fixed over channel) • Rate-Monotonic - channel priority = message freq. • Could check if channel set is schedulable • Bad – message freq. not consistent at each node • bursts = early msgs  missed deadlines

  10. We need a bettermessage scheduling algorithm.

  11. Calculate response time with modified fixed-priority scheduling algorithm. • Message’s response time on one channel depends on arrivals at other channels • Existing channels: • = channel • = transmission time • = interarrival time • = user-defined max allowed delay (constant over channel) • Given new channel ), we want feasible priority assignment for set (wcrt) • We’d like FPA to minimize

  12. Calculate response time with modified fixed-priority scheduling algorithm. • D_Order: • Arrange channels by delay • Small delay  High priority ( gets highest) • Compute based on these priorities • Find highest priority for which for all lower priorities • Make this the new channel’s priority and calculate • Proved optimal if (long proof)

  13. Which message gets handled first? Use modified EDD (dynamic) algorithm. • Messages get timestamped at source • Logical arrival time (for source) (for node b after node a in channel)

  14. Schedule messages bylogical arrival time. • RTOS maintains 3 queues per link • Real-time packets with current time(arranged by deadline) • Non-real time packets (arranged by deadline) • Real-time packets with current time(arranged by deadline) • When packet arrives, calculate logical arrival time and place in appropriate queue • Dispatcher goes through queues and starts transmission if not empty (also moves Q3 to Q1)

  15. OK, we’ve guaranteed worst case delay times. Now consider memory.

  16. Each node needs buffer space to prevent message loss • Source buffer size determined by : Buff. Size = • Intermediate buffer size det. by horizon: (if packet’s message’s logical time is outside horizon, throw the packets out because they’re outside requirements)

  17. How do we optimize checking each packet against the horizon? • Flow Control: • Each new channel computes horizon at each link and passes the horizon upstream • Each node uses this horizon to control downstream flow • Optimization • Diff. horizon per channel: flexible, but slow! (Q3)

  18. What about the buffer size for intermediate nodes? • Example: 2 nodes a,bshare link w/ horizon • No messages m will have , so… • All messages at b will be in range: • Buffer needs to allow for this range, so… • Buff. Size = • Node’s buffer size = sum of all channel buffers • New channel – decrease horizon if necessary

  19. Extension for Long Messages

  20. Long messages could be a problem • Nodes can transmit packets, but have to store whole message • More links = less delay available/link • What’s the typical solution? …

  21. Pipeline groups of packets to alleviate long message issues. • Split message on channel into packets with size • =packet group delaytotal delay

  22. How many packet groups do we need for a given message? • Want to minimize so more packet groups is better (even one packet per group!) • (Fancy math) – boils down to: • Upper bound: proportional to • Lower bound: can’t be arbitrarily small(must send packets atomically)

  23. Channels with packet groupsare established differently. • (Recall old method) • Select source-destination route, counting # links • Choose # packets = • Compute worst-case delay for each link • Check buffer requirements against horizons • Check total worst-case delay against max allowed delay (using modified D_Order algorithm) • If delay OK, adjust link buffers for max allowed delay

  24. Packet groups need differentmessage scheduling and buffer size. • Messages scheduled basically the same • logical arrival time computed for a whole group • Dispatch manager handles whole groups • Buffer size must be big enough for 2 packet groups

  25. Summary • Real-time multihop = must establish channels and schedule messages to meet requirements • New algorithms for both • Buffer size calculations • Flow control methods (optimization)

More Related