headers
Ying Xue | 1 Mar 2012 03:50
Favicon

Re: TIPC over IP

Great work!

Even if we implement another TIPC bearer over IP in future,  I am sure 
its performance is also worse than native Ethernet bearer.
So using L2TPv3 as TIPC infrastructure we can reach this performance, so 
I think this is out of my desired value.

Anyway, you use a simple method to further extend TIPC capability, so 
now we even can say TIPC's nodes have communication ability across IP 
network. :-)

How about broadcast message performance over L2TPv3's bearer?

Can you test it again?

Regards,
Ying

Erik Hugne wrote:
> Hi again!
>
> I made another test this afternoon using L2TPv3.
> An unmanaged vpn was set up between two qemu instances using iproute2 
> (ip l2tp)
>
> Each node will spawn a pseudo interface, l2tpeth0.
> Enabling a TIPC bearer on this worked straight out of the box.
>
> Performance figures was much better, but still about 50% slower than 
> using a native ethernet bearer.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Felix Nayman | 1 Mar 2012 17:00

Missing Topology Service events

We're running tipc 1.7.7 on Linux 2.6.32 and we're running into a problem with our Dynamic Subscription
mechanism.  We create  dynamic subscriptions with a specified timeout.  When that  subscription times out
we expect to receive a timeout event from the Topology Service so we can send out another subscription, but
it appears that  there are times where we're missing the Timeout event.  Has anyone encountered this
problem with subscriptions?
______________________________________________________________________________________________________________________________

This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely for the use of the
addressee(s). If you are not the intended recipient, please notify so to the sender by e-mail and delete
the original message. In such cases, please notify us immediately at sanchar-sadhan <at> infinite.com .
Further, you are not to copy, disclose, or distribute this e-mail or its contents to any unauthorized
person(s) .Any such actions are considered unlawful. This e-mail may contain viruses. Infinite has
taken every reasonable precaution to minimize this risk, but is not liable for any damage you may sustain
as a result of any virus in this e-mail. You should carry out your own virus checks before opening the e-mail
or attachments. Infinite reserves the right to monitor and review the content of al
 l messages sent to or from this e-mail address. Messages sent to or from this e-mail address may be stored on
the Infinite e-mail system. 

***INFINITE******** End of Disclaimer********INFINITE******** 
------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
Permalink | Reply | 6 comments |
headers
Andrew Booth | 1 Mar 2012 19:11
Favicon

Re: Missing Topology Service events

Could you be hitting congestion on the topology connection?

Andrew

From:   Felix Nayman <Felix.Nayman <at> infinite.com>
To:     "tipc-discussion <at> lists.sourceforge.net" 
<tipc-discussion <at> lists.sourceforge.net>
Date:   03/01/2012 11:01 AM
Subject:        [tipc-discussion] Missing Topology Service events

We're running tipc 1.7.7 on Linux 2.6.32 and we're running into a problem 
with our Dynamic Subscription mechanism.  We create  dynamic subscriptions 
with a specified timeout.  When that  subscription times out we expect to 
receive a timeout event from the Topology Service so we can send out 
another subscription, but it appears that  there are times where we're 
missing the Timeout event.  Has anyone encountered this problem with 
subscriptions?
______________________________________________________________________________________________________________________________

This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended 
solely for the use of the addressee(s). If you are not the intended 
recipient, please notify so to the sender by e-mail and delete the 
original message. In such cases, please notify us immediately at 
sanchar-sadhan <at> infinite.com . Further, you are not to copy, disclose, or 
distribute this e-mail or its contents to any unauthorized person(s) .Any 
such actions are considered unlawful. This e-mail may contain viruses. 
Infinite has taken every reasonable precaution to minimize this risk, but 
is not liable for any damage you may sustain as a result of any virus in 
this e-mail. You should carry out your own virus checks before opening the 
e-mail or attachments. Infinite reserves the right to monitor and review
(Continue reading)

Permalink | Reply | 5 comments |
headers
Felix Nayman | 1 Mar 2012 20:03

Re: Missing Topology Service events

Although it's possible that we could be running into congestion, this system was not heavily loaded at the
time so I don't think this was the case of too many messages being sent and received.  Also, processes were
not going up and down at the time.   After opening the socket to the Topology Service, we use setsockopt with
Critical Importance to prevent us from losing any messages.  But it still looks like we're losing these
messages with the TIPC_SUBSCR_TIMEOUT event which is causing havoc in our system.  We also have timeout
values randomly staggered so we don't flood the system with these  subscription timeout events.  The
majority of the time it works fine, but in a few rare instances we've seen this problem.
Any other suggestions or possible explanations for what's going on?

