headers
singaram srinivasan | 1 Dec 2011 11:54
Picon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

Hi Allan,Jon,

Please find my responses inline.

On Sat, Nov 26, 2011 at 12:10 AM, Stephens, Allan
<allan.stephens <at> windriver.com> wrote:

Jon’s concerns about the possible performance impacts of adding new
counters are definitely real.

A few observations of my own:

·Introducing new counters that record exceptional behavior, such as
the number of packets dropped because they are incorrectly
constructed, isn’t likely to cause too much of a problem since these
conditions won’t arise very often. We’ll need to be more careful about
introducing counters for things that are the norm, such as sending and
receiving normal packets that get to their destination properly.

>>> [Singaram] : As Allan suggested, the counters that are incremented/manipulated during abnormal
conditions like packets being dropped (because of no buffers, invalid credentials etc..) are likely to
happen in rare cases. Hence introducing these counters  will not cause much of performance issues. hence
these counters can prove to be useful in debugging situations. On the counters that are incremented in
normal working scenarios there can be a second thought on reducing the number of counters that are manipulated.

·Aggregating existing statistics is potentially feasible, but requires
 care if it is to be done correctly. We’d still probably need some
sort of bearer-level placeholder to record statistics information that
will otherwise be lost – for example, for holding statistics
associated with a link that no longer exists, or for a link whose
(Continue reading)

Permalink | Reply | 14 comments |
headers
Stephens, Allan | 1 Dec 2011 17:40
Favicon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

Singaram wrote:

> Hi Allan,Jon,
> 
> Please find my responses inline.
> 
> On Sat, Nov 26, 2011 at 12:10 AM, Stephens, Allan
> <allan.stephens <at> windriver.com> wrote:
> 
> Jon's concerns about the possible performance impacts of adding new
> counters are definitely real.
> 
> A few observations of my own:
> 
> *Introducing new counters that record exceptional behavior, such as the
> number of packets dropped because they are incorrectly constructed,
> isn't likely to cause too much of a problem since these conditions won't
> arise very often. We'll need to be more careful about introducing
> counters for things that are the norm, such as sending and receiving
> normal packets that get to their destination properly.
> 
> 
> >>> [Singaram] : As Allan suggested, the counters that are
> incremented/manipulated during abnormal conditions like packets being
> dropped (because of no buffers, invalid credentials etc..) are likely to
> happen in rare cases. Hence introducing these counters  will not cause
> much of performance issues. hence these counters can prove to be useful
> in debugging situations. On the counters that are incremented in normal
> working scenarios there can be a second thought on reducing the number
> of counters that are manipulated.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Abi Wilson | 2 Dec 2011 08:23

Two Links for Same interface

Hi,

I have a requirement in tipc to create two TIPC link for an Ethernet and
one must be in lower priority and Other in Higher priority.Please Advice me
to create two links for the Same Ethernet, So that I can set priority on
link basis. I have listed my need as tipc commands and the output. Thanks
in Advance.

Example:

:  *tipc-config -netid=1234 -a=1.1.2  -be=eth:eth0/1.1.0/1*
*tipc-config -lp=1.1.3:eth0-1.1.2:eth0/1*

Link <1.1.3:eth0-1.1.2:eth0>
ACTIVE MTU:1500 Priority:1 Tolerance:1500 ms Window:50 packets
RX packets:1 fragments:0/0 bundles:0/0
TX packets:1 fragments:0/0 bundles:0/0
TX profile sample:2 packets average:60 octets
0-64:100% -256:0% -1024:0% -4096:0% -16354:0% -32768:0% -66000:0%
RX states:6203 probes:3102 naks:0 defs:0 dups:0
TX states:6203 probes:3101 naks:0 acks:0 dups:0
Congestion bearer:0 link:0 Send queue max:1 avg:0

:  *tipc-config -netid=1234 -a=1.1.3  -be=eth:eth0/1.1.0/1*
*tipc-config  -lp=1.1.2:eth0-1.1.3:eth0/10 *

Link <1.1.2:eth0-1.1.3:eth0>
ACTIVE MTU:1500 Priority:10 Tolerance:1500 ms Window:50 packets
RX packets:1 fragments:0/0 bundles:0/0
TX packets:1 fragments:0/0 bundles:0/0
(Continue reading)

Permalink | Reply | 7 comments |
headers
Erik Hugne | 2 Dec 2011 09:27
Picon
Favicon
Gravatar

Re: Two Links for Same interface

