[ntp:questions] Re: Tinker and tos configuration commands....
David L. Mills
mills at udel.edu
Wed Feb 9 15:17:33 UTC 2005
Terje,
I beg to differ. The IP checksum is vulnerable to byte swap and reorder.
The most common error in the old days was with the venerable IMP11-A
interface for the PDP11. It was a 16-bit interface with a byte-swap
switch. It often was set to the wrong position, with result the bytes
were swapped in error, but not caught by the checksum. Sure, it was fast
to compute and my 16-bit PDP11 programs did that. The real challenge,
however, was doing a 16-bit checksum calculation on a 36-bit machine
like TOPS20 or Multics. Many a grad studen worked out a deliciously
intricate way to to a 16-bit checksum of a span of 36-bit words.
Dave
Terje Mathisen wrote:
> David L. Mills wrote:
>
>> Terje,
>>
>> +0 == -0 == 0 == +0.0 == -0.0 == 0.0 in logical comparisons, no matter
>> how you represent it, presuming of course that the integer to double
>> conversions are done first before comparison. That's all I care about.
>
>
> OK, no problem. In that case (i.e. never using bitwise operations
> directly on the number representation) using sign+magnitude or
> ones-complement would also work for integers.
>
>>
>> Once upon a time when checksums were expensive we did a terrible
>> thing. The ones-complement Internet checksum actually does have two
>> zeros. One of course is used to reprent a correct checksum, but other
>> was used to disable the checksum calculation itself. Wow, that goes
>> back a long way.
>
>
> The IP checksum is/was a wonderful algorithm: It is endian-independent,
> very quick to calculate even on trivial hardware/software, and history
> have shown that it still catches errors committed by things like
> Ethernet card FIFOs and bus drivers.
>
> We've discussed this several times over the last 10+ years in
> news:comp.arch, and the reality is that for packet reception at least,
> it is effectively free, and even sending is free unless you have a
> totally copy-free scatter/gather implementation.
>
>> The Univac 1100 series used ones-complement arithmetic and that drove
>> me batty.
>
>
> Been there, done that: I wrote my very first non-trivial program on an
> 1100. I started by writing a set of arbitrary precision math routines,
> and then used them to calculate pi with as many digits as I could manage
> within the 60 cpu seconds allotment to first year university students. :-)
>
> This was using Fortran 2, but with a C compiler and unsigned integer
> arithmetic, all of our favorite binary properties are guaranteed to work
> independently of the actual representation.
>
>
>>
>> Dave
>>
>> Terje Mathisen wrote:
>>
>>> David L. Mills wrote:
>>>
>>>> Brad,
>>>>
>>>> No, signs of zero disappeared with the Univac 1108 and ones
>>>> complement arithmetic and notwithstanding the Internet checksum.
>>>> Zero is a legitimate state variable. Twos complement arithmetic is
>>>> the sole survivor. Fudge values have nothing to do with it.
>>>
>>>
>>>
>>>
>>> Actually, that's only true for binary integer operations.
>>>
>>> FP otoh is always sign+biased_exponent+mantissa these days, since
>>> that's required by the relevant IEEE standard (754?).
>>>
>>> Terje
>>>
More information about the questions
mailing list