SCTP Discussions

Text archives Help


Re: [SCTP-Discussion] Implementation bugs?


Chronological Thread 
  • From: Andreas Jungmaier <ajung AT exp-math.uni-essen.de>
  • To: discussion AT sctp.de, "Alberto Bellettato" <abell AT libero.it>
  • Subject: Re: [SCTP-Discussion] Implementation bugs?
  • Date: Mon Nov 26 13:47:00 2001
  • List-id: SCTP Discussions <discussion.sctp.de>
  • Organization: University Essen

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

Hello Alberto,

currently we are (still) trying to implement some outstanding feature
requests, such as the retrieval functions.
Then we will release pre15 as soon as possible, so I will try
to fix the bugs you have discovered for that release.

> 1) Under the following conditions I got a 'Segmentation fault' error.
> An association has been established between 2 multihomed hosts (each one
> has 2 interfaces that are connected 2 by 2 through a direct cross-cable).
> Initially both the 2 paths are active.
> Then I disconnect the primary path (physically unplugging the cross cable).
> BEFORE networkStatusChangeNotif() callback was called (i.e. before sctp
> implementation consider the disconnected path inactive), I begin to send
> some (for ex. 100) data messages with the same size, chosen in the interval
> (600,1450) bytes. Each message is sent calling repetitively the function
> sctp_send() after a constant delay value (for ex. 20ms), using the function
> sctp_startTimer().
> In this condition sctp implementation tries to send all messages on the
> primary path, but it receives neither any SACK nor any HEARTBEAT_ACK,
> because that path has been physically disconnected. So it is used the
> retransmission algoritm for all messages, that begin to be transmitted
> successfully on the secondary path.
> After some (4 or 5) messages' receiving I get a 'Segmentation fault' error
> on the receiving machine (but sometimes it happens on the sending machine
> first).
> The strange fact is that this error happens only for messages sized with a
> value in the interval (600,1450) bytes.

Okay, I will have to look into that. We currently have a multi-homed
testbed here again, so I should find some time to test this very scenario
this week.

> 2) sctp_startTimer() function has problems with small delays.
> I use sctp_startTimer() to set throughput of the sent messages, adjusting
> delay timing passed to this function. For example, in order to obtain a
> 2Mbit/s throughput using 1000bytes messages, I call a function containing
> the sctp_send() every 4 milliseconds through the sctp_startTimer()
> function. The problem is that sctp_startTimer() works good only passing
> delay values
> >= 15milliseconds. If I pass a 4ms value, sctp_startTimer() assumes it as
> it would be 20ms.

I think the linux timer granularity is about 20 msecs. That is not
very high, but I doubt that timervalues smaller than 20 msecs work !

> I thought it could depend on some clock's granularity, but
> sctp_startTimer() strangely works good with values of 2ms and
> 3ms (but not with 6ms, 8ms...).

Hmmmh, I am amazed ! Does anyone have a clue as to the linux
timer granularity (that is: minimum timeout when using the poll
system call)?
I would ideally have something of about 1 millisecond, but so
far, I think, that needs RTLinux .

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

iD8DBQE8AkeDXAsLBNOCSsARAr4fAKCvQdMOrY7aB9RiBUqzp+ctFoSWgQCfXqqf
pZ5PwRVjghpKXJC0g58dkhw=
=SXQI
-----END PGP SIGNATURE-----




Archive powered by MHonArc 2.6.19+.

Top of page