[Soekris] Strange problem with net4801

Henry Spencer henry at spsystems.net
Wed Jan 19 03:11:52 UTC 2005


On Wed, 19 Jan 2005, Horst Laschinsky wrote:
> > Do not use cables with shielding on both sides. either unshielded,
> > or shield connected to ground on only one end.
> 
> What the f...? That worked! Can anyone explain me why? Up to now,
> I always thought the sole reason for the existance of common grounds
> was to _avoid_ disturbances???

Unfortunately, when machines are a fair ways apart, or plugged into
different electrical circuits... there may not be such a thing as a common
ground.  There may be a noticeable voltage difference between "ground" on
one machine and "ground" on the other, and any shielded cable which hooks
both ends of the shield to ground will be carrying significant current
through the shield (as part of a "ground loop"), which causes various
problems.  Grounding problems can make otherwise well-behaved data links
do *very* strange things.

Standard (twisted-pair) Ethernet connections have no DC continuity from
one machine to the other -- the signalling is all transformer-coupled.
It's important to preserve that property if you insist on using shielded
cable (despite superstitition, the unshielded cable specified in the
Ethernet specs works just fine even in very noisy environments; there
is *no technical requirement* for a shield).  Ground the shield only at
one end.

The original (D/I/X) coax-cable Ethernet explicitly specified that the
coax shield was *not* to be grounded, anywhere.  Grounding it in one place
is preferable, yes -- and in fact this part of the spec got modified in
later iterations, for safety reasons -- but it's far too easy for a
"ground in one place" spec to produce multiple grounds in practice. 

> > The 4801 has a 233MHz CPU. you will experience some limitations here.
> 
> Of course I may. But is a 233MHz CPU really so slow, that it cannot
> transfer data at 100MBit (or at least 40-50 MBit) 3des encrypted?

Think about it.  At 100Mbit, a 233MHz CPU has less than 20 CPU cycles to
encrypt each byte.  Granted that some operations can be done on multiple
bytes simultaneously, 3DES is still deadly slow in software -- DES was
designed for hardware implementation.  You just can't do 3DES in 20 cycles
per byte; that's maybe a factor of 5 too few, even if all other CPU
overheads are negligible.  (And that assumes one-way transmission, too;
double it for full-duplex.)

On the FreeS/WAN project a few years ago, we were seeing raw 3DES
encryption running at 1.6MB/s on an MMX-200.  The 3DES code may be a
little better now, but probably not a lot -- that was already well-tuned
x86 assembler.  The CPUs may be a little better too.  But there are
limits.  I don't think you're going to fill, or even half-fill, a 100Mbit
pipe with 233MHz software 3DES.  With AES, or hardware assist, maybe.

                                                          Henry Spencer
                                                       henry at spsystems.net




More information about the Soekris-tech mailing list