First login?
Lost password?
 
 
sctp-discussion AT lists.franken.de 
SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Re: Performances of high speed data transmission


Chronological Thread 
  • From: Michael Tuexen <Michael.Tuexen AT micmac.franken.de>
  • To: discussion AT sctp.de
  • Cc:
  • Subject: Re: [SCTP-Discussion] Re: Performances of high speed data transmission
  • Date: Sat Feb 16 17:22:01 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
Hi Alberto,

I do not have any experience with Linux because I'm using FreeBSD.
Let us concentrate on the receive buffer problem:

1. setting myrwnd in the sctplib does not have any influence on the
real recv buffer. If myrwnd is to low, you do not have optimal
performance but no message loss. If you set myrwnd to high you will
experience message loss, because the IP implementation of the
receiver will drop packets.

2. Try making the recv space for raw IP larger in the kernel, but i do
not know how to do it on Linux. I think we have Linux specific
code in adaptation.c.

Nevertheless, to achieve better throughput you have to make the receiver
window larger by doing something with the kernel and something with the
sctplib and both things have o be in tune.

Could you verify if you encounter message loss? Ethereal can help you.
If you have problems with this you could out a tracefile in the Web so
that I can download it. If think this is the best approach, because
there should be no message loss!

Best regards
Michael

On Saturday, February 16, 2002, at 04:56 PM, Alberto Bellettato wrote:

Hi All,

please read my comments.

although I am not too familiar with this implementation I can answer
your
last question. We experienced a limit (in a different implementation)
which
is imposed by the protocol depending on your RWND setting and the actual
Round Trip Time (limit=RWND/RTT). There are never more byte than RWND in
flight, and new data is only sent when SACKs arrive.

That is the case with all window based protocols, also with TCP.
It should not be a problem to increase the RWND variable (if buffers are
sufficient). It can be set as "myRwnd" in sctp_setAssocDefaults(), and
sctp_setAssocStatus() (see <sctp.h>).

However, one would also need to adapt the buffer size for raw ip sockets
as that may be a limiting factor, where packet loss could occurr (that has
already happened to me at high loads)
SO: I have net yet sufficiently tested the implementation at high loads,
but I am glad that Alberto does !

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).

In short, I would be grsteful if you, Alberto, could provide me with
the links for the necessary linux patches. As far as I have tested, I
found
that (on vanilla-linux) the standard resolution is around 20ms. So,
between
two blocking poll() calls there will be at least 20ms. That is far from
great, but most people could live with that. I know that FreeBSD can be
compiled with resolutions as low (or high :) as 1 ms, which would be nice
for
linux, too. I also know that there is a linux module rtc, but I am not
even
sure if that does what I want. Incidentally, that (20ms) test was about
a year ago, so things may have changed already....

I installed a patch named Utime, which is included in a bigger patch for
real-time Linux named KURT. After applying the KURT patch, in
"kernel-hacking" section of "make config" you can
choose to compile the kernel with "micro-second resolution". You can find
more detailed info at:

- http://www.ittc.ku.edu/utime/ (-> patch for kernel 2.2.13)

- http://www.ittc.ku.edu/kurt/ (-> patch for kernel 2.4.13 - Utime patch for
this kernel has been included in KURT package)

Alternatively to this patch you could modify the "#define HZ" in kernel
sources (it would be in param.h) from standard 100Hz (one tick every 10ms)
up to 4000 Hz, BUT you could experience problems with some processes and,
surely, general system performance will be affected due to the incremented
IRQ frequency. Then Utime patch is preferred.

However, if I understood the implementation, I think you can have benifit
from incremented system clock granularity only in a few cases, that is when
you use a blocking poll(). But if you use a non-blocking poll() as that one
in adl_getEvents(), you would not have a benefit.
I think the real limiting cause is the fact that all internal calculations
are truncated to millisecond resolution. Do you agree?

Regards,
Alberto

_______________________________________________
discussion mailing list
discussion AT sctp.de
http://www.sctp.de/mailman/listinfo/discussion


Michael.Tuexen AT micmac.franken.de



Archive powered by MHonArc 2.6.19+.

Top of page