To have the joy of quoting the TIPC spec... :-)
1.4.4. Overload Protection
To overcome situations where the congestion/flow control mechanisms described
earlier in this section are inadequate or insufficient, TIPC must provide two
additional overload protection services:
Node Overload Protection
TIPC must maintain a global counter on each node, keeping track of the total
number of pending, unhandled payload messages on the node. When this counter
reaches a critical value, which should be configurable, TIPC must selectively
reject new incoming messages. Which messages to reject must be based on the
following criteria: •Message importance. LOW_IMPORTANCE messages should be
rejected at a lower threshold than MEDIUM_IMPORTANCE messages, which should be
rejected before HIGH_IMPORTANCE messages. CRITICAL_IMPORTANCE should not be
rejected at all.
•Message type. Connectionless messages should be rejected earlier than
connection oriented messages. Rejecting such messages normally means rejecting
a service request form the beginning, causing less disturbances than
interrupting a transaction already in progress, e.g. an ongoing phone call.
Process Overload Protection
TIPC must maintain a counter for each process, or if this is impossible, for
each port, keeping track of the total number of pending, unhandled payload
messages on that process or port. When this counter reaches a critical value,
which should be configurable, TIPC must selectively reject new incoming
messages. Which messages to reject should be based on the same criteria as for
the node overload protection mechanism, but all thresholds must be set
significantly lower. Empirically a ratio 2:1 between the node global thresholds
and the port local thresholds has been working well.
And more such quotes from 5.9, 5.10, 5.11!
---
** [tickets:#641] MDS resend**
**Status:** unassigned
**Created:** Thu Nov 28, 2013 09:40 AM UTC by Hans Feldt
**Last Updated:** Tue Dec 03, 2013 06:44 AM UTC
**Owner:** nobody
Occasionally we see TIPC link congestion at the sending node. This can be seen
with "tipc-config -ls" as in:
Link <1.1.1:eth0-1.1.2:eth0>
ACTIVE MTU:1500 Priority:10 Tolerance:1500 ms Window:100 packets
RX packets:1877 fragments:0/0 bundles:0/0
TX packets:17511 fragments:0/0 bundles:0/0
TX profile sample:489 packets average:151 octets
0-64:0% -256:97% -1024:0% -4096:3% -16354:0% -32768:0% -66000:0%
RX states:12974 probes:5918 naks:0 defs:0 dups:0
TX states:12148 probes:6230 naks:0 acks:0 dups:0
Congestion bearer:0 link:12 Send queue max:81 avg:0
Above is from testing with tipc-pipe. With the default link window at 50 I get
one send EAGAIN when sending 100 msgs. When I increase link window to 100 I can
burst 100 msgs without link congestion. If I then burst 1000 msgs I see lots of
link congestion.
If we transfer this to opensaf it means a failed MDS send. MDS does not do any
resends, neither does any service (IMMs FEVS not considered)
AMFd for example could loose a message to a node director which is very bad.
What I suggest is that messages should be resent, typically a loop with 3
retries with a 100ms sleep in between.
There are some concerns, like:
* Can we put this in MDS or should it be done per service?
* What about MDS/TCP, same problem there?
---
Sent from sourceforge.net because [email protected] is
subscribed to https://sourceforge.net/p/opensaf/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/opensaf/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Opensaf-tickets mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensaf-tickets
