Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #28843
| 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> |
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
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