Hi Rohn,
Thanks for your reply and the hints.. I didnt step into the function to
see where exactly it crashes so its good to know that the fix is simple
as that..
On the other hand the second problem was due to my fault.. ( some old
code not properly cleaned up ) so RSP seems to actually work fine now,
although from purely qualitative tests it seems for me that the unicast
approach performs smoother..
i.e for 1000 shared objects just hitting a button and updating one bool
flag seems to block for a fraction of a second or so with RSP when with
the standard approach it seems I am not experiencing this issue for example.
Mapping also seems faster without RSP although from what I ve read in
previous posts this can be expected..
Anyways, thanks for the insights and all the best,
Petros
On 2014-11-24 08:03, ROHN Carsten wrote:
I don't know what your line 700 looks like, unfortunately. But the segfault we
resolved locally by a simple null pointer check.
Carsten
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Petros Kataras
Sent: Freitag, 21. November 2014 17:13
To: Equalizer Developer List
Subject: Re: [eq-dev] RSP / mutlicast details
Ok, looking again at the logs on the slaves side I realized that they were
trying to resolve the hostname of the master so I added it to the known hosts
and RSP seems to work now..
I m having other issues though that do not manifest when running the app
normally without RSP.
I have a shared object that actually seems to map and work fine but I get an
LBUNREACHABLE from objectStore.cpp line 700 . Reading through the source I
can't figure exactly where the issue might lie and as I mentioned the object
seems to register and map properly on the master and client side respectively..
Besides that I am also getting a segfault when exiting the app inside
EventConnection::getNotifier() when running the RSP config. This segfault
happens also with eqPly / seqPly and so on but I don't really have time to
debug it right now...
Anyways I think for now I am gonna stick with unicast and maybe later on I ll
give it a try again..
Thanks for the help anyways..
Cheers,
Petros
On Nov 21, 2014, at 10:11 AM, Petros Kataras <[email protected]> wrote:
Hi Rohn,
thanks for your reply!
I am pretty sure that multicast works properly on the network setup since I
tested with a simple node.js client/server script and I am able to receive
multicast in this case..
The only problem that I faced in that case was that I had to listen to 0.0.0.0
in order to actually receive the multicast. i.e If I would try to listen for
multicast explicitly on the 172 interface then I was not receiving anything..
I am not sure though if this is expected behavior with node.js or not..
Also something that I didn't mention on my previous post is that the appNode
has two network interfaces; one to communicate with the external world and one
for the local subnet ( of course with the multicast route configured for the
appropriate interface ). As I said though this seems to work in general from
the small test that I did with node.js.
I will try with coNetPerf today also and I will come back to you with more
details also on where exactly the appNode hangs.
Thanks again,
Petros
On Nov 21, 2014, at 8:25 AM, ROHN Carsten <[email protected]> wrote:
Hey Petros,
The config you posted will not send any RSP packets. Clients listen
to RSP, but the appNode doesn't send anything. If you uncomment the
commented stuff on the appNode, RSP starts working, and that's
probably why it hangs ;)
There could be a lot of reasons for hanging. I recommend to experiment with
coNetPerf first, if multicast really works in your network with your setup.
Server1: coNetPerf -s RSP#102400#239.172.18.57#172.18.57.12#12333##
Server2: coNetPerf -s RSP#102400#239.172.18.57#172.18.57.13#12333##
Serverx: ...
Client: coNetPerf -c RSP#102400#239.172.18.57#172.18.57.11#12333##
Does this test show packets being sent to the servers as you expect it? If yes,
your problem is not multicast, but how Collage handles multicast. And that's
where the debugging starts, I'm afraid. Where exactly does it hang?
Cheers,
Carsten
PS: A general note: We found multicast to be working pretty poorly for mapping,
so we had to use the *CM::push() functions to distribute data and mapped the
created objects to VERSION_NONE afterwards. This scales pretty well.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
Petros.Kataras
Sent: Donnerstag, 20. November 2014 18:40
To: [email protected]
Subject: [eq-dev] RSP / mutlicast details
Hello,
I am trying to setup a cluster with 1 master and 9 slaves that will use RSP for
mapping and delta distribution but I am not sure how the config file should
look exactly on the master side aka appNode..
Here is the config file that I have created so far:
#Equalizer 1.2 ascii
global
{
EQ_WINDOW_IATTR_HINT_FULLSCREEN ON
EQ_WINDOW_IATTR_HINT_SWAPSYNC OFF
}
server
{
connection { hostname "172.18.57.11" }
config
{
appNode
{
name "appNode"
host "sw-master"
connection{ type TCPIP }
connection
{
#type RSP
#port 12333
#interface "172.18.57.11"
#hostname "239.172.18.57"
hostname "172.18.57.11"
}
pipe
{
device 0
window
{
name "master"
attributes { hint_fullscreen OFF }
viewport [ .0 .0 1920 1080 ]
channel { name "master-channel" }
}
}
}
node
{
name "node1"
host "sw-renderer01"
connection{ type TCPIP }
connection
{
type RSP
port 12333
interface "172.18.57.12"
hostname "239.172.18.57"
}
pipe
{
device 0
window
{
name "node1"
viewport [ 0 0 1 1 ]
channel { name "node1-channel" }
}
}
}
node
{
name "node2"
host "sw-renderer02"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.13"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node2"
viewport [ 0 0 1 1 ]
channel { name "node2-channel" }
}
}
}
node
{
name "node3"
host "sw-renderer03"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.14"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node3"
viewport [ 0 0 1 1 ]
channel { name "node3-channel" }
}
}
}
node
{
name "node4"
host "sw-renderer04"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.15"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node4"
viewport [ 0 0 1 1 ]
channel { name "node4-channel" }
}
}
}
node
{
name "node5"
host "sw-renderer05"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.16"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node5"
viewport [ 0 0 1 1 ]
channel { name "node5-channel" }
}
}
}
node
{
name "node6"
host "sw-renderer06"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.17"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node6"
viewport [ 0 0 1 1 ]
channel { name "node6-channel" }
}
}
}
node
{
name "node7"
host "sw-renderer07"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.18"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node7"
viewport [ 0 0 1 1 ]
channel { name "node7-channel" }
}
}
}
node
{
name "node8"
host "sw-renderer08"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.19"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node8"
viewport [ 0 0 1 1 ]
channel { name "node8-channel" }
}
}
}
node
{
name "node9"
host "sw-renderer09"
connection{ type TCPIP }
connection
{
hostname "239.172.18.57"
interface "172.18.57.20"
type RSP
port 12333
}
pipe
{
device 0
window
{
name "node9"
viewport [ 0 0 1 1 ]
channel { name "node9-channel" }
}
}
}
layout { view { }}
canvas
{
layout 0
wall
{
bottom_left [ -1.6 -.5 -1 ]
bottom_right [ 1.6 -.5 -1 ]
top_left [ -1.6 .5 -1 ]
}
swapbarrier {}
segment { viewport [ 0 0 1 1 ] channel "master-channel" }
segment { viewport [ 0.00000000000000000000 0
0.11111111111111111111 1 ] channel "node1-channel" }
segment { viewport [ 0.11111111111111111111 0
0.11111111111111111111 1 ] channel "node2-channel" }
segment { viewport [ 0.22222222222222222222 0
0.11111111111111111111 1 ] channel "node3-channel" }
segment { viewport [ 0.33333333333333333333 0
0.11111111111111111111 1 ] channel "node4-channel" }
segment { viewport [ 0.44444444444444444444 0
0.11111111111111111111 1 ] channel "node5-channel" }
segment { viewport [ 0.55555555555555555555 0
0.11111111111111111111 1 ] channel "node6-channel" }
segment { viewport [ 0.66666666666666666666 0
0.11111111111111111111 1 ] channel "node7-channel" }
segment { viewport [ 0.77777777777777777777 0
0.11111111111111111111 1 ] channel "node8-channel" }
segment { viewport [ 0.88888888888888888888 0
0.11111111111111111111 1 ] channel "node9-channel" }
}
}
}
Now the appNode section is the one that I am not sure about ... Going through
older posts I see that people were subscribing also the appNode on the
multicast group but if I try to do that by uncommenting the relevant lines in
the config file then everything hangs.
On the other hand if I just run the config file as it is, then I can see that
the slaves properly subscribe on the appropriate multicast group and the sample
app runs properly but I am not sure if then the traffic is routed through the
multicast address or not..
The clients are auto-launched by the server btw and I haven't tried manually
pre-starting everything.
So, does the appNode need to subscribe to the multicast group or is it
sufficient to leave it like this ?
In case that the appNode actually has to subscribe to the multicast group do
you see something wrong with the above config file that it would cause it to
hang??
Thanks for any insights,
Petros
--
View this message in context:
http://software.1713.n2.nabble.com/RSP-mutlicast-details-tp7586748.ht
ml Sent from the Equalizer - Parallel Rendering mailing list archive
at Nabble.com.
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged.
If you are not one of the named recipients or have received this
email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete
this email and all attachments,
(iii) Realtime Technology does not accept or assume any liability or
responsibility for any use of or reliance on this email.
For other languages, go to http://www.3ds.com/terms/email-disclaimer
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged.
If you are not one of the named recipients or have received this email in error,
(i) you should not read, disclose, or copy it,
(ii) please notify sender of your receipt by reply email and delete this email
and all attachments,
(iii) Realtime Technology does not accept or assume any liability or
responsibility for any use of or reliance on this email.
For other languages, go to http://www.3ds.com/terms/email-disclaimer
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
_______________________________________________
eq-dev mailing list
[email protected]
http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev
http://www.equalizergraphics.com
