Chronological Thread 

< Chronological >      < Thread >

---

Dear all,

see my comments below.

Best regards
Michael

Michael Tuexen Tel.: +49 89 722 47210
Siemens AG Fax: +49 89 722 48212
ICN WN CS SE 5 E-mail:
Michael.Tuexen AT icn.siemens.de

> -----Original Message-----
> From: Brian F. G. Bidulock
> [SMTP:bidulock AT openss7.org]
> Sent: Monday, February 18, 2002 11:32 AM
> To: Andreas Jungmaier
> Cc:
> discussion AT sctp.de;
> Alberto Bellettato
> Subject: Re: [SCTP-Discussion] Re: Performances of high speed data
> transmission
>
> 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.
>
[Tuexen Michael] We do not do memory locking. But with
enough RAM you do not swap. I have used 128 MB and there were
no page faults.
> 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).
[Tuexen Michael] We have not experienced page faults but our
memory management is NOT optimized. The prototype is not performance
optimized at all.

> 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.
[Tuexen Michael] When using our sctplib you can't use
poll.

> o The user-space implementation may cause the process
> to yeild through over-agressive use of mutexes,
> locks and semaphores.
>
[Tuexen Michael] The plain sctplib does not use mutexes,
semaphores or that. Only the socketapi implementation does.
> 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 ¦
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• RE: [SCTP-Discussion] Re: Performances of high speed data transmi ssion, Tuexen Michael, 02/18/2002

---

Archive powered by MHonArc 2.6.19+.