TCP/UDP for deterministic safety system - TCP-IP

This is a discussion on TCP/UDP for deterministic safety system - TCP-IP ; 1) Is ethernet even suitable here? Trying to evaluate the use of ethernet TCP/IP (or UDP/IP) as a comms upgrade for an existing industrial safety monitor system. The topology is a daisy-chain of maybe twenty monitor stations all connected to ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 35

Thread: TCP/UDP for deterministic safety system

  1. TCP/UDP for deterministic safety system

    1) Is ethernet even suitable here?

    Trying to evaluate the use of ethernet TCP/IP (or UDP/IP) as a comms
    upgrade for an existing industrial safety monitor system. The topology
    is a daisy-chain of maybe twenty monitor stations all connected to a
    master PC. This is currently done with RS485 using a simple multi-drop
    half-duplex scheme where all stations are slaves to the master. Each
    station has an upstream port (to master) and a downstream port (to more
    slaves). The master polls each slave in turn (a broadcast). Each slave
    only responds if it sees its address. Slaves don't talk to each other.
    This is a dedicated network. The packet size is less than 100 bytes and
    max data rates are on the order of 19200baud.

    There are some legacy items that cannot easily be changed, such as the
    basic topology and the master-slave polling. It might make more sense to
    use a star topology with each station connected directly to a
    hub/switch, but this isn't going to happen. If I just think about
    ethernet physical & link layer I see no problems, but at the network
    layer I start to wonder how each device would need to be configured and
    what protocol makes sense. Whatever protocol is used should be supported
    by standard PC architecture using an ethernet card, and a standard APIs
    library.

    2) Details about protocols and configuration?

    I think each monitor station would need the functionality of a 2-port
    switch (upstream,downstream and internal port) such as an SMSC LAN9311
    might provide. I only need a hub, so there may be a better chip.

    I don't need much in the way of a protocol stack. Most of the features
    of the stack are things I can't use (see #3). Along with ethernet
    physical & data link layer support, all I really need is the ability to
    send & receive small data packets. There is no routing requirement since
    there is really just one link. Every message could be a broadcast. This
    mimics how it works right now. I was thinking UDP or IPX. TCP/IP stack
    components are the obvious choice since I wouldn't need to create a
    custom protocol.

    3) What about determinism?

    Several people have pointed out that TCP is not deterministic with all
    sorts of timeouts and delays. I do need some guaranteed bounded response
    times (1/4 second link response). I thought one way to address this
    would be to use UDP to avoid those automatic retries and associated
    timeouts. The PC master would probably broadcast, and each station could
    also broadcast. I would need to be able to disable features which could
    lead to non-deterministic behavior. Does this cover everything? If not
    is IPX or another protocol a better choice?

    thoughts?




  2. Re: TCP/UDP for deterministic safety system


    tns1 wrote:

    > I think each monitor station would need the functionality of a 2-port
    > switch (upstream,downstream and internal port) such as an SMSC LAN9311
    > might provide. I only need a hub, so there may be a better chip.


    You cannot daisy chain 10 switches and you definitely cannot daisy
    chain 10 hubs.

    Ideally, I would redesign and dump a lot of the legacy "features".

    If you can't do that, one suggestion would be to put two normal
    Ethernet net ports on each machine.

    A machine watches its upstream port for polls. If it sees a poll, it
    sends it to its downstream port and starts a timer. If no response in
    a certain amount of time, it sends its own report upstream. If it does
    receive a report from downstream, it adds its report onto it (if it
    will fit) and passes it upstream. If it will not fit, it passes the
    report upstream as a partial report and passes its own report upstream
    next. You need a 'final bit' in the report.

    The master sends polls downstream periodically and will receive a
    complete report of all connected machines automatically. You may or
    may not want each machine to immediately send an upstream acknowledge
    to a report. One advantage is this speeds up "end of the line"
    detection.

    A machine can also cache whether it's the end of the line or not. Or
    you can just use link heartbeat to do this.

    One huge problem with Ethernet for this -- if a machine is off, all
    machines downstream of it will be unreachable.

    DS

  3. Re: TCP/UDP for deterministic safety system

    David Schwartz wrote:
    > tns1 wrote:
    >
    >> I think each monitor station would need the functionality of a 2-port
    >> switch (upstream,downstream and internal port) such as an SMSC LAN9311
    >> might provide. I only need a hub, so there may be a better chip.

    >
    > You cannot daisy chain 10 switches and you definitely cannot daisy
    > chain 10 hubs.


    I see this discussed in the literature with the reason being 'the signal
    will degrade'. Not sure why this is. AFAIK hubs are not just wire
    connections, but are signal repeaters. I would guess that what is
    degrading then is timing - pulses are getting stretched or compressed
    with some additional delay added at each hub. Doesn't a switch retime
    the frame anyway, or do you need a full MAC/PHY to do this?

    I suppose it does not matter since I am not going to go to a lot of
    trouble to make a square peg fit a round hole. Still, I have to believe
    that if I went out and purchased a bunch of serial to ethernet
    converters, they would work in this topology. If not, why not? What am I
    missing?

    >
    > Ideally, I would redesign and dump a lot of the legacy "features".
    >
    > If you can't do that, one suggestion would be to put two normal
    > Ethernet net ports on each machine.
    >

    The chip I mentioned uses a full MAC/PHY for each port.

    > A machine watches its upstream port for polls. If it sees a poll, it
    > sends it to its downstream port and starts a timer. If no response in
    > a certain amount of time, it sends its own report upstream. If it does
    > receive a report from downstream, it adds its report onto it (if it
    > will fit) and passes it upstream. If it will not fit, it passes the
    > report upstream as a partial report and passes its own report upstream
    > next. You need a 'final bit' in the report.
    >

    Trying to understand why this is different from the hub/switch scheme.
    Are you saying that instead of passing along a message from the original
    master, each station must repackage the message as if it were the
    master? And this gets around the daisy-chain problem?

    > The master sends polls downstream periodically and will receive a
    > complete report of all connected machines automatically. You may or
    > may not want each machine to immediately send an upstream acknowledge
    > to a report. One advantage is this speeds up "end of the line"
    > detection.
    >


  4. Re: TCP/UDP for deterministic safety system

    On Aug 7, 1:54*pm, tns1 wrote:

    > Trying to understand why this is different from the hub/switch scheme.
    > Are you saying that instead of passing along a message from the original
    > master, each station must repackage the message as if it were the
    > master? And this gets around the daisy-chain problem?


    Yes, exactly.

    You cannot chain hubs because the timing degrades. You cannot chain
    switches because the delay exceeds the collision detection algorithm's
    ability.

    In principle, I don't think there's any reason chaining full-duplex
    switches would in fact cause a problem. But the standard treats all
    switches the same. The problem is that the packet may collide on the
    far end, after the near end has finished sending it. How can the near
    end know that the packet collided when it's already done?

    If you want to use Ethernet and can't use a star topology, you do not
    want an Ethernet bridge or switch. You want logically separate
    Ethernet segments with your CPU acting as a bridge for your protocol.

    DS

  5. Re: TCP/UDP for deterministic safety system

    David Schwartz wrote:
    > On Aug 7, 1:54 pm, tns1 wrote:
    >
    >> Trying to understand why this is different from the hub/switch scheme.
    >> Are you saying that instead of passing along a message from the original
    >> master, each station must repackage the message as if it were the
    >> master? And this gets around the daisy-chain problem?

    >
    > Yes, exactly.
    >
    > You cannot chain hubs because the timing degrades. You cannot chain
    > switches because the delay exceeds the collision detection algorithm's
    > ability.
    >
    > In principle, I don't think there's any reason chaining full-duplex
    > switches would in fact cause a problem. But the standard treats all
    > switches the same. The problem is that the packet may collide on the
    > far end, after the near end has finished sending it. How can the near
    > end know that the packet collided when it's already done?
    >
    > If you want to use Ethernet and can't use a star topology, you do not
    > want an Ethernet bridge or switch. You want logically separate
    > Ethernet segments with your CPU acting as a bridge for your protocol.


    OK, so far this makes sense. What about this claim that "switches can be
    cascaded...without limit"? The wording seems to imply half-duplex, but
    maybe not. http://www.ctrlink.com/producthelp.htm

  6. Re: TCP/UDP for deterministic safety system

    In article , tns1 wrote:

    >3) What about determinism?
    >
    >Several people have pointed out that TCP is not deterministic with all
    >sorts of timeouts and delays. I do need some guaranteed bounded response
    >times (1/4 second link response). I thought one way to address this
    >would be to use UDP to avoid those automatic retries and associated
    >timeouts. The PC master would probably broadcast, and each station could
    >also broadcast. I would need to be able to disable features which could
    >lead to non-deterministic behavior. Does this cover everything? If not
    >is IPX or another protocol a better choice?
    >
    >thoughts?


    You cannot have both what you seem to mean by determinism and error
    recovery. Errors, device hiccups, broken cables, and other network
    communications problems *will* happen. When they do happen, either
    your system crashes or it doesn't know what's going on for a while.
    When network problems happen, information will be delayed randomly
    by random durations, which doesn't sound very "deterministic."

    What is your system going to do if it does not get an answer with
    0.25 seconds? Whatever it does is a minor implementation detail,
    whether it closes and tries to restore TCP/IP connections, uses UDP
    retransmissions, or gives up and just hopes that a subsequent UDP
    broadcast will get through.

    You need to do a competent job of engineering, including estimating
    the probabilities of all error cases and deciding what will happen.


    One of my old pet peeves is that idiots and dishonest salescritters are
    still, in 2008, blathering in the trade rags and elsewhere about
    the supposed lack of determinism of 802.3, even today with FDX and
    without CSMA/CD and so no random collision backoffs. In practice
    and in theory CSMA/CD was no more "non-deterministic" than token
    protocols, because stations could hold the token while sending lots
    of data, tokens could get lost, and so forth. Undesirable stuff happens
    to network data, and when it does, things get "non-deterministic."
    A competent engineer acknowledges that fact and deals with it.


    Vernon Schryver vjs@rhyolite.com

  7. Re: TCP/UDP for deterministic safety system

    On Aug 7, 4:03*pm, David Schwartz wrote:
    > You cannot chain hubs because the timing degrades.



    Fine.


    > You cannot chain
    > switches because the delay exceeds the collision detection algorithm's
    > ability.



    No.

    Switches, aka bridges*, hard separate the collision domains on either
    side of the switch/bridge. There is no such thing as a collision that
    can be detected across a switch/bridge. They cannot be prevented
    either, if half duplex links are being used - the very last switch/
    bridge port might decide to transmit just as the node connected to
    that port does. But that has nothing to do with transmissions and/or
    collisions on any other segment.

    There is not a hard limit to the maximum diameter of a switched
    network in 802.1d, but some of the timers (used for setting up the
    spanning tree) are sized to assume no more than seven hops with all
    other parameters at the worst case. Certainly people have set up
    networks with more hops than that, and if they're in a nice straight
    line you probably have some slack to work with. In the OP's case, he
    might choose not to implement 802.1d at all, and just forward packets
    based on the sender's MAC (or something known in the packet) - IOW, if
    the sender is the host node, keep propagating until the end of the
    line. Otherwise, always propagate it towards the host's end of the
    line. And that you can do forever.

    The OP might consider something more along the lines of traditional
    (thick) or thin Ethernet if he doesn't want to require a functional
    active device at each node to allow communications all down the
    line.


    *Just to forestall the debate - a switch *is* a bridge, "switch" is
    simply the now fashionable marketing term for bridge. And not that
    some low-end switches do not actually implement 802.1d, and have a
    limited ability to be chained together because of that.

  8. Re: TCP/UDP for deterministic safety system

    Vernon Schryver wrote:
    > In article , tns1 wrote:
    >
    >> 3) What about determinism?
    >>
    >> Several people have pointed out that TCP is not deterministic with all
    >> sorts of timeouts and delays. I do need some guaranteed bounded response
    >> times (1/4 second link response). I thought one way to address this
    >> would be to use UDP to avoid those automatic retries and associated
    >> timeouts. The PC master would probably broadcast, and each station could
    >> also broadcast. I would need to be able to disable features which could
    >> lead to non-deterministic behavior. Does this cover everything? If not
    >> is IPX or another protocol a better choice?
    >>
    >> thoughts?

    >
    > You cannot have both what you seem to mean by determinism and error
    > recovery. Errors, device hiccups, broken cables, and other network
    > communications problems *will* happen. When they do happen, either
    > your system crashes or it doesn't know what's going on for a while.
    > When network problems happen, information will be delayed randomly
    > by random durations, which doesn't sound very "deterministic."
    >
    > What is your system going to do if it does not get an answer with
    > 0.25 seconds? Whatever it does is a minor implementation detail,
    > whether it closes and tries to restore TCP/IP connections, uses UDP
    > retransmissions, or gives up and just hopes that a subsequent UDP
    > broadcast will get through.
    >


    Lost messages are OK. The existing protocol (over RS485) has its own
    proven algorithm and it decides when a link is down. The valid response
    or the (rare) error can both determined within a bounded time. I
    wouldn't expect the ethernet physical layer to be any more error prone
    than the existing system. What isn't acceptable is handing off a message
    to a black box that has a large timeout I can't control, or automatic
    retries I don't know about and can't disable.

    > You need to do a competent job of engineering, including estimating
    > the probabilities of all error cases and deciding what will happen.
    >
    >
    > One of my old pet peeves is that idiots and dishonest salescritters are
    > still, in 2008, blathering in the trade rags and elsewhere about
    > the supposed lack of determinism of 802.3, even today with FDX and
    > without CSMA/CD and so no random collision backoffs.


    How do I guarantee full-duplex operation vs half-duplex? Can I just buy
    any new adapter card for 'baseT with a new switch and get this
    automatically, or is there special equipment, special settings?

    In practice
    > and in theory CSMA/CD was no more "non-deterministic" than token
    > protocols, because stations could hold the token while sending lots
    > of data, tokens could get lost, and so forth. Undesirable stuff happens
    > to network data, and when it does, things get "non-deterministic."
    > A competent engineer acknowledges that fact and deals with it.
    >
    >
    > Vernon Schryver vjs@rhyolite.com


  9. Re: TCP/UDP for deterministic safety system

    On Aug 7, 3:13*pm, "robertwess...@yahoo.com"
    wrote:

    > Switches, aka bridges*, hard separate the collision domains on either
    > side of the switch/bridge. *There is no such thing as a collision that
    > can be detected across a switch/bridge. *They cannot be prevented
    > either, if half duplex links are being used - the very last switch/
    > bridge port might decide to transmit just as the node connected to
    > that port does. *But that has nothing to do with transmissions and/or
    > collisions on any other segment.


    You cascade 20 switches. They are all locked in cut-through switching
    mode, locked at half-duplex, at locked the same speed. Each switch
    begins a cut-through 128-bytes into the packet. If the packet is, say,
    1400 bytes, if a collision occurs between switches 18 and 19, switch 1
    will already have finished sending the packet. There is no way it can
    report the collision to the packet originator.

    If two packets originate concurrently at opposite ends of the network,
    they may well collide "in flight" in the middle of the chain. Both
    packets will be lost.

    Now you might say "nobody would chain 20 cut-through switches in half-
    duplex mode". That's true. But it proves that the generic switching
    architecture does not guarantee that unlimited switch cascades are
    safe.

    DS

  10. Re: TCP/UDP for deterministic safety system

    robertwessel2@yahoo.com wrote:
    ....
    > In the OP's case, he
    > might choose not to implement 802.1d at all, and just forward packets
    > based on the sender's MAC (or something known in the packet) - IOW, if
    > the sender is the host node, keep propagating until the end of the
    > line. Otherwise, always propagate it towards the host's end of the
    > line. And that you can do forever.


    This sounds like the way to go. If I understand it, on the stations I
    would need a custom driver or to write an API for direct access to the
    ethernet MAC, unless whatever TCP/IP stack implementation I end up with
    already has this kind of low-level interface. What about on the PC
    master? There probably isn't a way to support this scheme with a
    standard API is there?

    >
    > The OP might consider something more along the lines of traditional
    > (thick) or thin Ethernet if he doesn't want to require a functional
    > active device at each node to allow communications all down the
    > line.
    >

    This would mimic how the current system works (data still passes thru
    dead stations), but would require working with coax instead of nice
    flexible UTP.

  11. Re: TCP/UDP for deterministic safety system

    On Aug 7, 6:55*pm, David Schwartz wrote:
    > On Aug 7, 3:13*pm, "robertwess...@yahoo.com"
    > wrote:
    >
    > > Switches, aka bridges*, hard separate the collision domains on either
    > > side of the switch/bridge. *There is no such thing as a collision that
    > > can be detected across a switch/bridge. *They cannot be prevented
    > > either, if half duplex links are being used - the very last switch/
    > > bridge port might decide to transmit just as the node connected to
    > > that port does. *But that has nothing to do with transmissions and/or
    > > collisions on any other segment.

    >
    > You cascade 20 switches. They are all locked in cut-through switching
    > mode, locked at half-duplex, at locked the same speed. Each switch
    > begins a cut-through 128-bytes into the packet. If the packet is, say,
    > 1400 bytes, if a collision occurs between switches 18 and 19, switch 1
    > will already have finished sending the packet. There is no way it can
    > report the collision to the packet originator.
    >
    > If two packets originate concurrently at opposite ends of the network,
    > they may well collide "in flight" in the middle of the chain. Both
    > packets will be lost.



    This can, and does, happen with plain old bridges. Cut-through makes
    it a bit more likely. In neither case is there any sort of collision
    detection/avoidance/whatever that extends past a switch or bridge
    port. IOW, this can happen on even a single switch hop.

    OTOH, a cut-through port will, and must, buffer if the next hop is
    busy. Whether or not a given switch buffers packets even in the event
    of a cut-thorough so that it can retransmit after a collision varies
    between implementation, but if it does not, as many early cut through
    switch did not, there is a clear increase in the risk of packet loss
    due to collisions.

    Also, cut through Ethernet switches are now fairly rare. Five years
    ago they were basically non-existent, but they're making a bit of a
    comeback, at least at the high end.


    > Now you might say "nobody would chain 20 cut-through switches in half-
    > duplex mode". That's true. But it proves that the generic switching
    > architecture does not guarantee that unlimited switch cascades are
    > safe.



    Neither is a chain of 20 bridges, or one.

  12. Re: TCP/UDP for deterministic safety system

    On Aug 7, 6:23*pm, tns1 wrote:
    > How do I guarantee full-duplex operation vs half-duplex? Can I just buy
    > any new adapter card for 'baseT with a new switch and get this
    > automatically, or is there special equipment, special settings?



    Most current Ethernet cards do support FDX, but read the specs to make
    sure, some of the old (and slow) ones that have been on the market for
    years do not. Low end switches often do not, but again, it'll be in
    the specs. In theory the specs actually allow HDX operation of
    Gigabit Ethernet, but I don't think I've ever seen a GigE part that
    didn't support FDX, so if you buy anything that supports GigE, it
    should support FDX.

    While probably irrelevant to the task at hand, HDX is not supported at
    all by 10GigE (IOW, everything is full duplex).

    In theory it should be as simple as connecting a FDX capable Ethernet
    card to a FDX capable switch port, they *should* auto negotiate FDX
    mode, but that's an area where more than a few bugs have shown up over
    the years. Most devices can have the mode forced. That has been
    getting better in the last few years, although you still see it pop up
    on occasion. Mostly that happens at slower speeds (less than GigE)
    where FDX is optional.


  13. Re: TCP/UDP for deterministic safety system

    On Aug 7, 7:28*pm, tns1 wrote:
    > robertwess...@yahoo.com wrote:
    > > In the OP's case, he
    > > might choose not to implement 802.1d at all, and just forward packets
    > > based on the sender's MAC (or something known in the packet) - IOW, if
    > > the sender is the host node, keep propagating until the end of the
    > > line. *Otherwise, always propagate it towards the host's end of the
    > > line. *And that you can do forever.

    >
    > This sounds like the way to go. If I understand it, on the stations I
    > would need a custom driver or to write an API for direct access to the
    > ethernet MAC, unless whatever TCP/IP stack implementation I end up with
    > already has this kind of low-level interface. What about on the PC
    > master? There probably isn't a way to support this scheme with a
    > standard API is there?



    On Windows you can definitely do this by slipping in at the NDIS
    layer, and I think you can do it with a TDI Filter driver. OTOH, you
    probably don't care at the host, since all the bridges will appear off
    the end of that cable. IOW, the fact that you have a slightly odd
    bridging protocol (or specifically an odd bridge route determinate
    protocol) still leaves the bridges themselves invisible to the hosts.

    Linux has hooks as well.



    > > The OP might consider something more along the lines of traditional
    > > (thick) or thin Ethernet if he doesn't want to require a functional
    > > active device at each node to allow communications all down the
    > > line.

    >
    > This would mimic how the current system works (data still passes thru
    > dead stations), but would require working with coax instead of nice
    > flexible UTP.



    Well, you're already doing some custom stuff, but it's not actually
    required to run shared medium Ethernet over coax. You will have to
    knock the speed down to do it. For example the old StarLAN1 did just
    that - basically 1Mb Ethernet over Cat-1 twisted pair - it could be
    run over both busses and hubs (like later 10baseT), and combinations
    of the two. If you can forgo collision detection (for example, the
    host always polls the downstream nodes), that gets a lot easier, and
    you can get better distances. But you are drifting a ways off
    commodity parts here.

    A partial solution that involves a bit of a hack would be to design
    each node so that it physically switches itself of of the conga line
    of nodes by directly connecting the downstream and upsteam ports
    togeather if the node is not active, or power is off, or whatever. A
    few carefully selected PMOS and NMOS transistors should be able to
    switch the node from an "inserted" to "bypass" state without too much
    grief. Or use a nice relay (and if shock and vibration arenít huge
    issues, Iím serious).


  14. Re: TCP/UDP for deterministic safety system

    In article
    ,
    David Schwartz wrote:

    > On Aug 7, 1:54*pm, tns1 wrote:
    >
    > > Trying to understand why this is different from the hub/switch scheme.
    > > Are you saying that instead of passing along a message from the original
    > > master, each station must repackage the message as if it were the
    > > master? And this gets around the daisy-chain problem?

    >
    > Yes, exactly.
    >
    > You cannot chain hubs because the timing degrades. You cannot chain
    > switches because the delay exceeds the collision detection algorithm's
    > ability.


    Isn't each segment connected to a network of switches a separate
    collision domain? That's the difference between repeaters and
    switches/bridges -- collision detection propagates through repeaters,
    not switches or bridges.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  15. Re: TCP/UDP for deterministic safety system

    On Aug 7, 11:35*pm, Barry Margolin wrote:

    > Isn't each segment connected to a network of switches a separate
    > collision domain? *That's the difference between repeaters and
    > switches/bridges -- collision detection propagates through repeaters,
    > not switches or bridges.


    Yes, exactly my thought. These would be, if anything, switches rather
    than hubs, and by the way, the old restriction of 10 switches
    (default) max value in longest spanning tree path is no longer
    applicable with RSTP.

    But that shouldn't be an issue anyway.

    If the OP had a working RS-485 network as he described, it can be made
    to work exactly the same way using UDP/IP over Ethernet. I see no
    problems at all, unless I missed something along the way.

    First of all, IN PRINCIPLE, although not in practice anymore, the same
    daisy chain topology required with RS-485 could be repeated using
    10BASE2 Ethernet. In practice, these days, I would very simply use a
    single switch. Feed every slave and the single master from that one
    switch. The survivability aspects of this are no worse than they were
    in RS-485.

    Secondly, the master would be the only host in the network initiating
    the requests. And this being UDP/IP, to emulate more exactly the
    orevious RS-485 network, the system would be EXACTLY as deterministic
    as the RS-485 network was. There are no ACK packets here. The reply to
    the master is an inherent acknowledgment.

    Thirdly, whatever scheme was used in the RS-485 network, to
    accommodate late or missing replies from the slaves, would transfer
    over to this network unchanged. If it worked with RS-485, it will work
    with this simple UDP/IP master-slave setup just as well.

    Bert

  16. Re: TCP/UDP for deterministic safety system

    On Aug 7, 8:35*pm, Barry Margolin wrote:

    > Isn't each segment connected to a network of switches a separate
    > collision domain? *That's the difference between repeaters and
    > switches/bridges -- collision detection propagates through repeaters,
    > not switches or bridges.


    There is a huge difference between what optimizations bridges
    typically bring you and what switches are guaranteed by standards to
    do. Switches *typically* isolate collisions as an optimization, but
    are not guaranteed to (and cannot always) do so.

    For example, if an output port on a switch is experiencing a large
    number of collisions due to high traffic from more than one input
    port, the switch may have no choice but to either propagate those
    collisions back to the source port or to drop packets. In fact, a
    switch may have no choice but to intentionally create collisions where
    there are none or drop packets on the floor.

    DS

  17. Re: TCP/UDP for deterministic safety system

    On Aug 8, 3:03*pm, David Schwartz wrote:

    > For example, if an output port on a switch is experiencing a large
    > number of collisions due to high traffic from more than one input
    > port, the switch may have no choice but to either propagate those
    > collisions back to the source port or to drop packets. In fact, a
    > switch may have no choice but to intentionally create collisions where
    > there are none or drop packets on the floor.


    What you are describing is merely a form of L2 flow control. If a port
    becomes overwhelmed with traffic from upstream hosts, it can either
    drop of push back. For backpressure, if the port is set to half
    duplex, the switch can use the trick you describe. Otherwise, in full
    duplex mode, it can use PAUSE frames. The effect is the same.

    But this packpressure is not a CSMA/CD topology limit, as you got with
    hubs, or an STP limit,as you got with the older STP algorithm. There
    is no problem emulating the RS-485 scheme the OP described. There
    would never be an issue with overwhelming a switch port with traffic.

    Bert



  18. Re: TCP/UDP for deterministic safety system

    On Aug 8, 1:42*pm, Albert Manfredi wrote:

    > What you are describing is merely a form of L2 flow control. If a port
    > becomes overwhelmed with traffic from upstream hosts, it can either
    > drop of push back. For backpressure, if the port is set to half
    > duplex, the switch can use the trick you describe. Otherwise, in full
    > duplex mode, it can use PAUSE frames. The effect is the same.


    What I'm saying is that a switch might isolate collisions as an
    optimization, or it might propagate them for flow control. It is not a
    guaranteed feature of every switch that a collision on one port will
    never trigger a collision on another port.

    Relying on a switch to create separate collision domains is like
    relying on a switch to not let one node see another node's unicast
    packets. It might do it some or most of the time, but it might not
    always do so unless you specifically configure it to do so. Almost all
    switches do this most of the time, but you can never rely on it
    happening automatically. You must assume it doesn't happen unless you
    assure otherwise.

    > But this packpressure is not a CSMA/CD topology limit, as you got with
    > hubs, or an STP limit,as you got with the older STP algorithm. There
    > is no problem emulating the RS-485 scheme the OP described. There
    > would never be an issue with overwhelming a switch port with traffic.


    The possibility of a late collision (after the originating machine has
    finished transmitting the packet) causing a packet to get lost *is* a
    topology limit with switches. Whether that affects the OP or not is
    not immediately obvious. If he really only ever has one packet in
    flight, I think he's safe practically. But there is nothing in the
    hard and fast topology rules that says anything about that case. This
    is a "seems to be okay" and "can't think of how it could fail" case,
    not a "the standards say this must work" case.

    DS

  19. Re: TCP/UDP for deterministic safety system

    On Aug 9, 1:57*am, David Schwartz wrote:

    > > But this packpressure is not a CSMA/CD topology limit, as you got with
    > > hubs, or an STP limit,as you got with the older STP algorithm. There
    > > is no problem emulating the RS-485 scheme the OP described. There
    > > would never be an issue with overwhelming a switch port with traffic.

    >
    > The possibility of a late collision (after the originating machine has
    > finished transmitting the packet) causing a packet to get lost *is* a
    > topology limit with switches.


    No, I don't think that's the case. A late collision could possibly
    occur at one port of a switch, e.g. if that port is set to half duplex
    and connected to an excessively long a series of hubs. Or if that port
    is set to half duplex and the Ethernet segment of that port is way too
    long (could occur in 100BASE-TX). However, across the switch to
    another port, there can be no danger of late collisions. The switch
    isolates the domains between ports, assuming we all agree that
    "switch" means "layer 2 bridge," and is not some random name given to
    any type of fan-out device.

    Another way to say it is that hosts attached to different ports of a
    switch do not have to do carrier sensing of hosts at other ports of
    the switch. If set to half duplex, the ONLY carrier sensing a given
    host has to worry about is from hosts (including the switch) connected
    to it's SAME switch port. This is because the Ethernet frames are
    buffered in the switch. They are fully sucked in from the upstream
    port before being sent out the downstream port. You don't need to
    ensure an empty catenet from source host to sink host when bridges are
    in the path.

    > Whether that affects the OP or not is
    > not immediately obvious. If he really only ever has one packet in
    > flight, I think he's safe practically.


    Which apparently is the case. In an RS-485 network, that's not an
    unusual setup. Using UDP/IP over Ethernet, this should be a piece of
    cake. TCP could be a different matter, possibly, depending on things
    like the time between queries from the master. If the queries are
    infrequent, should be no problem with TCP.

    Bert

  20. Re: TCP/UDP for deterministic safety system

    Albert Manfredi wrote:
    > On Aug 9, 1:57 am, David Schwartz wrote:
    >
    >>> But this packpressure is not a CSMA/CD topology limit, as you got with
    >>> hubs, or an STP limit,as you got with the older STP algorithm. There
    >>> is no problem emulating the RS-485 scheme the OP described. There
    >>> would never be an issue with overwhelming a switch port with traffic.

    >> The possibility of a late collision (after the originating machine has
    >> finished transmitting the packet) causing a packet to get lost *is* a
    >> topology limit with switches.

    >
    > No, I don't think that's the case. A late collision could possibly
    > occur at one port of a switch, e.g. if that port is set to half duplex
    > and connected to an excessively long a series of hubs. Or if that port
    > is set to half duplex and the Ethernet segment of that port is way too
    > long (could occur in 100BASE-TX). However, across the switch to
    > another port, there can be no danger of late collisions. The switch
    > isolates the domains between ports, assuming we all agree that
    > "switch" means "layer 2 bridge," and is not some random name given to
    > any type of fan-out device.
    >
    > Another way to say it is that hosts attached to different ports of a
    > switch do not have to do carrier sensing of hosts at other ports of
    > the switch. If set to half duplex, the ONLY carrier sensing a given
    > host has to worry about is from hosts (including the switch) connected
    > to it's SAME switch port. This is because the Ethernet frames are
    > buffered in the switch. They are fully sucked in from the upstream
    > port before being sent out the downstream port. You don't need to
    > ensure an empty catenet from source host to sink host when bridges are
    > in the path.
    >
    >> Whether that affects the OP or not is
    >> not immediately obvious. If he really only ever has one packet in
    >> flight, I think he's safe practically.

    >
    > Which apparently is the case. In an RS-485 network, that's not an
    > unusual setup. Using UDP/IP over Ethernet, this should be a piece of
    > cake. TCP could be a different matter, possibly, depending on things
    > like the time between queries from the master. If the queries are
    > infrequent, should be no problem with TCP.
    >
    > Bert

    Yes, just one packet in flight. The RS485 network uses a shared medium -
    one twisted pair for both tx&rx traffic. All traffic uses the same
    modulation - NRZ, so half-duplex is a real physical restriction even
    with only one host and one slave. If I understand it, 'baseT always uses
    separate twisted pairs for tx&rx, even in half-duplex mode.

    This brings up some questions on possible wiring.
    If using a shared utp medium will actually work for me and still let me
    use UDP/IP, then my first thought was I would wire it so that all slave
    transmitters tap directly onto the master receiver twisted pair, and
    visa-versa for the master transmitter pair. Wired like this, slaves
    can't 'read' each other's transmissions, and could never talk to one
    another directly. Packets could still collide if the slaves did not obey
    the protocol rule, "speak only when you are spoken to".

    This is one difference in the single pair RS485 network since everyone
    sees everyone else's transmissions. I think an ethernet PHY could be
    wired up just like this using a single pair. I don't see any advantage,
    but it would still work wouldn't it?

    Both of these ideas assume each station has a single transceiver tapping
    directly onto a shared medium (one or two pairs). The upstream and
    downstream RJ45 ports of each station would be wired directly together
    (or use simple signal repeater buffering).

    The alternative to this is like I originally proposed where each
    upstream/downstream port has its own active MAC/PHY. Cost and complexity
    is greater, so I wouldn't do this unless I had to. When would I have to?







    cable could be made which would


+ Reply to Thread
Page 1 of 2 1 2 LastLast