Open akoshelev opened 3 months ago
The test data generator has a conversion probability parameter that defaults to 2%, but it looks like it's only used when generating all trigger events (ReportFilter::TriggerOnly
). Possibly that is a bug?
Possibly that is a bug?
yea it looks like a bug to me, possibly not related to this one as we seem to be running out of space for HV not being large enough to account for degenerate use cases. We could say that we don't support more than 16 bits for HV, but then we need to fix our test in the clear
Discussed with @danielmasny - the approach of keeping an overflow bit is relatively straightforward to think about. Just keep the carry bit (secret shared) after the addition operation reaches the HV boundary. To properly set the overflow bit to 1, we need to OR all the carry bits obtained from the additions occurred after the overflow. This will require communication as OR gate cannot be represented by using XOR only
$A \lor B = (A \oplus B) \oplus (A \wedge B)$
So that will cost us an extra multiplication which is an extra 6% communication overhead. Not bad, but the aggregation code may need to significantly change to account for it. Using the appropriate channel, separating the overflow bit from value bits, etc.
I think it could be done relatively straightforwardly by using 15 of the 16 bits for storing the actual value and the 16th bit for the overflow. We could implement another integer_add which includes the computation and storage of the overflow bit when adding two values.
here is an example of such run
if number of input rows is large enough, the container type for breakdown key is too small to account for the sum of all values.