Serial (rs232 etc.) to IP

On 26 Oct 2005 06:38:42 -0700, cs_posting@hotmail.com wrote:

>If your serial link is fast, you probably don't want to put each
>character in it's own packet, instead wait a short amount of time and
>then send as many characters as you have collected from the serial
>line. 

..and by doing this also ruin the serial line throughput when a half
duplex protocol is used with short message frames. Some converters
wait 10-100 ms after the last serial character received, before the
(TCP or UDP) IP-frame is sent. For instance at 115200 bit/s, this
corresponds to 100-1000 character times.

Paul

On 2005-10-26, Paul Keinanen <keinanen@sci.fi> wrote:
> On 26 Oct 2005 06:38:42 -0700, cs_posting@hotmail.com wrote:
>
>>If your serial link is fast, you probably don't want to put
>>each character in it's own packet, instead wait a short amount
>>of time and then send as many characters as you have collected
>>from the serial line. 
>
> ..and by doing this also ruin the serial line throughput when
> a half duplex protocol is used with short message frames. Some
> converters wait 10-100 ms after the last serial character
> received, before the (TCP or UDP) IP-frame is sent. For
> instance at 115200 bit/s, this corresponds to 100-1000
> character times.

There's always going to be an throughput efficiency vs. latency
tradeoff when doing Async<->Ethernet.  You should pick a
product that allows you to control this tradeoff (or if it
doesn't, make sure the designer chose a tradeoff that matches
your requirements).

-- 
Grant Edwards                   grante             Yow!  Yow! I'm imagining
                                  at               a surfer van filled with
                               visi.com            soy sauce!

Paul Keinanen wrote:
> On 26 Oct 2005 06:38:42 -0700, cs_posting@hotmail.com wrote:
>
> >If your serial link is fast, you probably don't want to put each
> >character in it's own packet, instead wait a short amount of time and
> >then send as many characters as you have collected from the serial
> >line.
>
> ..and by doing this also ruin the serial line throughput when a half
> duplex protocol is used with short message frames. Some converters
> wait 10-100 ms after the last serial character received, before the
> (TCP or UDP) IP-frame is sent. For instance at 115200 bit/s, this
> corresponds to 100-1000 character times.

This is a valid concern, however there's a bit of a problem with single
character packets when many common embedded TCP devices try to talk to
common desktop operating systems.

TCP requires that you hang onto all outgoing data until it has been
acknowledged, because if it's not acknowledged you will have to resend
it.  Most embedded implementations handle this by sending a packet, and
then being unable to send another until the first has been
acknowledged.  The Windows TCP stack often takes as much as 200 ms to
acknowledge a packet when only one is outstanding, so single character
packets can be slowed down to the rate of only five per second!

There are a number of fixes.  You can hit windows with a bogus ack
right after you send it a packet and it will acknowledge yours.  That
gets you down into the 10 ms per packet regime, but then you are still
going to be collecting at least 10 ms worth of incoming serial
characters before each packet you send (no need for a delay, just when
you get the ack packetise and send everything that came in while you
were waiting on the ack).

A smarter method would be to keep better track of what has not been
acknowledged, so that you can have multiple outstanding packets and not
have to wait for the ack before you can send another.  But most of the
other wise turnkey implementations - OpenTCP for example - don't do
that.

ok,
   Heres a link to an example configuration page from NetBurner for a
customizable
device using arbitrary TCP ports ... however they imply that PORT 23 is
used to sense a connection from the IP network side... so that implies
telnet delivers data to the serial unit, and comms from the serial unit
go to an "arbitrary" port ... in this case 1000.

 http://www.netburner.com/products/processors/sb70/SB70config.htm

  I was aware of the "ack" aspect, hence single char mode.

  If anybody has any other experience/wisdom ... pipe up.

TIA,
-D

On 26 Oct 2005 10:57:55 -0700, cs_posting@hotmail.com wrote:

>> ..and by doing this also ruin the serial line throughput when a half
>> duplex protocol is used with short message frames. Some converters
>> wait 10-100 ms after the last serial character received, before the
>> (TCP or UDP) IP-frame is sent. For instance at 115200 bit/s, this
>> corresponds to 100-1000 character times.
>
>This is a valid concern, however there's a bit of a problem with single
>character packets when many common embedded TCP devices try to talk to
>common desktop operating systems.
>
>TCP requires that you hang onto all outgoing data until it has been
>acknowledged, because if it's not acknowledged you will have to resend
>it.  Most embedded implementations handle this by sending a packet, and
>then being unable to send another until the first has been
>acknowledged.  The Windows TCP stack often takes as much as 200 ms to
>acknowledge a packet when only one is outstanding, so single character
>packets can be slowed down to the rate of only five per second!