You could try to create a vlan interface tied to eth0 and enable a 
secondary TIPC bearer on this.

//E

On 2011-12-02 08:23, Abi Wilson wrote:
> Hi,
>
> I have a requirement in tipc to create two TIPC link for an Ethernet and
> one must be in lower priority and Other in Higher priority.Please Advice me
> to create two links for the Same Ethernet, So that I can set priority on
> link basis. I have listed my need as tipc commands and the output. Thanks
> in Advance.
>
> Example:
>
> :  *tipc-config -netid=1234 -a=1.1.2  -be=eth:eth0/1.1.0/1*
> *tipc-config -lp=1.1.3:eth0-1.1.2:eth0/1*
>
> Link<1.1.3:eth0-1.1.2:eth0>
> ACTIVE MTU:1500 Priority:1 Tolerance:1500 ms Window:50 packets
> RX packets:1 fragments:0/0 bundles:0/0
> TX packets:1 fragments:0/0 bundles:0/0
> TX profile sample:2 packets average:60 octets
> 0-64:100% -256:0% -1024:0% -4096:0% -16354:0% -32768:0% -66000:0%
> RX states:6203 probes:3102 naks:0 defs:0 dups:0
> TX states:6203 probes:3101 naks:0 acks:0 dups:0
> Congestion bearer:0 link:0 Send queue max:1 avg:0
>
> :  *tipc-config -netid=1234 -a=1.1.3  -be=eth:eth0/1.1.0/1*
(Continue reading)

Permalink | Reply | 6 comments |
headers
singaram srinivasan | 2 Dec 2011 16:30
Picon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

Hi Allan,

Please find my responses inlined.

> Hi Allan,Jon,
>
> Please find my responses inline.
>
> On Sat, Nov 26, 2011 at 12:10 AM, Stephens, Allan
> <allan.stephens <at> windriver.com> wrote:
>
> Jon's concerns about the possible performance impacts of adding new
> counters are definitely real.
>
> A few observations of my own:
>
> *Introducing new counters that record exceptional behavior, such as the
> number of packets dropped because they are incorrectly constructed,
> isn't likely to cause too much of a problem since these conditions won't
> arise very often. We'll need to be more careful about introducing
> counters for things that are the norm, such as sending and receiving
> normal packets that get to their destination properly.
>
>
> >>> [Singaram] : As Allan suggested, the counters that are
> incremented/manipulated during abnormal conditions like packets being
> dropped (because of no buffers, invalid credentials etc..) are likely to
> happen in rare cases. Hence introducing these counters  will not cause
> much of performance issues. hence these counters can prove to be useful
> in debugging situations. On the counters that are incremented in normal
(Continue reading)

Permalink | Reply | 12 comments |
headers
Abi Wilson | 5 Dec 2011 12:21

Re: Two Links for Same interface

Thanks for your Advice, I tried with the below configuration, I am unable
to configure.

*vconfig add eth0 2*
*vconfig add eth0 3*
*ifconfig eth0.2 10.144.15.6 up*
*ifconfig eth0.3 10.144.15.7 up*

eth0.2    Link encap:Ethernet  HWaddr 00:0C:29:27:E2:CD
          inet addr:10.144.15.6  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

eth0.3    Link encap:Ethernet  HWaddr 00:0C:29:27:E2:CD
          inet addr:10.144.15.7  Bcast:10.255.255.255  Mask:255.0.0.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

*tipc-config -netid=1234 -a=1.1.1 -be=eth:eth0.2*
*tipc-config -netid=1234 -a=1.1.2 -be=eth:eth0.3*
*operation not supported (cannot change node address once assigned)*
*
*
*Regards,*
(Continue reading)

Permalink | Reply | 5 comments |
headers
Erik Hugne | 5 Dec 2011 12:31
Picon
Favicon
Gravatar

Re: Two Links for Same interface

Try this:
/*Assign netid and address*/
tipc-config -netid=1234 -a=1.1.1

/*Bring up bearer 1*/
tipc-config -be=eth:eth0.2*
/*Bring up bearer 2*/
tipc-config -be=eth:eth0.3*

//E

