Chronological Thread 

< Chronological >      < Thread >

---

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.

regards
Rainer


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

---

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