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

Text archives Help


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


Chronological Thread 
  • From: "Alberto Bellettato" <alberto.bellettato AT icn.siemens.it>
  • To: <discussion AT sctp.de>
  • Subject: [SCTP-Discussion] Re: Performances of high speed data transmission
  • Date: Sat Feb 16 16:57:01 2002
  • List-id: SCTP Discussions <discussion.sctp.de>
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



Archive powered by MHonArc 2.6.19+.

Top of page