If you are using a protocol that was initially written for serial line
communication with normal CRC checks and timeout controls, why bother
with TCP, just use simple UDP. If the UDP frame is lost, let the
original serial line protocol timeout mechanism handle any missing
data.

Paul

Paul Keinanen wrote:

> If you are using a protocol that was initially written for serial line
> communication with normal CRC checks and timeout controls, why bother
> with TCP, just use simple UDP. If the UDP frame is lost, let the
> original serial line protocol timeout mechanism handle any missing
> data.

Yes, if you are using such a protocol.  But most common serial devices,
be they lab test equipment, printers, modems, or whatnot do not use
such a protocol all of the time, though users may be in the habit of
using one (XMODEM or something) when corruption is intolerable.

In packet switched networks it is permissable to drop packets just
because you "don't feel like passing them on right now".  In most
point-to-point serial, the practical assumption is of quite high
reliability, usually interrupted only by total failure.

When that's not true - with really noisy phone lines... 1200 baud
dialup in Moscow circa '92... error correcting packetized protocols
such as MNP made sense for interactive user sessions.  You just had to
get used to typing far ahead of the several retries necessary to get
the packetized half-duplex echo through.

packer44@hotmail.com wrote:

>    Heres a link to an example configuration page from NetBurner for a
> customizable
> device using arbitrary TCP ports ... however they imply that PORT 23 is
> used to sense a connection from the IP network side... so that implies
> telnet delivers data to the serial unit, and comms from the serial unit
> go to an "arbitrary" port ... in this case 1000.

There's arbitrary (you pick one you like) and then there's arbitrary
(it gets dynamically assigned).

Because your device may not be literally running a telnet service, you
might want to pick a port other than telnet's port 23 to listen on.  In
some cases, client computers may even not be able to access some
traditional low port numbers.  For a custom function you might want to
pick something slightly over 1024.  If you want to use a telnet client
to open an interactive test session to your device, you specify the
port number in addition to the IP address to the program, and you do
something similar with the operating system call to open a TCP session
if you are building it into a program.

When you connect to the device, it then picks a port to reply to you
on... you don't have to worry much about that part unless you are
building the TCP stack from scratch.  Just worry about picking the
device's listen port/

packer44@hotmail.com wrote:
> Could anyone lend some light into which protocol or technique is used
> to actually send I/O from a legacy serial port device onto a TCP/IP
> network?

There is no specific protocol that is always used for serial to IP transfer.
In the case of our products there are several solutions depending on what you
want to achieve:
- Proprietary protocol over UDP packages combined with a virtual COM-port
driver to give the application the illusion it is directly connected to the
serial device.
- Telnet, which a few others already mentioned.
- PPP to enable Internet access for a device that does have an IP stack but no
network card.

-- 
M.I.K.e

Tauno Voipio wrote:

[X]

> 
> For an entirely private use, pick the
> port from 49152 - 65535.
> 

I remember my first "private TCP protocol". I chose a port number easy 
to remember and within the above range; so I picked yymmd, which is the 
day I was born. So you now know I am between 40 and 56 years old...

Paul Keinanen wrote:
> On 26 Oct 2005 10:57:55 -0700, cs_posting@hotmail.com wrote:
> 
> 
>>>..and by doing this also ruin the serial line throughput when a half
>>>duplex protocol is used with short message frames. Some converters
>>>wait 10-100 ms after the last serial character received, before the
>>>(TCP or UDP) IP-frame is sent. For instance at 115200 bit/s, this
>>>corresponds to 100-1000 character times.
>>
>>This is a valid concern, however there's a bit of a problem with single
>>character packets when many common embedded TCP devices try to talk to
>>common desktop operating systems.
>>
>>TCP requires that you hang onto all outgoing data until it has been
>>acknowledged, because if it's not acknowledged you will have to resend
>>it.  Most embedded implementations handle this by sending a packet, and
>>then being unable to send another until the first has been
>>acknowledged.  The Windows TCP stack often takes as much as 200 ms to
>>acknowledge a packet when only one is outstanding, so single character
>>packets can be slowed down to the rate of only five per second!
> 
> 
> If you are using a protocol that was initially written for serial line
> communication with normal CRC checks and timeout controls, why bother
> with TCP, just use simple UDP. If the UDP frame is lost, let the
> original serial line protocol timeout mechanism handle any missing
> data.
> 

This has at least one problem: these serial line protocols usually 
assume that packets arrive in order. This makes sense for these 
protocols (I cannot imagine a message jumping over the previous one and 
reaching its destiny sooner than the other), but not for IP packets.