From: Corey Minyard <minyard@acm.org>
To: linux-sctp@vger.kernel.org
Subject: 200ms delays with SCTP streaming data
Date: Mon, 13 Jul 2020 21:59:07 +0000 [thread overview]
Message-ID: <20200713215907.GE3235@minyard.net> (raw)
Hi, it's me again with another strange issue. In case you didn't figure
it out before, I'm working on a library that supports all different
types of stream I/O, and SCTP is one supported building block. I
noticed when I stacked a multiplexer layer on top of SCTP I started
getting timeouts occasionally. It took a bit, but I finally realized
that I was getting 200ms delays occasionally between sending a packet
and receiving a packet. I verified this with a trace right at the
sctp_send() and sctp_recvmsg() calls. It doesn't seem to be regular
in any way I can see, but it happens often enough to cause issues.
If I replace the SCTP block with a TCP block, it works fine, and pretty
much all the code is the same except where it does the read and write
calls (including the epoll() usage, and I have also switched to select()
and it has the same issue). The write calls don't seem to be the issue,
I see two back-to-back writes a few microseconds apart and see a 200ms
delay between the messages on the receive side.
The test in question sets up two connections and does a big simultaneous
bidirectional transfer. The test app has 4 threads waiting on epoll()
handling data and writing data.
And the delay is always ~200ms. Which sounds suspicious.
It's not using sctp_sendv() at the moment, as the systems I'm running on
don't have that yet. But the library does have support if it sees it is
available.
So I don't think it's my library; I've stared at it a bunch (and found a
few other bugs) but I can't reconcile this one. There are no timers
that would cause this in the code in question. Just basically an
epoll() call waiting on data and receive processing that is comparing
data, along with write processing that is sending the same data.
Anyway, I haven't tried to create a small reproducer; I thought I would
report it first and see if anything rang a bell. I tried this on a
recent kernel and got the same issue.
The library is at https://github.com/cminyard/gensio. I'd need to
provide a patch for the tracing.
-corey
next reply other threads:[~2020-07-13 21:59 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-13 21:59 Corey Minyard [this message]
2020-07-13 22:11 ` 200ms delays with SCTP streaming data Marcelo Leitner
2020-07-14 12:12 ` Corey Minyard
2020-07-14 13:10 ` Corey Minyard
2020-07-14 13:51 ` Michael Tuexen
2020-07-14 16:23 ` Corey Minyard
2020-07-14 17:30 ` Michael Tuexen
2020-07-15 13:08 ` David Laight
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200713215907.GE3235@minyard.net \
--to=minyard@acm.org \
--cc=linux-sctp@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.