Re: [Gems-users] topology model question

[Mladen Nikitovic <mladen@xxxxxx>]

hm, I don't understand how the extra row of 12 switches provides total 
ordering.
All links at all levels seem to have the same latency, namely 
NETWORK_LINK_LATENCY.
So, by adding a level of single-input switches, doesn't that just push 
the original problem up to the next level where the output from 4 single 
input/output switches are grouped into a single 4-input 1-output switch? 
Isn't it possible that there could be problems with ordering and 
flooding on that level instead?  In theory, it seems possible that the 
12 nodes send something simultaneously to their corresponding switches. 
And, if those switches send the packet upwards (to the 3 switches on the 
next level) in the same cycle you would end up in the same situation as 
if you hadn't the first level switches in the first place. I think I'm 
missing something that happens on the first level that prevents this 
from happening. But I don't see how a single-input single-output solves 
the problem.
/Mladen

Niket wrote:
> HIERARCHICAL_SWITCH and CROSSBAR topologies are designed to provide a 
> "total order" to requests so that broadcast protocols can be simulated. 
> Hence this indirection through root switch.
> As regards your earlier question of the extra level of up switched in 
> the HIERARCHICAL_SWITCH, looking at the makeHierarchicalSwitch function, 
> I find these comments :
>   // Make a row of switches with only one input.  This extra row makes
>   // sure the links out of the nodes have latency and limited
>   // bandwidth.
>
> I guess this explains it. If it were not for these links, the requesting 
> nodes would flood the network with requests assuming infinite buffering.
> -Niket
>
> Mladen Nikitovic wrote:
>   
> > Hi,
> >
> > I'm trying to understand the implementation of the network when using 
> > the HIERARCHICAL_SWITCH and the CROSSBAR topology in the 
> > MOESI_CMP_directory protocol.
> > I have a configuration of 4 processors, 1 processor per chip. My 
> > understanding is that the L1 cache controller, L2 cache controller and 
> > the directory are the entities that need access to the network. This 
> > means 4x3 entities in total = 12 nodes.
> > When choosing the HIERARCHICAL_SWITCH topology with FAN_OUT_DEGREE of 4 
> > i get the following implementation when tracing the 
> > makeHierarchicalSwitch function:
> > 19 switches and 42 links are created.
> >
> > Nodes 0 to 11 are hooked up to a switch each, which means 12 switches in 
> > total. These 12 switches are then connected to 3 switches (according to 
> > fan-out-degree) and these are finally connected to a root switch.
> > Now, in the "down network", the root switch is connected to 3 new 
> > switches, and these are then directly connected to nodes 12 to 23.
> > It seems that the switches have only one output on the way up to the 
> > root switch, but why do you need to create 12 switches in the first 
> > level? Do these switches only have one input as well? If the next-level 
> > switches can handle 4 inputs, why couldn't those handle the 12 nodes in 
> > the first place?
> > On the way down the switches have 4 outputs, according to 
> > fan-out-degree, correct?
> > The result is a structure that is asymmetrical, the up-network has more 
> > levels of switches than the down-network, so the question is why this is 
> > implemented this way? Is there a reason why there are switches with 
> > different number of in/out-ports?
> > In theory, the hierarchical switch topology looked symmetrical to me, 
> > but here I don't see that. Would be nice to understand this. The same 
> > asymmetry appears when using the CROSSBAR topology, but the only 
> > diffrence is that there are fewer levels of switches, (if i remember 
> > correctly there are 12 + 1 root switch = 13 switches in total).
> > Also, I expected local communication to be possible (by going up a level 
> > through a switch and then directly down, thus not through a root switch) 
> > , but I see from the topology printout that all latencies are the same 
> > no matter the location of the communicating nodes. Is there a reason why 
> > local communication is not possible?
> > Regards,
> > Mladen
> >
> >
> >
> >
> > _______________________________________________
> > 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.
> >
> >   
> >     
> _______________________________________________
> 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.
>
>