David S. Miller wrote:
> From: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Mon, 12 Dec 2005 12:03:22 -0800
>
>
>>- d32 = d32 / HZ;
>>-
>> /* (wmax-cwnd) * (srtt>>3 / HZ) / c * 2^(3*bictcp_HZ) */
>>- d64 = (d64 * dist * d32) >> (count+3-BICTCP_HZ);
>>-
>>- /* cubic root */
>>- d64 = cubic_root(d64);
>>-
>>- result = (u32)d64;
>>- return result;
>>+ return cubic_root((cube_factor * dist) >> (cube_scale + 3 - BICTCP_HZ));
>
> ...
>
>>+ while ( !(d32 & 0x80000000) && (cube_scale < BICTCP_HZ)){
>>+ d32 = d32 << 1;
>>+ ++cube_scale;
>>+ }
>>+ cube_factor = d64 * d32 / HZ;
>>+
>
>
> I don't think this transformation is equivalent.
>
> In the old code only the "d32" is scaled by HZ.
>
> So in the old code we're saying something like:
>
> d64 = (d64 * dist * (d32 / HZ)) >> (count + 3 - BICTCP_HZ);
>
> whereas the new code looks like:
>
> d64 = (((d64 * d32) / HZ) * dist) >> (count + 3 - BICTCP_HZ);
>
> Is that really equivalent?
Almost. It depends on how large the numbers are in d64 and d32, if their
multiplication may overflow than the first option is better since it has
less of a chance to overflow.
On the other hand, the second line can be more accurate.
Baruch
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
