Chronological Thread 

< Chronological >      < Thread >

---

Dear all,
See by 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: Andreas Jungmaier
> [SMTP:ajung AT exp-math.uni-essen.de]
> Sent: Thursday, February 14, 2002 5:13 PM
> To:
> discussion AT sctp.de;
> Benedict Rainer; 'Alberto Bellettato'
> Cc:
> 'discussion AT sctp.de'
> Subject: Re: AW: [SCTP-Discussion] Performances of high speed data
> transmissio n
>
> -----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 !
[Tuexen Michael] On a FreeBSD system you can set the raw socket space
with sysct before using the sctplib. The sctplib will then use this
value
automatically. [Tuexen Michael] If the raw IP recv space is not in
tune
with the SCTP parameters you will encounter message loss.
> 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....
[Tuexen Michael] On FreeBSB you use the HZ option in the kernel
config file.
> 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+ibe97tymZ7GCbB> 5Q84SOc=
> =E5MH
> -----END PGP SIGNATURE-----
> _______________________________________________
> discussion mailing list
> discussion AT sctp.de
> http://www.sctp.de/mailman/listinfo/discussion

---

• RE: AW: [SCTP-Discussion] Performances of high speed data transmi ssio n, Tuexen Michael, 02/14/2002

---

Archive powered by MHonArc 2.6.19+.