| [email protected] writes:
>Title: Tulip excessive collison again...
>we are experiencing a problem like that one in note 373.*
>He, has excessive ethernet collisions when copying files with ftp between
>the two systems,
"Excessive collisions" is something entirely different than what was
discussed in the other two threads. An excessive collision is declared
when a sender gives up after 16 tries. For the TCP connections in the
other threads, the sender generally doesn't tie up the wire long enough
for excessive collisions to be a significant problem.
So you may have a different problem than those threads. You might hunt
down ttcp and do some measurements with that instead of trying to
infer from NSR behaviour the similarities with the old cases.
and he had timeout problem during network backup so the
>backup procedure is aborted. I think he made backups with NSR.
If NSR opens several TCP connections, then things might get interesting.
Also if it NSR uses reqquest/response protocol instead of streaming
a lot of data, it could behave somewhat differently than the cases
studied in the old threads.
>I have red the discussions about Tulip on note 373 and 1873 but
>they aren't very clear for me.
Unfortunately, some of those postings are about a clear as they get. If
you watch the traffic with a Sniffer or tcpdump (see note 2328) you'll
get a much better feel for Ethernet dynamics.
>In there any solution to this problem ?
There's a very good paper from Canada suggesting changes to Ethernet to avoid
the capture effect, but that doesn't apply to your situation.
>Is the behaviour of the Tulip chip right ?
As far as I know.
--
<> Eric (Ric) Werme <> This space under reconstruction <>
<> <[email protected]> <> <>
[posted by Notes-News gateway]
|
|
Yes, excessive collisions are a drag, but the Tulip is conforming the
the Ethernet spec. It does turn out that chips that don't conform to
the Ethernet spec (take a longer Inter Packet Gap) can perform better
than chips that try to transmit as soon as possible. The point of
contention occurs immediately after a transmit completes when several
adapaters (that respect the specified Inter Packet Gap) will all start
transmitting therefore causing a collision, jam, and random exponential
backoff.
If you have a switch, why not run the Alpha servers in full duplex
mode? You'd get no collisions in full duplex.
netstat -s -Itu0 will show more details about the collision counters.
|