Steve Hill wrote:
> On Wed, 7 Feb 2007, Vlad Yasevich wrote:
>
>> I think I've tracked this down. Can you apply the attached patch on top
>> of the one I posted before and re-run your test.
>
> Using the 2.6.20 kernel on the sending side with both patches applied, the
> problem seems to be fixed
On Wed, 7 Feb 2007, Vlad Yasevich wrote:
> I think I've tracked this down. Can you apply the attached patch on top
> of the one I posted before and re-run your test.
Using the 2.6.20 kernel on the sending side with both patches applied, the
problem seems to be fixed.
Thanks.
--
- Steve Hill
Hi Steve
I think I've tracked this down. Can you apply the attached patch on top
of the one I posted before and re-run your test.
With both patches, I was able flip-flop the downed interface multiple times
and in all cases path failover completed and data flow resumed.
Here is the modified scri
Steve Hill wrote:
> Vlad Yasevich wrote on 05 February 2007 20:35:
>
>> would you mind terribly, changing the -d "$net" to the
>> -i "$net", and run the script with the interface name instead?
>
> I seem to get the same failure when dropping traffic based on interface
> as I do when dropping base
Vlad Yasevich wrote on 05 February 2007 20:35:
> would you mind terribly, changing the -d "$net" to the
> -i "$net", and run the script with the interface name instead?
I seem to get the same failure when dropping traffic based on interface
as I do when dropping based on address.
> When I block
Hi Steve
would you mind terribly, changing the -d "$net" to the
-i "$net", and run the script with the interface name instead?
The reason is, that I see 2 different behaviors between blocking
by interface and blocking by IP and would like to find out if
you see it too.
When I block at the inter
Vlad Yasevich wrote on 05 February 2007 17:08:
> 1. What did you set the sinfo_timetolive to?
I presume you mean the timetolive parameter of sctp_sendmsg()? - this
was set to 1400ms (as previously mentioned, this was in error but it
does appear to have highlighted a problem with the stack itsel
Hi Steve
Steve Hill wrote:
Vlad Yasevich wrote on 05 February 2007 16:39:
Once you start simulating the network failure, how long do you wait?
If you have not changed rto_max and path_max_retrans, you can end up
waiting quite a while for the full path switchover. This will also
severely slow
Vlad Yasevich wrote on 05 February 2007 16:39:
> Once you start simulating the network failure, how long do you wait?
>
> If you have not changed rto_max and path_max_retrans, you can end up
> waiting quite a while for the full path switchover. This will also
> severely slow down your retransmis
Steve Hill wrote:
Vlad Yasevich wrote on 25 January 2007 16:33:
Can you try the attached patch and let me know if the problem is
fixed. You can try reducing rto_max or path_max_retrans to get the
failover to happen a little faster.
Sorry for the delay - I've been on vacation for the past we
Vlad Yasevich wrote on 25 January 2007 16:33:
> Can you try the attached patch and let me know if the problem is
> fixed. You can try reducing rto_max or path_max_retrans to get the
> failover to happen a little faster.
Sorry for the delay - I've been on vacation for the past week.
I've tried
BTW, if anyone needs a reproducer, I can provide one.
-vlad
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Steve
Steve Hill wrote:
> On Wed, 10 Jan 2007, Sridhar Samudrala wrote:
>
>> So looks like there may be an issue with PR-SCTP(partial reliability)
>> support and packet loss. I will take a look into this.
>>
>> Do you still see this problem even if you don't set timetolive?
>
> No, the proble
13 matches
Mail list logo
