Hi,
While calculating the output link for any message inside a PerfectSwitch::wakeup(), the routing table is looked up. Depending on the routing table, the output link is selected. Now these routing tables are populated inside Topology::createLinks(bool). If you read through this, you will find that there is a call to - shortest_path(topology_weights, m_component_latencies, m_component_inter_switches).
Now this shortest path looks at "link weights" and decides for each source destination pair, which is the shortest path.
If nothing is specified, the weight is defaulted to latency and hence the shortest path is actually the shortest path in the network. However, if one wants to prioritize certain paths, the link weights will have to be specified in a manner that the intended route (which might not be the shortest) is calculated by this function as the shortest path.
One example where such a thing is useful is when one wants dimension ordered routing (as a matter of fact, any particular routing other than shortest path routing).
-Niket
> Hello Mike & Niket,
>
> Thank you for your explanation. I also noticed the usage of link weights defaulted to link latencies when calculating the routing table entries. But I don't see any difference in routing calculation with FINITE_BUFFERING enabled or not. The finite buffer size is just used to delay the message transfers (if there are not enough slots in the destination buffer) in both perfect switch and throttles in a switch. Where can I find the source code related to "e-cube routing"?
>
> Lide
>
> On 8/10/07, Niket Agarwal (niketa@xxxxxxxxxxxxx) <niketa@xxxxxxxxxxxxx > wrote:
> Link weight is defaulted to "link latency" if otherwise specified and is
> then used to calculate the shortest path from one point to the other in
> the network. This is used for routing.
>
> All this works fine if you use infinite buffering. For finite buffering
> though, the routing has to be restricted to dimension ordered e-cube and
> hence the link-weights have to be accordingly specified in the network
> topology file.
>
> - Niket
>
>
> > 1. In Throttle.C, the function network_message_to_size() uses a constant
> > MESSAGE_SIZE_MULTIPLIER whose value is 1000 to multiply with the message
> > size. Why do we need this value? I think the message sizes in GEMS should be
> > 8B for control message and 64+8B for data message. But with this value, the
> > message sizes are 1000 times larger. Is that correct?
> >
> >
> >
> > The bandwidth unit in the simulator is 1/1000 of a byte. This was for
> > smooth graduation of curves for the BASH paper
> >
> > 2. What dese the link weight mean in network code? Basically we have three
> > properties in a link: latency, bandwidth and weight. I noticed by default
> > the link weight was set to the same as latency, but it has been used when
> > calculating the routing route. So I am a little confused about the weight.
> >
> >
> >
> > i believe the link_weight is for E_cube routing when FINITE_BUFFERING
> > is enabled. I'm not positive though.
> >
> > 3. In the wakeup function of Throttle.C, there is a piece of Bash code. I am
> > wondering what it's used for.
> >
> >
> >
> > BASH-- Bandwidth Adaptive Snooping, Martin et al.
> >
> > http://www.cs.wisc.edu/multifacet/papers/hpca02_bash.pdf
> >
> >
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/ " to your search.
|
![[Computer Systems Lab]](http://www.cs.wisc.edu/pics/csl_logo.gif){kind=logo}