On 2011-12-05 12:21, Abi Wilson wrote:
> Thanks for your Advice, I tried with the below configuration, I am
> unable to configure.
>
> *vconfig add eth0 2*
> *vconfig add eth0 3*
> *ifconfig eth0.2 10.144.15.6 up*
> *ifconfig eth0.3 10.144.15.7 up*
>
> eth0.2    Link encap:Ethernet  HWaddr 00:0C:29:27:E2:CD
>            inet addr:10.144.15.6  Bcast:10.255.255.255  Mask:255.0.0.0
>            UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
>            RX packets:0 errors:0 dropped:0 overruns:0 frame:0
>            TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
>            collisions:0 txqueuelen:0
>            RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
>
> eth0.3    Link encap:Ethernet  HWaddr 00:0C:29:27:E2:CD
>            inet addr:10.144.15.7  Bcast:10.255.255.255  Mask:255.0.0.0
(Continue reading)

Permalink | Reply | 4 comments |
headers
Stephens, Allan | 5 Dec 2011 23:02
Favicon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

Responses inline.

-- Al

From: singaram srinivasan [mailto:singaram.srinivasan <at> gmail.com]
Sent: Friday, December 02, 2011 10:30 AM
To: Stephens, Allan
Cc: Jon Maloy; tipc-discussion <at> lists.sourceforge.net
Subject: Re: [tipc-discussion] Proposal for adding Ethernet bearer statistics counters and port
receive filter statistics

 [SNIP]
>
> *Aggregating existing statistics is potentially feasible, but requires
> care if it is to be done correctly. We'd still probably need some sort
> of bearer-level placeholder to record statistics information that will
> otherwise be lost - for example, for holding statistics associated with
> a link that no longer exists, or for a link whose individual statistics
> have been reset by the user. The displayed statistics would be the sum
> of the individual link stats plus these "historical" bearer stats.
>
> >>>[Singaram] : Aggregating existing statistics, would prove difficult
> in a scenario where two nodes are communicating over TIPC and say a
> node-1 goes down all of a sudden, then the link statistics in node-2
> will be reset to zero in such scenarios we may not be able to debug with
> the help of counters that are currently maintained at the link level.
>
> Consider the following scenario
> 1. Two nodes (node-1 and node-2) are trying to establish a TIPC link.
> 2. Node-1 bearer has problems receiving the packets sent by node-2.
(Continue reading)

Permalink | Reply | 11 comments |
headers
singaram srinivasan | 6 Dec 2011 16:56
Picon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

Responses inline.

Regards,
Singaram

On Tue, Dec 6, 2011 at 3:32 AM, Stephens, Allan <
allan.stephens <at> windriver.com> wrote:

>  Responses inline.****
>
> ** **
>
> -- Al****
>
> ** **
>
> *From:* singaram srinivasan [mailto:singaram.srinivasan <at> gmail.com]
> *Sent:* Friday, December 02, 2011 10:30 AM
> *To:* Stephens, Allan
> *Cc:* Jon Maloy; tipc-discussion <at> lists.sourceforge.net
>
> *Subject:* Re: [tipc-discussion] Proposal for adding Ethernet bearer
> statistics counters and port receive filter statistics****
>
> ** **
>
>  [SNIP]****
>
> >
> > *Aggregating existing statistics is potentially feasible, but requires
(Continue reading)

Permalink | Reply | 10 comments |
headers
Stephens, Allan | 7 Dec 2011 19:06
Favicon

Re: Proposal for adding Ethernet bearer statistics counters and port receive filter statistics

More responses inline.

I think we're nearing consensus about what statistics could be collected. Where do you want to go from here?

-- Al

[SNIP]

>
> No port - Incremented when a message is dropped because of destination
> port not reachable. This is maintained at socket level.
[Singaram] : In filter_rcv function, when a received message is rejected(it being wrong sort of message
for the socket) this counter is being incremented.
[AL] OK, I understand what you're trying to count now. My question now is: how is this value reported back to
the user? It isn't really a link-level or bearer-level items, since you could conceivably run into this
issue even with intra-node traffic. I'm wondering if we need to introduce port-level statistics?
[Singaram] : The value is reported as global counter to users i.e., one per each node running TIPC. I don't
feel there would be need to implement one such counter per every port.

[AL] I'd be OK with this approach, at least to start with. We could always switch to per-port counters (that
could also be aggregated into a global count for reporting purposes) at a later date.

[SNIP]
>
> TX/RX packets counters - Incremented when a packet is sent/received.
> Would be helpful in case of scenario explained in reply to point number
> 2.
You'll need to explain this better, as I don't get what you mean.
[Singaram] : The count of packets that are exchanged during link establishment are not maintained as a part
of link statistics in current implementation. We may end up losing these count of packets that are
(Continue reading)

Permalink | Reply | 9 comments |

Gmane