Yes, the empty VCs would be skipped and the switch doesn't go unused
because of the addition of extra VNs.
But, note that the way the round-robin arbiter is implemented, the
m_round_robin_inport is incremented on every arbitration cycle and then
a linear scan of VCs is done to select the next VC that will win the
switch. If we add an extra VN in which VCs will never have anything,
VN=0 will get a lot many arbitration wins just because of the way the
arbitration logic is coded up. The different performance numbers are due
to that.
If you are *always* seeing VN=4 performing better than VN=5, the reason
could be that the request network (VN=0) is getting a much higher
priority and data is not able to travel faster in the network. Just
speculation!
-Niket
On 04/08/2010 03:07 AM, Ikhwan Lee wrote:
> Oh, I missed the 'for' statement at line-11. Yes, you're right. And
> I'm stuck again =(.
>
> 2010/4/8 付斌章 <fubinzhang@xxxxxxxxx>:
>
>> Line-11, line-14, and line-15 guarantee that the empty VCs belonging to
>> "extra" VN will be skipped
>>
>> 1. void SWallocator_d::arbitrate_inports()
>> 2. {
>> 3 // First I will do round robin arbitration on a set of input vc
>> requests
>> 4 for(int inport = 0; inport < m_num_inports; inport++)
>> 5 {
>> 6 int invc = m_round_robin_inport[inport]; //get the vc id
>> just before the vc we will first try, because invc is added again in line-13
>> 7 m_round_robin_inport[inport]++;
>> 8
>> 9 if(m_round_robin_inport[inport] >= m_num_vcs)
>> 10 m_round_robin_inport[inport] = 0;
>> 11 for(int j = 0; j < m_num_vcs; j++)// This guarantees that every
>> input vc will be checked
>> 12 {
>> 13 invc++;
>> 14 if(invc >= m_num_vcs)
>> 15 invc = 0; // wrap around..
>> 16 if(m_input_unit[inport]->need_stage(invc, ACTIVE_,
>> SA_) && m_input_unit[inport]->has_credits(invc))
>> 17 { // find a "need process" vc
>> 18 if(is_candidate_inport(inport, invc))// this
>> line is used to keep packets' order, ignor it
>> 19 {
>> 20 int outport =
>> m_input_unit[inport]->get_route(invc);
>> 21 m_local_arbiter_activity++;
>> 22 m_port_req[outport][inport] = true;
>> 23 m_vc_winners[outport][inport]= invc;
>> 24 break; // got one vc winner for this
>> port
>> 25 }
>> 26 }
>> 27 }
>> 28 }
>> 29}
>>
>> -----邮件原件-----
>> 发件人: gems-users-bounces@xxxxxxxxxxx
>> [mailto:gems-users-bounces@xxxxxxxxxxx] 代表 Ikhwan Lee
>> 发送时间: 2010年4月8日 13:43
>> 收件人: Gems Users
>> 主题: Re: [Gems-users] 答复: What happens if NUMBER_OF_VIRTUAL_NETWORKS is
>> greater than needed?
>>
>> The swtich allocator wakes up, checks exactly one VC for each input
>> port in a round-robin manner, and goes back to sleep. So, empty VCs
>> associated with the extra VN will actually consume extra cycle, which
>> kind of explains why VN=4 is slightly faster than VN=5 in my
>> simulations.
>>
>> Ikhwan
>>
>> 2010/4/8 付斌章 <fubinzhang@xxxxxxxxx>:
>>
>>> If the "extra" VN is empty, it does not affect the performance since empty
>>> VCs are always skipped.
>>>
>>> -----邮件原件-----
>>> 发件人: gems-users-bounces@xxxxxxxxxxx
>>> [mailto:gems-users-bounces@xxxxxxxxxxx] 代表 Ikhwan Lee
>>> 发送时间: 2010年4月8日 13:18
>>> 收件人: Gems Users
>>> 主题: Re: [Gems-users] What happens if NUMBER_OF_VIRTUAL_NETWORKS is
>>>
>> greater
>>
>>> than needed?
>>>
>>> I'm using the GARNET fixed pipeline model, and it looks like the
>>> round-robin arbitration could indeed cause different executions.
>>> SWallocator_d::arbitrate_inports() function uses m_num_vcs to wrap
>>> around, and since m_num_vcs = m_virtual_networks*m_vc_per_vnet,
>>> different number of VNs could lead to different timing.
>>>
>>> Thanks for pointing that out.
>>>
>>> Ikhwan
>>>
>>> On Wed, Apr 7, 2010 at 11:36 PM, Niket Agarwal <niketa@xxxxxxxxxxxxx>
>>>
>> wrote:
>>
>>>> What interconnect model you are using? In GARNET, most arbitrations
>>>>
>> across
>>
>>>> different VNs are independent. So, having extra unused VNs should not
>>>> matter. Having said that, I can imagine round-robin arbitrations inside
>>>>
>>> the
>>>
>>>> router taking separate decisions with different number of VNs. This could
>>>> lead to different order of packet delivery and hence different
>>>>
>> executions.
>>
>>>> -Niket
>>>>
>>>> On 04/08/2010 12:31 AM, Dan Gibson wrote:
>>>>
>>>> Well, actually the same argument applies. As far as I understand the
>>>> situation, your two runs (VN=4 and VN=5) could have had different
>>>> g_RANDOM_SEEDs, which could account for the difference in performance.
>>>> Admittedly, I'm no expert on Ruby's interconnect, so I don't know what
>>>>
>> the
>>
>>>> actual effect of extra VCs would be... but it seems like the kind of
>>>>
>> thing
>>
>>>> that would have an effect.
>>>>
>>>> Regards,
>>>> Dan
>>>>
>>>> On Wed, Apr 7, 2010 at 8:57 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
>>>>
>> wrote:
>>
>>>>> Dan,
>>>>> I was not trying to compare the performance of VN=4 and VN=5. I was
>>>>> rather concerned about the integrity of the simulation results since I
>>>>> could not understand why they weren't exactly the same. But I do
>>>>> appreciate your advice. Thanks,
>>>>> mos
>>>>> Ikhwan
>>>>>
>>>>> On Tue, Apr 6, 2010 at 8:17 AM, Dan Gibson <degibson@xxxxxxxx> wrote:
>>>>>
>>>>>> Ikhwan,
>>>>>> Let me put it another way. In multiprocessor simulations, no two runs
>>>>>> are
>>>>>> different in a /statistically significant way/. Only when two
>>>>>> configurations
>>>>>> (e.g., VN=4, VN=5) are run each MANY times, and averages taken, with
>>>>>> nice,
>>>>>> tight 95% confidence intervals, can one say with confidence that X is
>>>>>> faster
>>>>>> than Y.
>>>>>>
>>>>>> I.e., try VN=4 and VN=5 each with many different RANDOM_SEEDs.
>>>>>>
>>>>>> Regards,
>>>>>> Dan
>>>>>>
>>>>>> See also:
>>>>>> "Variability in Architectural Simulations of Multi-threaded
>>>>>>
>> Workloads",
>>
>>>>>> by
>>>>>> Wisconsin's own Alaa Alameldeen and David A. Wood.
>>>>>> LINK: http://www.cs.wisc.edu/~alaa/papers/hpca03_variability.pdf
>>>>>>
>>>>>>
>>>>>> On Mon, Apr 5, 2010 at 5:07 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks Dan. I was running MOESI_SMP_directory using a fixed
>>>>>>> g_RANDOM_SEED for all simulations. I am still not sure why results
>>>>>>>
>> are
>>
>>>>>>> different for having an extra VNET. I'll keep the list posted if I
>>>>>>> figure out why.
>>>>>>>
>>>>>>> Ikhwan
>>>>>>>
>>>>>>> On Tue, Apr 6, 2010 at 7:57 AM, Dan Gibson <degibson@xxxxxxxx> wrote:
>>>>>>>
>>>>>>>> It depends.
>>>>>>>> 1. If you're not using a protocol ending in _m, then your protocol
>>>>>>>> doesn't
>>>>>>>> use the MemoryController module. If that is the case, random noise
>>>>>>>> (aka
>>>>>>>> rand() % 5) is simply added to MAIN_MEMORY_LATENCY_MINUS_2 to
>>>>>>>> generate
>>>>>>>> the
>>>>>>>> 'actual' memory latency.
>>>>>>>> 2. If your protocol ends in _m, then you are using the
>>>>>>>> MemoryController
>>>>>>>> model, which has some built-in features to add random delays, when
>>>>>>>> activated. Check out MemoryController.[Ch] (specifically, the
>>>>>>>> comments
>>>>>>>> at
>>>>>>>> the start) to see how that works.
>>>>>>>>
>>>>>>>> In either case, for a fixed RANDOM_SEED, you should get precisely
>>>>>>>>
>>> the
>>>
>>>>>>>> same
>>>>>>>> results.
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Dan
>>>>>>>>
>>>>>>>> On Mon, Apr 5, 2010 at 4:43 PM, Ikhwan Lee <ikhwan@xxxxxxxxxxxxxxx>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> How is a simulation randomized? I've been getting exactly the same
>>>>>>>>> results for each run with same simulation parameters.
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Ikhwan
>>>>>>>>>
>>>>>>>>> On Sat, Apr 3, 2010 at 12:24 PM, Dan Gibson <degibson@xxxxxxxx>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Average many runs of each (e.g., 8 runs w/ VNs = 4, 8 runs w/
>>>>>>>>>>
>> VNs
>>
>>>>>>>>>> =
>>>>>>>>>> 5)
>>>>>>>>>> and
>>>>>>>>>> see if there is a statistically significant difference or not.
>>>>>>>>>> Since
>>>>>>>>>> the
>>>>>>>>>> difference in runtime is pretty small, this could be due only to
>>>>>>>>>> difference
>>>>>>>>>> in RANDOM_SEED.
>>>>>>>>>>
>>>>>>>>>> That said, I don't actually know how Ruby might react to having
>>>>>>>>>> 'extra'
>>>>>>>>>> VNs.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>> On Fri, Apr 2, 2010 at 4:52 PM, Ikhwan Lee
>>>>>>>>>> <ikhwan@xxxxxxxxxxxxxxx>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> The MOESI_SMP_directory protocol needs 4 virtual networks;
>>>>>>>>>>> however,
>>>>>>>>>>> it
>>>>>>>>>>> should also run fine with 5 virtual networks since the 5th
>>>>>>>>>>> virtual
>>>>>>>>>>> network will never be used by the protocol. The question is,
>>>>>>>>>>>
>>> when
>>>
>>>>>>>>>>> I
>>>>>>>>>>> compare the results of two simulations (one with 4 and one with
>>>>>>>>>>>
>>> 5
>>>
>>>>>>>>>>> virtual networks), I get something like below.
>>>>>>>>>>>
>>>>>>>>>>> 153c153
>>>>>>>>>>> < NUMBER_OF_VIRTUAL_NETWORKS: 4
>>>>>>>>>>> ---
>>>>>>>>>>> < NUMBER_OF_VIRTUAL_NETWORKS: 5
>>>>>>>>>>> 1457c1458
>>>>>>>>>>> < Ruby_current_time: 25741756
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>> Ruby_current_time: 27894100
>>>>>>>>>>>>
>>>>>>>>>>> 1459c1460
>>>>>>>>>>> < Ruby_cycles: 25741755
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>> Ruby_cycles: 27894099
>>>>>>>>>>>>
>>>>>>>>>>> 1461,1468c1462,1469
>>>>>>>>>>> < mbytes_resident: 480.223
>>>>>>>>>>> < mbytes_total: 508.523
>>>>>>>>>>> < resident_ratio: 0.944347
>>>>>>>>>>> <
>>>>>>>>>>> < Total_misses: 2736589
>>>>>>>>>>> < total_misses: 2736589 [ 221437 184551 181803 181854 165005
>>>>>>>>>>> 165866
>>>>>>>>>>> 172800 177348 162455 164810 168559 167311 146275 158797 158483
>>>>>>>>>>> 159235
>>>>>>>>>>> ]
>>>>>>>>>>> < user_misses: 199059 [ 6640 12908 16388 12543 9998 14914 11967
>>>>>>>>>>> 11834
>>>>>>>>>>> 17170 11744 11685 12695 13389 11501 12351 11332 ]
>>>>>>>>>>> < supervisor_misses: 2537530 [ 214797 171643 165415 169311
>>>>>>>>>>>
>>> 155007
>>>
>>>>>>>>>>> 150952 160833 165514 145285 153066 156874 154616 132886 147296
>>>>>>>>>>> 146132
>>>>>>>>>>> 147903 ]
>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>>> mbytes_resident: 177.781
>>>>>>>>>>>> mbytes_total: 498.574
>>>>>>>>>>>> resident_ratio: 0.356579
>>>>>>>>>>>>
>>>>>>>>>>>> Total_misses: 2976004
>>>>>>>>>>>> total_misses: 2976004 [ 231381 201401 206063 197190 177795
>>>>>>>>>>>> 182883
>>>>>>>>>>>> 187239
>>>>>>>>>>>> 196167 175355 180539 183532 179732 157077 173355 171734
>>>>>>>>>>>>
>> 174561
>>
>>>>>>>>>>>> ]
>>>>>>>>>>>> user_misses: 200169 [ 12482 12593 12510 11561 13957 9487
>>>>>>>>>>>>
>> 11581
>>
>>>>>>>>>>>> 12406
>>>>>>>>>>>> 17732 13232 11811 11721 12437 12137 12108 12414 ]
>>>>>>>>>>>> supervisor_misses: 2775835 [ 218899 188808 193553 185629
>>>>>>>>>>>>
>>> 163838
>>>
>>>>>>>>>>>> 173396
>>>>>>>>>>>> 175658 183761 157623 167307 171721 168011 144640 161218
>>>>>>>>>>>>
>> 159626
>>
>>>>>>>>>>>> 162147
>>>>>>>>>>>> ]
>>>>>>>>>>>>
>>>>>>>>>>> --- omitted the rest
>>>>>>>>>>>
>>>>>>>>>>> The differences are not too big, but still quite strange since
>>>>>>>>>>>
>> I
>>
>>>>>>>>>>> expected them to be exactly the same. Any idea on what is
>>>>>>>>>>> happening?
>>>>>>>>>>> I'm using Garnet fixed pipeline network.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Ikhwan
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> 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.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> 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.
>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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.
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>>
>>>> _______________________________________________
>>>> 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.
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> 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.
>>
>>>
>>>
>> _______________________________________________
>> 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.
>>
>>
>>
> _______________________________________________
> 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}