Chronological Thread 

< Chronological >      < Thread >

---

Alberto,

Kernel implementations tend to yield higher throughputs. When
comparing TCP against sctplib, remember that TCP is a kernel
implementation and sctplib is user-space.

On our openss7 LiS STREAMS implementation we are pulling maximum
throughputs on the order of 30000 32-byte packets per second on
100Mb/s for an effective throughput of 7.68Mb/s. So, while there
is a higher tax associated with SCTP, it is still possible to
acheive comparable performance with a kernel implementation of
SCTP.

For user-space implementations there are a number of other things
that you must consider when attempting such performance tests:

o User space implementations use VM for buffer space.
This means that there is a good chance that pages
might swap. IMBW, but I don't believe that sctplib
has memory locking considerations.

One way to avoid this would be to have sctplib lock
its buffer space in memory.

o Depending on the memory allocation scheme within the
user-space library, malloc and free could cause a
page fault, resulting in the user-space process
losing the processor.

A way to stop this is to run the process at a higher
priority or under a different scheduling algorithm
(e.g. RTC).

o User space implementations may have different than
expected reactions to things like poll() and
setitimer(). Careful that the mechanisms you use in
your test program are not harmfully interacting with
the library.

An example of a problem here is using setitimer to
time a loop while disrupting the library's use of
the signal.

o The user-space implementation may cause the process
to yeild through over-agressive use of mutexes,
locks and semaphores.

Not much you can do there.

In general, it is rather difficult to treat a user-space
implementation in the same manner as you treat existing kernel
implementations of TCP and UDP. If you are looking for high
performance, kernel implementations are the way to go.

--brian

On Mon, 18 Feb 2002, Andreas Jungmaier wrote:

> Alberto, all,
>
> On Saturday, 16. February 2002 16:56, Alberto Bellettato wrote:
> > I tried to increment RWND ("myRwnd"), but I did not obtain a performance
> > increment. I did not set the buffer size for raw ip sockets, I will try
> > it.
> > But I think the problem do not reside in it, considering that, using a
> > 100Mb/s link, a normal ftp session (supposed to have a similar default ip
> > buffer size) can achieve more than 10Mb/s, while my test is limited to
> > less
> > than 2Mb/s (8000 messages/s = 8000 * 20Bytes * 8 = 1,28Mb/s).
> >
> Please also take into account the overhead you get in that situation.
> What you put on the link with SCTP is a lot more than 8000*20 Bytes, if
> messages are not bundled, whereas TCP uses 1460 Bytes Payload per packet.
>
> So, you need to compute the absolute link load for SCTP and TCP, and
> compare these. Might look a little better for our implementation, which
> after all is still a prototype :-)
>
> Best regards,
> Andreas
>

--
Brian F. G. Bidulock ¦ The reasonable man adapts himself to the ¦
bidulock AT openss7.org
¦ world; the unreasonable one persists in ¦
http://www.openss7.org/ ¦ trying to adapt the world to himself. ¦
¦ Therefore all progress depends on the ¦
¦ unreasonable man. -- George Bernard Shaw ¦

---

• [SCTP-Discussion] Re: Performances of high speed data transmission, Alberto Bellettato, 02/16/2002
  • Re: [SCTP-Discussion] Re: Performances of high speed data transmission, Michael Tuexen, 02/16/2002
  • Re: [SCTP-Discussion] Re: Performances of high speed data transmission, Andreas Jungmaier, 02/18/2002
    • Re: [SCTP-Discussion] Re: Performances of high speed data transmission, Brian F. G. Bidulock, 02/18/2002
      • Re: [SCTP-Discussion] Re: Performances of high speed data transmission, Andreas Jungmaier, 02/18/2002

---

Archive powered by MHonArc 2.6.19+.