Subject: Re: [Rserpool] Re: Adler-32 Checksum

From: Thomas Dreibholz <[email-masked]>
Date: Fri, 1 Jul 2005 16:05:35 +0200

On Thursday 30 June 2005 17:06, Peter Lei wrote:
> Johnson Walter-CWJ002 wrote:
> > Is there any property that makes the Internet Checksum better at
> > detecting a handlespace inconsistency as compared to a simple XOR of the
> > byte block data which is composed of the pool handle zero padded to a 32
> > bit work boundary and the 32 bit PE Id?
> >
> > Wondering since the Internet checksum will be more computationally
> > expensive.
>
> I'm not sure what your concern is here.  The Internet checksum
> is just the ones's complement of (one's complement sum + carry).
> That's two additional steps over a simple XOR sum.

XOR is computationally cheaper than addition. It works bit-wise and does not 
need a carry. So if the probability of detecting handlespace inconsistencies 
would be the same for the Internet checksum and XOR, XOR would be the 
preferable solution.

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-masked]
 Homepage:   http://www.exp-math.uni-essen.de/~dreibh
=======================================================================

_______________________________________________
rserpool mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rserpool

---

From: James Carlson <[email-masked]>
Date: Fri, 1 Jul 2005 10:32:09 -0400

Thomas Dreibholz writes:
> need a carry.

Was that meant as a serious comment?  I don't think that sort of
consideration applies to _any_ system built in the past 40 years or
so.

I'd think that choosing a commonly-implemented (and thus likely-to-
be-bug-free and well-supported and well-understood) algorithm would
trump any concern about bit twiddling at this level.

I suspect that most people who deal with TCP/IP already have a handy,
well-tested in_cksum() function available.

-- 
James Carlson, KISS Network                    <[email-masked]>
Sun Microsystems / 1 Network Drive         71.234W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.497N   Fax +1 781 442 1677

---

From: Qiaobing Xie <[email-masked]>
Date: Fri, 01 Jul 2005 12:09:54 -0500

James,

I couldn't agree with you more here. Let's just stick with something 
that is well known and widely accepted.

regards,
-Qiaobing

---

From: Thomas Dreibholz <[email-masked]>
Date: Mon, 4 Jul 2005 10:33:47 +0200

On Friday 01 July 2005 16:32, James Carlson wrote:
> > XOR is computationally cheaper than addition. It works bit-wise and does
> > not need a carry.
>

XOR is cheaper, although not significantly on today's computers.

> So if the probability of detecting handlespace inconsistencies 

But unfortunately, the inconsistency detection probability seems to be lower
for XOR. Example:
Pool "TEST", PE #1000
Pool "TEST", PE #1001
Pool "TEST", PE #1002
Pool "TEST", PE #1003
Since the amount of PEs in the pool is even, the PHs' XOR chechsum would
cancel out (x XOR x XOR x XOR x == 0); therefore the checksum would
effectively be computed over the PE IDs only.

Using the Internet checksum, the PHs - regardless of even or odd number of
PEs in a pool - would always contribute to the checksum. Therefore, the
Internet checksum is the preferred solution.

Best regards
- -- 

- -----------------------------------------------------------------------

---

From: James Carlson <[email-masked]>
Date: Fri, 8 Jul 2005 15:09:43 -0400

> On Friday 01 July 2005 16:32, James Carlson wrote:
[...]
> > would be the same for the Internet checksum and XOR, XOR would be the

No, I didn't write that quoted text -- nor do I know who did.  Please
be more careful when handling attributions.

Instead, I've argued that the existing Internet checksum is better.