hama-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ηλίας Καπουράνης <ikapo...@csd.auth.gr>
Subject Re: Aggregator Problem (?)
Date Sat, 21 Dec 2013 11:48:24 GMT

yeah I know about the corner case. What do you mean the aggregated 
results from superstep number 1? Between supersteps, there are the 
"aggregator" supersteps. And they are like  this:
- node superstep No.1
- aggregator superstep No.1
- node superstep No.2 etc etc

So if a node at "node superstep No.1" votes to halt, he shouldn't be 
included in the aggregator phase which comes next, right?

My question is:
why the node gets aggregated if he has voted to halt? Doesn't "vote to 
halt" mean that he wants to stop?

Στις 20/12/2013 11:35 μμ, ο/η Anastasis Andronidis έγραψε:
> Hello,
> what you actually see it is an expected behavior from the aggregators. The results you
are taking in the superstep number 2, are the aggregated results from superstep number 1.
> There is a small corner case though. In superstep 0 the aggregators are off. This will
change on next release.
> Cheers,
> Anastasis
> On 20 Δεκ 2013, at 4:48 μ.μ., ikapoura@csd.auth.gr wrote:
>> Hello there,
>> I am using the Graph API and I have noticed something.
>> If a node votes to halt at a superstep, we suppose that he won't be part of the aggregation
>> BUT he is included in the aggregation phase of the next superstep!
>> To be more precise:
>> - Imagine we have a graph with 10 nodes.
>> - At superstep 1 node K votes to halt.
>> - At superstep 2 we check the number of the nodes aggregated and its 10. (it had
to be 9)
>> - At superstep 3 we check again the number of the nodes aggregated and then it is
9! (which is the correct)
>> This persists only with the aggregators. Node K doesn't work at superstep 2.
>> Can someone confirm that this is a problem or am i missing something?
>> Thanks

View raw message