Conference 7.286::fddi

I'm not sure that I understand what you are describing, but consider this.

The speed difference is 10 to 1, so that means that in .2 seconds you transmit
2 seconds worth of Ethernet packets.  The bridge will discard any packets that
haven't been forwarded within 2 seconds.

More or less.

Because the bridge can run an exact timer for each packet, it uses mathod that
is lost to me in the mists of time and is probably different for each major
generation of bridge, but that involves some sort of counter.

Anyway, even if it worked correctly, your 1 minute of transmits would result
in the first .2 seconds of packets being received followed by a steady state
of 1 in 10 packets being received.  Assuming the best case and no other traffic
on the Ethernet segment.  But that can't be true since its very hard to prevent
all traffic, like bridge hellos, decnet hellos, etc.  So those will result in
collisions and backoffs which will reduce the packets that get received to less
than 1 in 10, say maybe 1 in 20 or 1 in ???.

So, lets say that the algorithm in the bridge is not capable of producing the
best possible forwarding rate, or let's say the implementation is broken.

What's the different between getting 5% of the traffic and getting 0%?

When going over links that vary in speed, you need to use a protocol that
adapts to the speed and buffering of the least capable widget in the path.
While some beleive that rate base flow control can be made to work, I'm
confident that you can always find a "typical" network that will blow a rate
based scheme out of the water, so that leaves only window and/or credit based
flow control.

Now from a testing point of view, I'm curious what 10-100 bridge you're actually
using.  And what is the EXACT configuration on the Ethernet side.  And what
revs of firmware in the bridge.

    Found out what was going on when sending with a single transmitter from
    an Ethernet (EtherWorks Turbo EISA (DE425-AA) to a PCI - FDDI DEFPA
    via a DECNIS. If the DECNIS gets into a situation where it can't
    transmit its bridge hello messages it will stop forwarding on that port
    to prevent the possibility of bridging loops.  With one transmitter on
    saturating the Ethernet, the DECNIS could not get a word in edgewise.
    
    I am going to try an experiment with two Ethernet transmitters to see
    if the resultant collisions will allow the DECNIS to sneek in its hello
    messages.
    
    As to the FDDI to Ethernet loss, I'm going to try increasing the bridges
    buffer size from the default size of 100 packets to 65K packets to
    see what impact that has.
    
    Ultimately, I think I'll have to add flow control to the custom protocol
    I'm devloping.  Due network traffic issues, the protocol sends
    sequence numbered packets broadcast to multiple receivers. Only when a
    receiver detects a missing packet sequence number does it send a
    request to the sender for a retransmit.  We cannot accept the network
    traffic overheadof sending a positive acknoledgement from each
    receiver.
    
    I was thinking of either having a send backoff for a transmitter which
    is sending to a node on a slower LAN or a self tuning backoff based on
    a receiver getting above a threshold number of retransmit requests
    within a given time. The former approach is easyier to implement but
    suffers from the problem of multiple transmitters coliding when each
    thought it was sending what it thought was a resonable rate to the
    slower LAN.
    
    
    Thank you very much for your 1836.1 reply.  It was extreamly well
    thought out and presented
    
    Mike Thomas