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