What happens if a body flit is blocked? Or is this akin to circuit switching where the links are reserved before the head flit is sent?
grose
@regi what problem in particular are you worried about with a body flit being blocked? I don't know if this is the answer you want, but in class, we talked about multiple virtual "channels", where each router remembers the pending packet it's processing
grose
For long messages, is latency independent of distance, because distance affects only the time till the first flit arrives, which, if the message is long, is only a small fraction of the total time
dumbo_
Wormhole Flow Control summary:
Advantage over "store-and-forward" control
- lower latency
- more efficient buffer utilization
Limitations:
- occupies resources across multiple routers
- suffers from head of line blocking(if head flit cannot move due to contention, another worm cannot proceed even through the link is idle)
andrewwuan
What decides the total length of the entire message? If bandwidth allows, are the slits "pushed" as fast as it can be, so that the minimum length of the entire message can be 3 (1 for head, 1 for body, and 1 for tail, no matter how long the body is)?
BryceToTheCore
I think that there would still be a correlation with Network distance and the chance of the transaction being blocked. The longer a transaction travels, the higher the probability that it will encounter a busy intersection. If the transaction halts, then latency will have increased.
Edit
Ahhh, the next slide addresses this concern!
plymouth
Does wormhole flow control have any advantages compared to cut-through flow control? It seems like wormhole flow control would be more difficult to implement.
BryceToTheCore
Wormhole flow control allows us to build networks with buffers only large enough to contain a flit, but not not an entire packet.
grose
But isn't that an insubstantial difference? From what I've read, packets aren't that big
http://searchnetworking.techtarget.com/answer/Minimum-and-maximum-Ethernet-frame-sizes
I guess it might make a difference on chip though...
What happens if a body flit is blocked? Or is this akin to circuit switching where the links are reserved before the head flit is sent?
@regi what problem in particular are you worried about with a body flit being blocked? I don't know if this is the answer you want, but in class, we talked about multiple virtual "channels", where each router remembers the pending packet it's processing
For long messages, is latency independent of distance, because distance affects only the time till the first flit arrives, which, if the message is long, is only a small fraction of the total time
Wormhole Flow Control summary:
Advantage over "store-and-forward" control
- lower latency
- more efficient buffer utilization
Limitations:
- occupies resources across multiple routers
- suffers from head of line blocking(if head flit cannot move due to contention, another worm cannot proceed even through the link is idle)
What decides the total length of the entire message? If bandwidth allows, are the slits "pushed" as fast as it can be, so that the minimum length of the entire message can be 3 (1 for head, 1 for body, and 1 for tail, no matter how long the body is)?
I think that there would still be a correlation with Network distance and the chance of the transaction being blocked. The longer a transaction travels, the higher the probability that it will encounter a busy intersection. If the transaction halts, then latency will have increased.
Edit
Ahhh, the next slide addresses this concern!
Does wormhole flow control have any advantages compared to cut-through flow control? It seems like wormhole flow control would be more difficult to implement.
Wormhole flow control allows us to build networks with buffers only large enough to contain a flit, but not not an entire packet.
But isn't that an insubstantial difference? From what I've read, packets aren't that big http://searchnetworking.techtarget.com/answer/Minimum-and-maximum-Ethernet-frame-sizes
I guess it might make a difference on chip though...