From: Andrew Booth [mailto:abooth <at> pt.com]
Sent: Thursday, March 01, 2012 12:12 PM
To: Felix Nayman
Cc: tipc-discussion <at> lists.sourceforge.net
Subject: Re: [tipc-discussion] Missing Topology Service events

Could you be hitting congestion on the topology connection?

Andrew

From:        Felix Nayman <Felix.Nayman <at> infinite.com>
To:        "tipc-discussion <at> lists.sourceforge.net" <tipc-discussion <at> lists.sourceforge.net>
Date:        03/01/2012 11:01 AM
Subject:        [tipc-discussion] Missing Topology Service events
________________________________

We're running tipc 1.7.7 on Linux 2.6.32 and we're running into a problem with our Dynamic Subscription
mechanism.  We create  dynamic subscriptions with a specified timeout.  When that  subscription times out
we expect to receive a timeout event from the Topology Service so we can send out another subscription, but
it appears that  there are times where we're missing the Timeout event.  Has anyone encountered this
problem with subscriptions?
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ying Xue | 2 Mar 2012 08:45
Favicon

Re: Missing Topology Service events

 From your description, I think you should subscribe many services in 
your system. Until now we have a known issue which some subscription 
messages are lost because link is congested.
Currently due to the lack of protection mechanism of link congestion, 
Topology service may loss messages although you are using SOCK_SEQPACKET 
socket.

I ever created one patch to fix the issue, but the patch still had some 
potential problem when it was reviewed by Allan.

If I have time in next week, I will revise it again and expect it can be 
completely resolved.

Regards,
Ying

Felix Nayman wrote:
> Although it's possible that we could be running into congestion, this system was not heavily loaded at the
time so I don't think this was the case of too many messages being sent and received.  Also, processes were
not going up and down at the time.   After opening the socket to the Topology Service, we use setsockopt with
Critical Importance to prevent us from losing any messages.  But it still looks like we're losing these
messages with the TIPC_SUBSCR_TIMEOUT event which is causing havoc in our system.  We also have timeout
values randomly staggered so we don't flood the system with these  subscription timeout events.  The
majority of the time it works fine, but in a few rare instances we've seen this problem.
> Any other suggestions or possible explanations for what's going on?
>
> From: Andrew Booth [mailto:abooth <at> pt.com]
> Sent: Thursday, March 01, 2012 12:12 PM
> To: Felix Nayman
> Cc: tipc-discussion <at> lists.sourceforge.net
(Continue reading)

Permalink | Reply | 3 comments |
headers
Felix Nayman | 2 Mar 2012 18:04

Re: Missing Topology Service events

Ying,

It appears to be clear that we're missing topology service events.  Would it be possible to get a patch (or
better yet let me know where I would need to make the change) that would output a message to syslog when the
topology service fails to send a message.  I've got event logging with timestamps clearly showing that
we're not receiving messages from the topology service that we would expect to receive (publications and
timeout events).  I'm just not sure that we're running into congestion in these cases.

Also a clarification about the topology service.  The topology service is running on the same node as the
process it responds to correct? How does the topology service get updates about processes running on
other nodes? So the congestion you're talking about here is most likely port congestion and not link or
socket congestion correct?

Thanks,
Felix

-----Original Message-----
From: Ying Xue [mailto:ying.xue <at> windriver.com] 
Sent: Friday, March 02, 2012 1:45 AM
To: Felix Nayman
Cc: Andrew Booth; tipc-discussion <at> lists.sourceforge.net
Subject: Re: [tipc-discussion] Missing Topology Service events

 From your description, I think you should subscribe many services in 
your system. Until now we have a known issue which some subscription 
messages are lost because link is congested.
Currently due to the lack of protection mechanism of link congestion, 
Topology service may loss messages although you are using SOCK_SEQPACKET 
socket.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ying Xue | 5 Mar 2012 09:03
Favicon

Re: Missing Topology Service events

Hi Felix,

Sorry, I make a mistake that topology service message is possibly lost 
due to port congestion rather than link congestion.

You can add some logs in subscr_send_event():

