Re: Question on PE Checksum

Walter,

see my comments in-line.

Best regards
Michael

On Jul 21, 2005, at 23:47 Uhr, Johnson Walter-CWJ002 wrote:

> The only inconsistency we are trying to detect is within the  
> handlespace of the registrars. What we need to know is the probability  
> that the PE Checksum calculated for a particular registrar will result  
> in the same PE Checksum value calculated using different byte block  
> data (incorrect registrar handlespace data). If different we want to  
> synchronize our handlespace. Basically we want to have a consistent  
> handlespace knowing which registrars own which PEs.
It is clear at that level... But what kind of inconsistencies?
- A PE is registered at one side but not at the other.
- Differences in the data of a PE registered at both sides.
- ?
If one can not get any specific error model it is the best to assume  
that the 16 checksum will not detect
an inconsistency with a probability of 1/2^16.
>
> If the PE checksum does match for different byte block data does it  
> matter? Phrased another way, do the handlespace inconsistencies  
> matter? I don't see a case where this matters from a basic operational  
> standpoint.
>
>
> -----Original Message-----
> From: Michael Tuexen [mailto:[email protected]]
> Sent: Thursday, July 21, 2005 3:37 PM
> To: Johnson Walter-CWJ002
> Cc: Thomas Dreibholz; [email protected]
> Subject: Re: [Rserpool] Question on PE Checksum
>
> Hi Walter,
>
> see my comments in-line.
>
> Best regards
> Michael
>
>
> On Jul 21, 2005, at 21:49 Uhr, Johnson Walter-CWJ002 wrote:
>
>> Not that I have verified this 32 bit Internet Checksum algorithm
>> (http://www.csee.usf.edu/~christen/tools/check32.c) for accuracy or
>> efficiency/optimization. But this seems to indicate a method where a
>> 32 bit Internet Checksum can be calculated using only a 32 bit
>> processor.
> Just to be clear: I have not said that you can not compute the 32 bit
> checksum
> on a 32 bit processor. What I wanted to point out out is that the
> common efficient
> way of computing the checksum makes use of a larger integer type where
> you can accumulate
> the overflows without having explicit statements for that in the code.
>
>  From the code you cited:
>
>      sum = sum + *((word32 *) addr)++;
>      count = count - 4;
>      if (sum < sum_last) overflow++;
>      sum_last = sum;
>
> The optimized versions do not have the last two lines of the inner loop
> shown above.
>>
>> If true, I guess my main concern is if people believe/know if moving
>> to a 16 bit Internet Checksum with its reduced ability of detecting an
>> inconsistency in the handlespace is better than using a non-optimized
>> 32 bit Internet Checksum hash or a very efficient 32 bit XOR hash
>> (instead of 16 bit Internet Checksum hash) which may not be optimally
>> spread/unique as compared to a 32 bit Internet Checksum but
>> potentially better than a 16 bit Internet Checksum.
> My feeling (that means I can not prove it) is that we should use a
> checksum here and not an XOR. The 16 bit checksum
> can be computed efficiently on every platform running IP, the 32 bit
> may or may not be computed as efficient.
> The real question for me is: Do we need a better one than 16 bit
> checksum. What kind of inconsistencies are we expecting?
> I have no idea on that. What do others think?
>>
>> Thanks
>> Walter
>>
>> -----Original Message-----
>> From: Michael Tuexen [mailto:[email protected]]
>> Sent: Thursday, July 21, 2005 10:00 AM
>> To: Thomas Dreibholz
>> Cc: [email protected]; Johnson Walter-CWJ002
>> Subject: Re: [Rserpool] Question on PE Checksum
>>
>> Thomas,
>>
>> the question is not if it is available in a programming language, but
>> if it is available on all processors the protocol runs on.
>> And that point is what I'm not sure about. And I'm not talking
>> about about servers or workstations, but processors used in embedded
>> devices and so on.
>>
>> The other point is that people do have some highly optimized code
>> for the 16 bit stuff, but not for the 32 bit stuff. But they can build
>> it if the processor supports 64 bit integer arithmetic.
>>
>> Best regards
>> Michael
>>
>>
>> On Jul 21, 2005, at 11:19 Uhr, Thomas Dreibholz wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Thursday 21 July 2005 09:21, Michael Tuexen wrote:
>>>> Hi Walter,
>>>>
>>>> I have looked into efficient ways of implementing the Internet
>>>> checksum
>>>> and figured
>>>> out that you need 32 bit arithmetic to calculate the 16 bit  
>>>> checksum.
>>>> When using
>>>> a '32 bit Internet checksum' this would require support for 64 bit
>>>> integers.
>>>
>>> Yes.
>>>
>>>> I do think that we should not require that.
>>>
>>> But is this really relevant on today's computers and compilers?
>>> Working with
>>> 64-bit integers ("long long" datatype) is for example part of the
>>> ANSI-C
>>> standard since ANSI C99 (http://www.nirvani.net/docs/ansi_c.pdf).  
>>> This
>>> standard is six years old.
>>>
>>> I think the effort to use the 32-bit sum is not significantly higher
>>> than to
>>> use the 16-bit sum; but the probability that handlespace
>>> inconsistencies are
>>> detected is.
>>>
>>>
>>> Best regards
>>> - --
>>> ===================================================================== 
>>> =
>>> =
>>>  Dipl.-Inform. Thomas Dreibholz
>>>
>>>  University of Essen,                            Room ES210
>>>  Inst. for Experimental Mathematics              Ellernstraße 29
>>>  Computer Networking Technology Group            D-45326  
>>> Essen/Germany
>>> -
>>> --------------------------------------------------------------------- 
>>> -
>>> -
>>>  E-Mail:     [email protected]
>>>  Homepage:   http://www.exp-math.uni-essen.de/~dreibh
>>> ===================================================================== 
>>> =
>>> =
>>> -----BEGIN PGP SIGNATURE-----
>>> Version: GnuPG v1.2.4 (GNU/Linux)
>>>
>>> iD8DBQFC32im32BbsHYPLWURAjLRAJ0Rw450qEZypJ52M6vfxi+WGeU5fACfX1hY
>>> 98Q/vzXnwNsqwmUEym2ILpc=
>>> =8ijA
>>> -----END PGP SIGNATURE-----
>>>
>>
>