Chronological Thread 

< Chronological >      < Thread >

---

Hello Andreas,
thank you for your fast reply.

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

I'll be waiting for it anxiously; I need it for developing my university
thesis.

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

I think having found some things can be useful for debugging. This week I
tried some other tests simulating a packet-loss network data transmission
between 2 hosts connected one each other through a router. On this router I
used NistNet (http://ww.antd.nist.gov/itg/nistnet) to emulate a network with
settable packet-loss. I established a single path, 100 in-streams, 100
out-streams association, but I used only one stream for transmission. I sent
100, 1KB sized, messages with an approximative 1.5Mbit/s throughput.
The results of this tests are:
- If I use _ordered_ delivery of sctp-data-chunks in packet-loss
transmission (even only 1%) some lost chunks are not retransmitted. In a lot
of cases (randomly) I got the 'segmentation fault' error.
- If I try the same test using the _unordered_ delivery all works good.

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

I think we can exclude timer granularity from bug causes list: I recompiled
my Linux kernel using a patch (shipped with NistNet), that sets Linux timer
granularity to ~1 microsecond. I didn't see an improvement in
sctp_StartTimer() behaviour with small delays.

Best regards,
Alberto Bellettato

---

• [SCTP-Discussion] Implementation bugs?, Alberto Bellettato, 11/25/2001
  • Re: [SCTP-Discussion] Implementation bugs?, Andreas Jungmaier, 11/26/2001
    • Re: [SCTP-Discussion] Implementation bugs? News, Alberto Bellettato, 11/30/2001

---

Archive powered by MHonArc 2.6.19+.