Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.arch.embedded > #28843

Re: High packet rate ethernet with LwIP

From David Brown <david.brown@hesbynett.no>
Newsgroups comp.arch.embedded
Subject Re: High packet rate ethernet with LwIP
Date 2019-09-22 23:24 +0200
Organization A noiseless patient Spider
Message-ID <qm8oqa$udn$1@dont-email.me> (permalink)
References <nnd$46f32a8f$5fab99bf@bacadb246ebd9154> <qm5kv1$de2$1@dont-email.me> <383doedvggdj2k8kji5uoqucpp3ldf98s2@4ax.com> <qm76hh$v3i$1@dont-email.me> <v8aeoetf4sa6b4877iq9t3dp3nosm6eus7@4ax.com>

Show all headers | View raw


On 22/09/2019 10:29, upsidedown@downunder.com wrote:
> On Sun, 22 Sep 2019 09:06:24 +0200, David Brown
> <david.brown@hesbynett.no> wrote:
> 
>> On 21/09/2019 23:01, upsidedown@downunder.com wrote:
>>> On Sat, 21 Sep 2019 19:00:16 +0200, David Brown
>>> <david.brown@hesbynett.no> wrote:
>>>
>>>> On 20/09/2019 18:27, Stef wrote:
>>>>> For transportation of several high speed serial ports, we want to use a
>>>>> serial over ethernet approach. At a minimum I need to transfer four ports
>>>>> with 512 byte packets that come in every 40 ms at 2 Mbps.
>>>>
>>>> If you can consider USB instead of Ethernet, an FTDI 4232H chip will
>>>> handle 4 ports at 3 Mbps without trouble.
>>>>
>>>> But there are no limits in LWIP speed for what you need.  I have run a
>>>> board with a Modbus TCP/IP server handling 6 simultaneous connections
>>>> each with a transaction (request and reply) every millisecond - far more
>>>> packets than you need here.
>>>
>>> That is essentially a half duplex environment with inherit flow
>>> control. So if there is some congestion issues, it will clear sooner
>>> or later.
>>>
>>
>> It is half duplex on each connection, but full duplex overall (you can
>> receive a request on one connection while sending out a reply on
>> another, and there is always other traffic such as ARP or broadcasts
>> flying around).  That is always the case with TCP/IP and Ethernet.
> 
> While it is legal for the Modbus/TCP client to send out multiple
> request to a single server, without first waiting for response for
> previous requests, there are some practical maximum number of
> outstanding request If not otherwise but at least when the client send
> window is full (request not TCP/IP acknowledged by the server TCP/IP
> stack).

The clients here were multiple independent processes on the same PC. 
This is perfectly reasonable for any type of TCP/IP service.  On the 
server side, being a single core processor, it is entirely possible to 
have multiple requests waiting, though only one request is processed at 
a time.  And of course only one request packet could be coming in on the 
Ethernet MAC at a time (multiple packets could be in-flight, buffered at 
switches along the way from the client to the server).

> 
> On the server side, if there are performance issues, it should
> artificially delay the responses, thus ultimately forcing the client
> to suspend the next request. 

I was not pushing requests as fast as I could - they were being sent at 
approximately 1 ms intervals from each client.

> When receiving requests from multiple
> clients, the TCP/IP stack should not acknowledge a request, until
> there are Rx buffers available or when the Modbus/TCP server is ready
> to handle next Modbus request/reply sequence,

Of course incoming packets are delayed if there are no Rx buffers 
available.  But 6 buffers are all that are needed for 6 simultaneous 
connections (plus a buffer or two for "noise" Ethernet packets).

The Modbus server code sees there is a request from a client, processes 
it, generates a reply, and sends that out to the LWIP stack.  These 
replies are buffered, and passed out through the MAC when it is free.

> 
> All this reduces throughput during a congestion, but at least
> maintains link sanity.

The link has a bandwidth ceiling - 100 Mbps total, the processor has 
speed limits for handling the packets, and there is a limit to the LWIP 
buffers.  Unlimited links are hard to find.


