- From: Alberto Bellettato <alberto.bellettato AT icn.siemens.it>
- To: discussion AT sctp.de
- Subject: [SCTP-Discussion] Performances of high speed data transmission
- Date: Thu Feb 14 13:17:01 2002
- List-id: SCTP Discussions <discussion.sctp.de>
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
- [SCTP-Discussion] Performances of high speed data transmission, Alberto Bellettato, 02/14/2002
Archive powered by MHonArc 2.6.19+.