subscr_send_event()
{
...
res = tipc_send(sub->server_ref, 1, &msg_sect);
if (res == -ELINKCONG)
printk(KERN_ERR "port is congested, and missing topology events will 
happen! ");
}

Therefor, if tipc_send() returns -ELINKCONG error code, it denotes it 
fails to send the message. In theory it should try to send it again once 
port is not congested again.
But here it doesn't!

You may have below questions about it:

1. Why not to send the message again if port is not congested any more?
The key reason is that the thread invoking subscr_send_event() can be 
blocked because it may be running on BH context.

2. What conditions will port congestion happen?
If many service names are published or withdrew simultaneously, port 
congestion possible occurs.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ying Xue | 5 Mar 2012 11:11
Favicon

Re: Missing Topology Service events

Ying Xue wrote:
> Hi Felix,
>
> Sorry, I make a mistake that topology service message is possibly lost 
> due to port congestion rather than link congestion.
>
> You can add some logs in subscr_send_event():
>
> subscr_send_event()
> {
> ...
> res = tipc_send(sub->server_ref, 1, &msg_sect);
> if (res == -ELINKCONG)
> printk(KERN_ERR "port is congested, and missing topology events will 
> happen! ");
> }
>
> Therefor, if tipc_send() returns -ELINKCONG error code, it denotes it 
> fails to send the message. In theory it should try to send it again once 
> port is not congested again.
> But here it doesn't!
>
> You may have below questions about it:
>
> 1. Why not to send the message again if port is not congested any more?
> The key reason is that the thread invoking subscr_send_event() can be 
> blocked because it may be running on BH context.
>
>   
Sorry, The key reason is that the thread invoking subscr_send_event()
(Continue reading)

Permalink | Reply | 0 comments |
headers
Erik Hugne | 5 Mar 2012 13:38
Picon
Favicon
Gravatar

Re: TIPC over IP

Hi.
Since the L2TP pseudo interfaces represents a point-to-point link, using 
this type of bearer to create multi-node clusters, or getting 
mcast/bcast traffic to work will probably be tricky (if at all possible..)

Enabling separate bearers with different neighbor detection domains 
might work.. but i cannot test it in my environment.

On node 1.1.1:
tipc-config -be=eth:eth2/1.1.0
tipc-config -be=eth:l2tpeth0/1.2.0

On node 1.2.1:
tipc-config -be=eth:eth2/1.2.0
tipc-config -be=eth:l2tpeth0/1.1.0

|-------------------|      |-------------------|
|TIPC cluster 1.1.0 |      |TIPC cluster 1.2.0 |
|-------------------|      |-------------------|
   |      |                   /         |
   |     eth2                /        eth2
[1.1.1]-/                  [1.2.1]--/
   |                       /
l2tpeth0          l2tpeth0
   |__________________|

Maybe i'll give it a shot if i can get my hands on a bunch of Raspberry 
PI's later on.. :)

//E
(Continue reading)

Permalink | Reply | 1 comment |
headers
Jon Maloy | 5 Mar 2012 17:07
Picon
Favicon

Re: TIPC over IP

Hi Erik,
Allowing the scenario you describe below is the very intention with a having detection domains in the
discovery messages.
It used to work as long as we had multi-cluster support in the code, but will probably not work after Allan's
latest clean-ups in tipc 2.0. 

There has been at least three previous attempts to introduce multi-cluster support, and the "detection
domain" field is a result of this.
Unfortunately they all turned out to be too complex, mainly due to the perceived need to route packets while
preserving name table consistency and message sequentiality.

In the latest approach, which I know Allan already has implemented, we instead agreed to skip any routing
functionality altogether.
Instead, we simply state that all links that can be set up directly node-to-node, according to the
detection scope and network identity set by the user, are legal.
Strictly spoken not even the "full-mesh" requirement within the same cluster is valid any more. 
If messages need to be forwarded it is the user's problem to arrange this. 
This gives a high degree of flexibility for configuring TIPC networks, and is probably sufficient for the
foreseeable future.
You should ask Allan for his patch regarding this, and test your scenario with this.
We call this the "flexi-cluster" approach, and it is by far the simplest and most promising that has been
tried so far.  It really should go into tipc-2.1 when ready.

Regarding TIPC over IP in general, I always thought that it would be most useful when you want to connect
clusters and zones which are geographically or logically isolated from an l2 perspective, i.e. when
routing is needed between them.
For cluster internal messaging, Ethernet will remain the predominant media, although I think UDP can be
useful in some cases, since it provides broadcast.

So, I highly appreciate your effort, but I still don't think it eliminates the need for a separate UDP bearer type.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane