Stephens, Allan | 2 Jun 2011 21:44
Favicon

Re: Fwd: Overload in SEQPACKET - inter node

Hi Lars:

It sounds like you've run into a TIPC 2.0-specific issue that was introduced by changes to
sk_add_backlog() in Linux 2.6.35. You are correct in concluding that changing TIPC_OVERLOAD_BASE or
message importance won't help because the new checking introduced to sk_add_backlog() happens before
TIPC gets to do its normal overload checking.

I haven't looked in detail at the code involved here, but it looks like you can work around the problem (at
least to some degree) by changing SO_RCVBUF to a larger value. TIPC currently doesn't pay any attention to
the value specified by SO_RCVBUF, but increasing its value looks like it will allow you to get around the
new checking done by sk_add_backlog(). I suggest that you give this a whirl (if you haven't already) and
let us know whether or not it helps.

In the long run, we'll need to modify TIPC 2.0 so that this sort of kludging isn't necessary. This should be
done as part of the wholesale re-evaluation of TIPC 2.0's traffic management capabilities, but we really
need to find someone to drive this work as neither Jon nor I have the bandwidth to do it ...

Regards,
Al

> ---------- Forwarded message ----------
> From: Lars Gullik Bjønnes <larsbj <at> gullik.org>
> Date: Wed, Jun 1, 2011 at 22:16
> Subject: Re: [tipc-discussion] Overload in SEQPACKET - inter node
> To: "Stephens, Allan" <allan.stephens <at> windriver.com>
> Cc: tipc-discussion-request <at> lists.sourceforge.net
> 
> 
> On Wed, Jun 1, 2011 at 13:19, Stephens, Allan
> <allan.stephens <at> windriver.com> wrote:
> > Increasing the importance of the messages you are sending will
> increase the number of messages that TIPC allows in queues before
> declaring overload. Take a look at the archive for this mailing list and
> you'll find some recent posts about this very subject.
> 
> I found some message. None of them directly relevant.
> 
> I have instrumented socket.c a t bit (this is on 2.6.3[56]), and am
> discovering that the overload is caused by a failure to add to the
> backlog (sk_add_backlog).
> 
> Is it correct to say that any fiddling with importance or
> OVERLOAD_LIMIT_BASE will not have any bearing on this?
> 
> Will/Can a change to SO_RCVBUF make any difference? or is that just
> unused by TIPC?
> 
> >
> > Regards,
> > Al
> >
> >> -----Original Message-----
> >> From: Lars Gullik Bjønnes [mailto:larsbj <at> gullik.org]
> >> Sent: Wednesday, June 01, 2011 6:08 AM
> >> To: tipc-discussion <at> lists.sourceforge.net
> >> Subject: [tipc-discussion] Overload in SEQPACKET - inter node
> >>
> >>
> >> Hi,
> >>
> >> I am having a problem that I do not quite know how to solve.
> >>
> >> I have a small cluster (some 11 nodes) using tipc for communication,
> >> SEQPACKET. In some situations I get a error return for Overload (4),
> >> and the connection goes down. (A lot of small packets in a very short
> time).
> >>
> >> What are the methods to avoid this kind of overload? Can some buffers
> >> be increased? Will the importance of message change anything?
> >>
> >> Any insights?
> >>
> >> --
> >>       Lgb
> >>
> >>
> >> ---------------------------------------------------------------------
> >> ---
> >> ------
> >> Simplify data backup and recovery for your virtual environment with
> >> vRanger.
> >> Installation's a snap, and flexible recovery options mean your data
> >> is safe, secure and there when you need it. Data protection magic?
> >> Nope - It's vRanger. Get your free trial download today.
> >> http://p.sf.net/sfu/quest-sfdev2dev

> >> _______________________________________________
> >> tipc-discussion mailing list
> >> tipc-discussion <at> lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/tipc-discussion

> >
> 
> 
> 
> --
>         Lgb
> 
> 
> 
> --
>         Lgb
> 
> ------------------------------------------------------------------------
> ------
> Simplify data backup and recovery for your virtual environment with
> vRanger.
> Installation's a snap, and flexible recovery options mean your data is
> safe, secure and there when you need it. Data protection magic?
> Nope - It's vRanger. Get your free trial download today.
> http://p.sf.net/sfu/quest-sfdev2dev

> _______________________________________________
> tipc-discussion mailing list
> tipc-discussion <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/tipc-discussion

------------------------------------------------------------------------------
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Discover what all the cheering's about.
Get your free trial download today. 
http://p.sf.net/sfu/quest-dev2dev2 
_______________________________________________
tipc-discussion mailing list
tipc-discussion <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/tipc-discussion

Gmane