Hi Guna, see below.
> -----Original Message----- > From: GUNA [mailto:gbala...@gmail.com] > Sent: Thursday, 28 April, 2016 10:27 > To: tipc-discussion@lists.sourceforge.net > Subject: [tipc-discussion] Kernel 4.4.0 TIPC: links were bouncing and not > stable > enough > > Hi Jon, > > Back to debugging the table mismatch and standby links issues ... > > I need to clarify two items first as described below. The both issues are > reported by our audit script and works fine for kernel 3.4.2 but not for > new kernel 4.4.0 > > 1. Table mismatch > This is due to bunch of entries with type 2, "node" scope that differs from > each other. > Since the type "2" is internal and "node" scope, do we expect this to be > matched with other node's table? Any change on latest TIPC? > > // slot3 > > 2 16781314 16781314 <1.1.3:0> 0 node > 2 16781314 16781314 <1.1.3:1> 1 node > 2 16781324 16781324 <1.1.3:1> 1 node > 2 16781324 16781324 <1.1.3:0> 0 node > 2 16781325 16781325 <1.1.3:0> 0 node > 2 16781325 16781325 <1.1.3:1> 1 node > This is a new feature in 4.0+. It actually shows the working links on this node towards other nodes, not only the connectivity to a node, as type "0" does. I can read form this that you typed the command on node <1.1.3>, and that that node has two links towards each of <1.1.2>,< 1.1.12> and <1.1.13> respectively, (16781314 in hex is 1001002, i.e. 1.1.2). You will find corresponding entries for the other endpoints of the links on the respective nodes. The fact that they are present in the table means they are up and working. > > // slot2 > Type Lower Upper Port Identity Publication > Scope > > 2 16781315 16781315 <1.1.2:0> 0 node > 2 16781315 16781315 <1.1.2:1> 1 node > 2 16781324 16781324 <1.1.2:0> 0 node > 2 16781324 16781324 <1.1.2:1> 1 node > 2 16781325 16781325 <1.1.2:0> 0 node > 2 16781325 16781325 <1.1.2:1> 1 node > > See above. <1.1.2> has links towards <1.1.3> as expected, and also towards <1.1.12> and <1.1.13>. So, everything is correct here. > 2. Active and standby links. > Our system has 2 bearer p19p1 and p19p2. Both links are ACTIVE in 3.4.2 > kernel, but on new kernel the one comes as STANDBY. Both have same > priority. > Is it expected behavior on latest TIPC? No. If they have the same priority they should both be active. I just checked this in the current code, and there is actually a bug, but only in the flag used to present the node, state, not the state as such. So, even if the statistics say STANDBY, it is still ACTIVE, and will take its full part of the load sharing. You can safely us it as before. I will post a patch to fix this upstream, but it probably won't go into kernel 4.4, since this is just a "cosmetic" bug. Thank you for reporting this. > > If both are expected behavior then I would change our audit script > accordingly. Otherwise, need to debug the issue. > > Link <1.1.2:p19p1-1.1.3:p19p1> > ACTIVE MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets > RX packets:4294901760 fragments:0/0 bundles:0/0 > TX packets:54487 fragments:0/0 bundles:0/0 > TX profile sample:164252 packets average:30 octets > 0-64:97% -256:3% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0% > RX states:473939 probes:513 naks:1407 defs:0 dups:0 > TX states:999870 probes:472019 naks:0 acks:0 dups:1407 > Congestion link:0 Send queue max:0 avg:0 > > Link <1.1.2:p19p2-1.1.3:p19p2> > STANDBY MTU:1500 Priority:10 Tolerance:1200 ms Window:50 packets > RX packets:4294508544 fragments:0/0 bundles:0/0 > TX packets:43737 fragments:0/0 bundles:0/0 > TX profile sample:255979 packets average:29 octets > 0-64:98% -256:2% -1024:0% -4096:0% -16384:0% -32768:0% -66000:0% > RX states:419534 probes:509 naks:14 defs:242 dups:247 > TX states:1000082 probes:419011 naks:248 acks:0 dups:14 > Congestion link:0 Send queue max:0 avg:0 > > [root@Slot2 ~]# tipc-config -b > Bearers: > eth:p19p1 > eth:p19p2 > > On last discussion, you asked me to turn on debug from the node.c. Could > you let me know how I could turned on? Do I need to add printf or just > enable any micro? You have to recompile the kernel with DEBUG option to see all pr_debug() printouts. I don't think you need to do that now according to the above. BR ///jon > > I tried to use the latest tipcutils, but having issue on compiling it. > > Thanks, > Guna > ------------------------------------------------------------------------------ > Find and fix application performance issues faster with Applications Manager > Applications Manager provides deep performance insights into multiple tiers of > your business applications. It resolves application problems quickly and > reduces your MTTR. Get your free trial! > https://ad.doubleclick.net/ddm/clk/302982198;130105516;z > _______________________________________________ > tipc-discussion mailing list > tipc-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/tipc-discussion ------------------------------------------------------------------------------ Find and fix application performance issues faster with Applications Manager Applications Manager provides deep performance insights into multiple tiers of your business applications. It resolves application problems quickly and reduces your MTTR. Get your free trial! https://ad.doubleclick.net/ddm/clk/302982198;130105516;z _______________________________________________ tipc-discussion mailing list tipc-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tipc-discussion
