Consider there are three nodes whose hostnames are host-master, host-slave1, host-slave2 respectively.
Let the MPI program to be run on host-master, with the executing command like this:
mpiexec -n 4 -h host-master,host-slave1,host-slave2 mpi.program
Since MPI APIs (e.g. MPI_Send/MPI_Bcast/..) can be invoked to transfer messages between two different nodes (for example, host-slave1 -> host-slave2),
I don't know what kind of OS communication interfaces that MPI-Engine use to implement this.
By createing tcp-socket between host-slave1 and host-slave2, and sending messages throught this channel?
Or by host-master collecting messages from host-slave1 through pipe channel, then forwarding these messages to host-slave2 through pipe as well?
Related
I have a question regarding ns2, so i have two adhoc routing protocol, one is simple just send a periodic hello messages and perform nodes movement, the other is Vector based forwarding protocol to send the data. I want to ask if there is away that i can call both protocol on the same set of nodes? both are TCP protocol,
since i'm new in tcl i assueme the changes will be here but i'm not sure if such a thing is possible?
$ns_ node-config -adhocRouting $opt(adhocRouting) \
Given file descriptors of two connected AF_UNIX sockets is it possible to ensure that they are indeed connected to the same peer?
A function like getpeername would do but it doesn't seem to support this family.
Regarding the definition of AF_UNIX socket, the socket is the method used by the processes of the local machine.
So, to get the peer(s) of a socket file, you just need to get the list of local processes that have opened the file descriptor.
You can do that using fuser command or lsof. Both unix command will give you the list of processes using the socket, and you may compare the result to status about your question.
I am using asterisk(1.6.2.13) to mass originate to specified numbers that are come from mysql database using perl and AMI.
if I send all calls (simultaneous) to asterisk, it will drop half of them after about 20 seconds. but if I sleep for 1 second between each originate it will process the call clearly. so this will reduce the capacity of origination.
Is there any way to get rid of this limitation?
Asterisk uses a single thread to process all SIP messages, and everything relating to SIP messaging happens in this thread (eg. realtime database access). This imposes an upper limit on the number of calls that can be processed per second. You can monitor the unprocessed SIP packets on the socket queue using something like "netstat -na |grep 5060". I've found it can up to 200 call setups per second, beyond that it will start losing and retransmitting packets and eventually dropping calls.
I have a program where there is a master/slave setup, and I have some functions implemented for the master which sends different kinds of data to the slaves. Some functions send to individual slaves, but some broadcast information to all the slaves via MPI_Bcast.
I want to have only one receive function in the slaves, so I want to know if I can probe for a message and know if it was broadcasted or sent as a normal blocking message, since there are different method to receive what was broadcasted and what was sent normally.
No, you can't decide whether to call Bcast or Recv on the basis of a probe call.
A MPI_Bcast call is a collective operation -- all MPI tasks must participate. As a result, these are not like point to point communication; they make use of the fact that all processes are involved to make higher-order optimizations.
Because the collective operations imply so much synchronization, it just doesn't make sense to allow other tasks to check to see whether they should start participating in a collective; it's something which has to be built into the logic of a program.
The root process' role in a broadcast is not like a Send; it can't, in general, just call MPI_Bcast and then proceed. The implementation will almost certainly block until some other number of processes have participated in the broadcast; and
The other process' role in a broadcast is not like receiving a message; in general it will be both receiving and sending information. So participating in a broadcast is different from making a simple Recv call.
So Probe won't work; the documentation for MPI_Probe is fairly clear that it returns information about what would happen upon the next MPI_Recv, and Recv is a different operation than Bcast.
You may be able to get some of what you want in MPI 3.0, which is being finalized now, which allows for nonblocking collectives -- eg, MPI_Ibcast. In that case you could start the Broadcast and call MPI_Test to check on the status of the request. However, even here, everyone would need to call the MPI_Ibcast first; this just allows easier interleaving of collective and point-to-point communication.
Since Socket is used in hadoop src, guess it's TCP connections to send/recv messages and files, right?
How JVM translate these Socket instances to Linux system calls, is that socket/send, or select/poll?
If it's all about select/poll, I still can get ip/port through relative socket system calls, right?
When I collect all the sys_calls during a terasort (1 master, 3 slaves), I got rare connect/accept/socket sys_calls, and they are without any LAN ip in the sockaddr struct (either 0 or strange ones, IPv4). There are bunches of select/poll sys_calls, is that reasonable?
you could use "netstat --tcp -n" commands to check current tcp connection. i guess Hadoop should use TCP.
you may need use strace to start your Hadoop JVM. The strace will print system calls used by the running application. Usual application use sys_poll to check connection FD's status and use read/write or sendto/recvfrom syscall to receive transmit packet.
?
Right, these system call is only called once during connection setup through sys_socket system call, then application does many polls, transmit or receives operation on that socket.