Serial to TCP/UDP slow. HELP

[John Hutchins]

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
times?

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


------------------

[Lance Edmonds]

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?



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

[John Hutchins]

Lance,
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.



------------------

[Lance Edmonds]

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...

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

[Peter Manders]

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.


Peter.


------------------
[email protected]

[Paul Dwyer]

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

[John Hutchins]

Thank you for your contributions,They were very helpfull.


------------------