Hi Max, > On Jul 25, 2019, at 5:51 AM, Max A. <max1...@mail.ru> wrote: > > Hi Florin, > > > As explained above, as long as the sender is faster, this will happen. Still, > out of curiosity, can you try this [1] to see if it changes linux’s behavior > in any way? Although, I suspect the linux’s window probe timer, after a zero > window, is not smaller than min rto (which is the 200 ms you’re seeing). > > [1] https://gerrit.fd.io/r/c/20830/ <https://gerrit.fd.io/r/c/20830/> > > Unfortunately, nothing has changed [1].
Oh well, zero window probe timer is the same 200ms. > > Therefore, is the data read by the application much faster or is the > advertised rcv window unrelated to the amount of data buffered? Obviously, if > the latter, the actual buffer is larger than what you’ve configured. Also, > does mtcp act as proxy in this case as well? > > The mtcp application works as a simple wget client. That’s an important difference because in case of the proxy, you cannot dequeue the data from the fifo before you send it to the actual destination and it gets acknowledged. That means, you need to wait at least one rtt (to the final destination) before you can make space in the fifo. If the final destination consuming the data is slower than the sender, you have an even bigger problem. Try doing a simple wget client, builtin or with vcl, and you’ll note that data should be dequeued much faster than in the proxy case. You could improve the 200ms by forcing an ack out of the proxy to the sender once you get an ack from the receiver (this is what empties up space in the rx fifo on the sender side). But for that you need to monitor acks and push window updates. This works only if data is freed faster than the 200ms linux uses for probing. If you need to avoid that, to support the maximum throughput in proxy scenarios, you need to increase fifo sizes. > > The problem is not that we are slowly sending data, but that we are slowly > receiving data from the Linux stack, causing it to pause for 0.2 seconds. At > the same time, vpp reports errors like “Segment not in the receive window”. Probably the not in the receive window is generated by the last segment that fills the window. I’ll look into it once I have a bit of time, but in your case it doesn’t make too much of a difference, unfortunately. Florin > > > [1] https://drive.google.com/open?id=1pC8yeQyldyysuloSc8rulhVC9Y0xs-Qr > > -- > Max A.
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#13582): https://lists.fd.io/g/vpp-dev/message/13582 Mute This Topic: https://lists.fd.io/mt/32582078/21656 Group Owner: vpp-dev+ow...@lists.fd.io Unsubscribe: https://lists.fd.io/g/vpp-dev/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
