In article <[log in to unmask]>,
 Hansang Bae <[log in to unmask]> writes:
|>
|>
|> "Al" <[log in to unmask]> writes:
|> >We had no disconnection problems before when we had Hubs instead of these
|> >switches. We are only getting them in the last couple of weeks. We are
|> >monitoring the switch port that goes into a Hub which itself connects into
|> >the thinnet via a BNC. We get something like 2000 collisions each hour on
|> >this port.  I am thinking getting rid of the thinnet and putting our old
|> >928s directly on the switches. But I no experience of these 3Ks boxes on a
|> >switched network.
|>
|>
|> 2000 collisions in an of itself is completely meaningless.  My guess is
|> that you had more in the past, but you just weren't looking.  Just make
|> sure that your switch port isn't been swamped and that flow control is
|> turned of as appropriate.  Since this port is being connected to a hub,
|> locking the switch port to half duplex would be a must.  I'm not
|> familiar with the 928's or the 3K boxes you're alluding to so I can't
|> speak about ti.
|>
Just to add another aspect: Running partially switched networks today
is a drag anyway. You loose the inherent flow-control of the collision
domain and the net gets more unfair than before. Consider the following
scenario: Eight stations want so send a 32k window of data to one or more
stations on a particular segment. As long as all segments are repeated,
one station will win, send its window and thereafter every station
has a fair chance of accessing the medium. If these 8 stations happen
to connect to switched ports and send to a shared segment, the switch
will buffer the data and as soon as it gets its turn will send out
250k of data. Due to the capture effect most likely in one attempt.
Any station on this segment that tries to send a packet within this
250ms timeframe has a (at least) 50% chance to suffer an excessive
collison and thus will experience an application layer timeout.

--
Manfred Kwiatkowski         [log in to unmask]