No announcement yet.

Serial to TCP/UDP slow. HELP

  • Filter
  • Time
  • Show
Clear All
new posts

  • Serial to TCP/UDP slow. HELP

    I am trying to multiplex a number of serial ports over a LAN.
    This is the scenario:

    Port "A" at location "X" sends a message (32 bytes)
    to port "AA" at location "Y".
    Port "AA" responds with a message (32 bytes).
    Port "A" must see the last character of the message
    from port "AA" within 250 mSec of the last character
    of the message port "A" sent.
    Considering this may involve 16 serial ports at each location,
    is this possible using TCP or UDP?

    Does anyone have any ideas as to achieve the required response

    I have had limited success with TCP.
    Any help would be greatly appreciated!


  • #2
    If I have this straight, you are creating a kind of "client server" app, that has distributed clients monitoring up to 16 serial ports, and these are sending info gathered from the serial ports back to the server, which is located elsewhere on a LAN? Or are the clients communicating between each other, forming a "serverless" set of distributed clients?

    For the former, then the problem is that TCP/UDP communications could be held up by heavy network traffic load, so guaranteeing a response time is going to be out of the hands of PowerBASIC and in the hands of WinSock and/or the network software. That is, if the LAN is busy, your timing could be compromised.

    Essentially, the "mechanic's" of the app are straight forward and do-able with PowerBASIC, but guaranteeing such strict timing for relaying TCP or UDP data will be the primary concern.

    Can you divide the job down so that there is a "manager" for all 16 ports on the clients, therefore reducing the impact of network latency at the critical point. Whether this strategy could be implemented in your project will depend on what you project design permits, but without much more info on the concept behind your project, this suggestion is just a possibility. Maybe you could describe the project in more detail?

    PowerBASIC Support
    mailto:[email protected][email protected]</A>
    mailto:[email protected]


    • #3
      The object is to have 2PC's, connecting two pieces of eqipment
      sending messages over 16 serialports, multiplexed onto a
      dedicated fibre optic LAN. The only traffic will be the messages
      between the two pieces of equipment.

      Would it be faster to send a packet of data consisting of one
      character from each port or to determin the end of each message
      and (time permitting) send a packet consisting of 16 messages.



      • #4
        Well, at the packet level, you would be:
        1. Sending one packet (containing 16x 32-byte serial port data blocks)
        2. Sending 16 packets (containing 1x 32-byte serial port data block)
        3. Sending 512 packets (containig 1/32 of a data block)

        IMHO, option 1 or 2 seem the most efficient, since that would result in the lowest network overhead.

        However, the best test would be to try the options and benchmark the results...

        PowerBASIC Support
        mailto:[email protected][email protected]</A>
        mailto:[email protected]


        • #5
          I don't know if this is of any help, but I managed to squeeze about 500 messages of 1kB per second over a TCP connection on a 10Mbit network.
          It didn't help much if the packages were smaller, in my experience it's better to combine data into larger packets.

          I remember reading somewhere deep inside Microsoft documentation, that's about as much as you can expect. You can expect a maximum of about half the bandwith of your network.
          But this is not true for very small packets because they have relatively a very large overhead.

          I used API TCP functions, blocking calls because messaging would have created extra overhead.


          [email protected]
          [email protected]


          • #6
            I don't realy see why there should be any problem in any variety of ways of doing this...
            A fibre LAN is not going to hicup in 250ms with only two talkers, what's the normal ping time between the systems? <10ms I would imagine. The issues will come in managing things at the serial end to not sit and wait too long before passing the data.

            What you need to do is work on some sort of header system to control flow and possibly errors, for example have a header with the size of the payload (so you can vary it on the fly), the dest and scr ports. After that it's difficult for me to say more as I don't know what sort of data your moving or how much there is and how often it is created. ie if something is too slow (because of network trouble) can the receiving pc pass something to the serial ports waitng in lieu of the data (this would depend on the serial device etc).

            could you give me some more details

            Paul Dwyer
            Network Engineer
            Aussie in Tokyo


            • #7
              Thank you for your contributions,They were very helpfull.