Chronological Thread 

< Chronological >      < Thread >

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,

please see my comments below:

On Thursday, 14. February 2002 13:46, Benedict Rainer wrote:
> Hello Alberto,
>
> 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 !

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

In short: I would like a solution that works with Realtime-Enabled
Linux as well (or even better) as a normal, out-of-the-box kernel,
but not worse than now. Microsecond resolution (internally) is fine,
however, I will keep the external library interface (as described
in <sctp.h>) as it is.

Comments ?

Andreas

> > -----Ursprüngliche Nachricht-----
> > Von: Alberto Bellettato
> > [mailto:alberto.bellettato AT icn.siemens.it]
> > Gesendet am: Donnerstag, 14. Februar 2002 13:15
> > An:
> > discussion AT sctp.de
> > Betreff: [SCTP-Discussion] Performances of high speed data
> > transmission
> >
> > Hi All,
> > I am trying to evaluate performances in a high speed data
> > transmission using
> > SCTPlib implementation (pre16).
> > In particular I need to transmit data at speed values greater
> > than 1000
> > messages per second and up to the maximum rate (20-100 Bytes
> > long messages). For example, supposing the maximum rate is
> > 20000 messages
> > per second, it means a trasmission of one data message even every 50
> > microseconds.
> > I got no problems in generating this high data rates in the
> > Upper Layer (I
> > mean data rate used to put data messages in the send queue of
> > SCTP layer);
> > obviously this values are machine dependent, but using a PIII
> > 650Mhz even
> > the value of 50 microsecond is allowed. But the problem
> > raises in the rate
> > that is measured at the receiving machine: I can not exceed
> > the ~8000 msg/s
> > value. Moreover this test is not repetible, because I got
> > different results
> > and some times I experienced malfunctions and even
> > segmentation faults.
> > So where is the problem? I think It resides in the SCTP
> > implementation.
> > Infact all timer alarms are approximated to 1 millisecond (see
> > get_msecs_tonexttimer() in timer_list.c (row 348 in pre16) and
> > adl_getEvents() in adaptation.c (row 492 in pre16)). So when
> > I send data
> > more frequently than one message every 1 millisecond, the
> > implementation
> > does not distinguish this values, and it works using a "best
> > effort" policy,
> > whose efficiency is machine dependent.
> > I wonder if an alarm timers' calculation based on a
> > microsecond estimation
> > is
> > realizable. I could modify functions in adaptation.c and
> > timer_list.c in
> > order to handle a microsecond resolution. I suppose that this
> > approach has
> > not been followed in the implementation creation because of required
> > compliance with low speed machines.
> > But is it possible to create a machine-specific
> > implementation which uses a
> > microsecond resolution for timer alarms evaluation? Is there
> > any problem I
> > do not consider?
> > In order to minimize system clock granularity I installed
> > UTime patch for
> > linux kernel 2.4.13 (shipped with KURT real-time patch); it reduces
> > granularity from Linux standard 10 milliseconds down to the order of
> > microseconds.
> > I have installed it in order to obtain an optimized system
> > for fast data
> > transmission, but using a single istance of SCTP it would not give a
> > performance increment. Infact, if I understand correcty the
> > implementation,
> > all timer alarms are based on gettimeofday() measurements,
> > which refers to
> > Time Stamp Counter present in many CPUs (Pentium and above);
> > then system
> > clock granularity does not influence performance of a single istance
> > (granularity applied to alarms of the linux-system scheduler
> > of processes
> > should be significant only if there would be more istances,
> > i.e. processes).
> >
> > Am I mismatching any crucial node?
> > Could you comment on my considerations and questions?
> >
> > Has anyone tested high data rate transmission in a real-time
> > system (with an
> > SCTP implementation developed for it)? Is there a maximum
> > rate caused by
> > SCTP protocol?
> >
> > Thank you very much in advance.
> >
> > Alberto Bellettato
> > Developing grad. thesis at Univers. of Parma
> > On stage at Siemens ICN
> >
> >
> > _______________________________________________
> > discussion mailing list
> > discussion AT sctp.de
> > http://www.sctp.de/mailman/listinfo/discussion
>
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

- --
- ------------------------------------------------------------------------
Dipl.-Ing. Andreas Jungmaier | _
Computer Networking Technology Group | ASCII ribbon campaign ( )
University of Essen | - against HTML email X
http://www.exp-math.uni-essen.de/~ajung | & vcards / \
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8a+HuXAsLBNOCSsARApfDAJ9RnE6YvkYJ6r++0LqonfQ8hd7drwCggNjK
R+ibe97tymZ7GCbB5Q84SOc=
=E5MH
-----END PGP SIGNATURE-----

---

• AW: [SCTP-Discussion] Performances of high speed data transmissio n, Benedict Rainer, 02/14/2002
  • Re: AW: [SCTP-Discussion] Performances of high speed data transmissio n, Andreas Jungmaier, 02/14/2002

---

Archive powered by MHonArc 2.6.19+.