# hama-user mailing list archives

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

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
phase.
>> 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
>>
>>

```
Mime
View raw message