I am afraid I don't see where you are going with this.  My point was 
merely to show that an LWIP based microcontroller card can handle a 
great deal more throughput of packets than the OP needed for his use - 
LWIP itself is not the limitation he feared.

> 
>>
>>> The OP did not specify if those 2 Mbit/s streams had some kind of flow
>>> control. If not, a congestion problem could cause an overflow and
>>> possibly lockup.
>>
>> Of course he needs to support the UART side of this with the four
>> channels coming in - I assumed that much was obvious, and that he could
>> handle that side of the problem easily enough.  And I also assumed that
>> there is no problem with a bit of variable latency on the transmission
>> of packets through the system and over the Ethernet, otherwise the whole
>> idea is infeasible.
> 
> If there is no flow control on the serial side, then this is a _hard_
> realtime case, so the system *must* respond to a request no matter
> what, before the next packet arrives, in this case 40 ms. 

We have no information about what flow control there might be, or what 
real-time and latency requirements there might be (and hard time limits 
are independent from flow control - no flow control does not imply hard 
timing requirements).

> In some
> cases it might be possible to do some buffering on the serial side,
> but the buffer size needs to be large to survive longer hiccups.

Obviously.

> Anyway, the high level system design must know, how to handle overload
> issues (alarming, freezing, interpolation etc.) in case of failure.

Also obvious.

I think it is fair to assume that the OP is aware of such things until 
he indicates otherwise.  He merely wants to know if his throughput 
problems are due to a limitation of LWIP, or if LWIP can be configured 
to improve the throughput here.

> 
> 
>>> Anyway, I did not notice that the packets came with such low duty
>>> cycle, so even a 10baseT connections should be able to handle four
>>> streams even with TCP/IP  even with some retransmissions, provided
>>> that a missed frame is reacted upon in less than 40 ms.
>>>
>>
>> Yes.  It should be entirely possible, without pushing anything to its
>> limits.
>>
> 

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-20 18:27 +0200
  Re: High packet rate ethernet with LwIP upsidedown@downunder.com - 2019-09-20 21:20 +0300
    Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-23 10:37 +0200
      Re: High packet rate ethernet with LwIP Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-09-23 14:08 +0300
      Re: High packet rate ethernet with LwIP Richard Damon <Richard@Damon-Family.org> - 2019-09-23 07:13 -0400
        Re: High packet rate ethernet with LwIP Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2019-09-23 18:55 +0300
      Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-23 14:04 +0200
        Re: High packet rate ethernet with LwIP Dimiter_Popoff <dp@tgi-sci.com> - 2019-09-23 17:03 +0300
          Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-23 18:37 +0200
            Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-24 14:22 +0200
              Re: High packet rate ethernet with LwIP upsidedown@downunder.com - 2019-09-25 07:55 +0300
                Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-25 09:51 +0200
                Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-25 16:03 +0200
                Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-25 11:59 +0200
                Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-25 13:16 +0200
              Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-25 09:42 +0200
                Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-25 13:41 +0200
                Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-25 14:10 +0200
                Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-25 15:22 +0200
      Re: High packet rate ethernet with LwIP upsidedown@downunder.com - 2019-09-23 22:26 +0300
        Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-23 22:16 +0200
          Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-23 23:08 +0200
  Re: High packet rate ethernet with LwIP Joe Chisolm <jchisolm6@earthlink.net> - 2019-09-20 13:44 -0500
    Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-23 10:46 +0200
  Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-21 19:00 +0200
    Re: High packet rate ethernet with LwIP upsidedown@downunder.com - 2019-09-22 00:01 +0300
      Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-22 09:06 +0200
        Re: High packet rate ethernet with LwIP upsidedown@downunder.com - 2019-09-22 11:29 +0300
          Re: High packet rate ethernet with LwIP David Brown <david.brown@hesbynett.no> - 2019-09-22 23:24 +0200
        Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-23 11:10 +0200
    Re: High packet rate ethernet with LwIP Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2019-09-23 11:03 +0200

csiph-web