April 2015 - discuss - mailman3.cels.anl.gov

Re: [mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait
by Lei Shi 03 Apr '15

03 Apr '15

Huiwei, Thanks for your email. Your answer leads to my another question about asynchronous MPI communication. I'm trying to do an overlapped communication/computing to speedup my MPI code. I read some papers comparing some different approaches to do the overlapped communication. The "naive" overlapped communication implementation, which only use non-blocking mpi Isend/Irecv and the hybrid approach using OpenMP and MPI together. In the hybrid approach, a separated thread is use to do all non-blocking communications. Just exactly as you said, the results indicate that current MPI implementations do not support true asynchronous communication. If I use the naive approach, my code with non-blocking or blocking send/recv gives me almost the same performance in term of Wtime. All communications are postponed to MPI_Wait. I have tried calling mpi_test to push library to do communication during iterations. And try to use a dedicated thread to do communication and the other thread to do computing only. However, the performance gains are very small or no gain at all. I'm wondering it is due to the hardware. The cluster I tested uses 10G Ethernet card. Best, Lei Shi On Fri, Apr 3, 2015 at 8:49 AM, Huiwei Lu <huiweilu(a)mcs.anl.gov> wrote: > Hi Lei, > > As far as I know, all current MPI implementations do not support true > asynchronous communication for now. i.e., If there is no MPI calls in your > iterations, MPICH will not be able to make progress on communication. > > One solution is to poll the MPI runtime regularly to make progress by > inserting MPI_Test to your iteration (even though you do not want to check > the data). > > Another solution is to enable MPI's asynchronous progress thread to make > progress for you. > > -- > Huiwei > > On Thu, Apr 2, 2015 at 11:44 PM, Lei Shi <lshi(a)ku.edu> wrote: > >> Hi Junchao, >> >> Thanks for your reply. For my case, I don't want to check the data have >> been received or not. So I don't want to call MPI_Test or any function to >> verify it. But my problem is like if I ignore calling the MPI_Wait, just >> call Isend/Irev, my program freezes for several sec and then continues to >> run. My guess is probably I messed up the MPI library internal buffer by >> doing this. >> >> On Thu, Apr 2, 2015 at 7:25 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> >> wrote: >> >>> Does MPI_Test fit your needs? >>> >>> --Junchao Zhang >>> >>> On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi(a)ku.edu> wrote: >>> >>>> I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do >>>> communication. But in my case, I don't really care what kind of data I get >>>> or it is ready to use or not. So I don't want to waste my time to do any >>>> synchronization by calling MPI_Wait or etc API. >>>> >>>> But when I avoid calling MPI_Wait, my program is freezed several secs >>>> after running some iterations (after multiple MPI_Isend/Irev callings), >>>> then continues. It takes even more time than the case with MPI_Wait. So my >>>> question is how to do a "true" non-blocking communication without waiting >>>> for the data ready or not. Thanks. >>>> >>>> _______________________________________________ >>>> discuss mailing list discuss(a)mpich.org >>>> To manage subscription options or unsubscribe: >>>> https://lists.mpich.org/mailman/listinfo/discuss >>>> >>> >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [OMPI users] Buffered sends are evil?
by Jeff Squyres (jsquyres) 03 Apr '15

03 Apr '15

Fair enough. My main point should probably be summarized as: MPI_BSEND isn't worth it; there are other, less-confusing, generally-more-optimized alternatives. > On Apr 3, 2015, at 11:20 AM, Balaji, Pavan <balaji(a)anl.gov> wrote: > > Jeff, > > Your blog post seems to confuse what implementations currently do with what Bsend is capable of. If users really wanted it (e.g., a big customer asked for it), every implementation will optimize the crap out of it. The problem is that every few users really care for it, so there's not been a good incentive for implementations to optimize it. > > Coming to the technical aspects, bsend doesn't require copying into the user buffer, if you have internal buffer resources. It only guarantees that Bsend will not block if enough user buffer space is available. If you are blocking for progress anyway, I'm not sure the extra copy would matter too much -- it matters some, of course, but likely not to the extent of a full copy cost. Also, the semantics it provides are different -- guaranteed nonblocking nature when there's buffer space available. It's like saying Ssend is not as efficient as send. That's true, but those are different semantics. > > Having said that, I do agree with some of the shortcomings you pointed out -- specifically, you can only attach one buffer. I'd add to the list with one more shortcoming: It's not communicator safe. That is, if I attach a buffer, some other library I linked with might chew up my buffer space. So the nonblocking guarantee is kind of bogus at that point. > > -- Pavan > >> On Apr 3, 2015, at 5:30 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: >> >> Yes. I think the blog post gives 10 excellent reasons why. :-) >> >> >>> On Apr 3, 2015, at 2:40 AM, Lei Shi <leishi(a)ku.edu> wrote: >>> >>> Hello, >>> >>> I want to use buffered sends. Read a blog said it is evil, http://blogs.cisco.com/performance/top-10-reasons-why-buffered-sends-are-ev… >>> >>> Is it true or not? Thanks! >>> >>> Sincerely Yours, >>> >>> Lei Shi >>> --------- >>> >>> _______________________________________________ >>> users mailing list >>> users(a)open-mpi.org >>> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >>> Link to this post: http://www.open-mpi.org/community/lists/users/2015/04/26597.php >> >> >> -- >> Jeff Squyres >> jsquyres(a)cisco.com >> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss > > -- > Pavan Balaji ✉️ > http://www.mcs.anl.gov/~balaji > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [OMPI users] Buffered sends are evil?
by Balaji, Pavan 03 Apr '15

03 Apr '15

Jeff, Your blog post seems to confuse what implementations currently do with what Bsend is capable of. If users really wanted it (e.g., a big customer asked for it), every implementation will optimize the crap out of it. The problem is that every few users really care for it, so there's not been a good incentive for implementations to optimize it. Coming to the technical aspects, bsend doesn't require copying into the user buffer, if you have internal buffer resources. It only guarantees that Bsend will not block if enough user buffer space is available. If you are blocking for progress anyway, I'm not sure the extra copy would matter too much -- it matters some, of course, but likely not to the extent of a full copy cost. Also, the semantics it provides are different -- guaranteed nonblocking nature when there's buffer space available. It's like saying Ssend is not as efficient as send. That's true, but those are different semantics. Having said that, I do agree with some of the shortcomings you pointed out -- specifically, you can only attach one buffer. I'd add to the list with one more shortcoming: It's not communicator safe. That is, if I attach a buffer, some other library I linked with might chew up my buffer space. So the nonblocking guarantee is kind of bogus at that point. -- Pavan > On Apr 3, 2015, at 5:30 AM, Jeff Squyres (jsquyres) <jsquyres(a)cisco.com> wrote: > > Yes. I think the blog post gives 10 excellent reasons why. :-) > > >> On Apr 3, 2015, at 2:40 AM, Lei Shi <leishi(a)ku.edu> wrote: >> >> Hello, >> >> I want to use buffered sends. Read a blog said it is evil, http://blogs.cisco.com/performance/top-10-reasons-why-buffered-sends-are-ev… >> >> Is it true or not? Thanks! >> >> Sincerely Yours, >> >> Lei Shi >> --------- >> >> _______________________________________________ >> users mailing list >> users(a)open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >> Link to this post: http://www.open-mpi.org/community/lists/users/2015/04/26597.php > > > -- > Jeff Squyres > jsquyres(a)cisco.com > For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait
by Balaji, Pavan 03 Apr '15

03 Apr '15

You can free the request with MPI_Request_free if you don't want to wait on it. I have no idea how you'll write a correct program without waiting for receive completions at least, though. -- Pavan > On Apr 2, 2015, at 11:44 PM, Lei Shi <lshi(a)ku.edu> wrote: > > Hi Junchao, > > Thanks for your reply. For my case, I don't want to check the data have been received or not. So I don't want to call MPI_Test or any function to verify it. But my problem is like if I ignore calling the MPI_Wait, just call Isend/Irev, my program freezes for several sec and then continues to run. My guess is probably I messed up the MPI library internal buffer by doing this. > > > On Thu, Apr 2, 2015 at 7:25 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > Does MPI_Test fit your needs? > > --Junchao Zhang > > On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi(a)ku.edu> wrote: > I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do communication. But in my case, I don't really care what kind of data I get or it is ready to use or not. So I don't want to waste my time to do any synchronization by calling MPI_Wait or etc API. > > But when I avoid calling MPI_Wait, my program is freezed several secs after running some iterations (after multiple MPI_Isend/Irev callings), then continues. It takes even more time than the case with MPI_Wait. So my question is how to do a "true" non-blocking communication without waiting for the data ready or not. Thanks. > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss -- Pavan Balaji ✉️ http://www.mcs.anl.gov/~balaji _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] How to use non-blocking send/receive without calling MPI_Wait
by Huiwei Lu 03 Apr '15

03 Apr '15

Hi Lei, As far as I know, all current MPI implementations do not support true asynchronous communication for now. i.e., If there is no MPI calls in your iterations, MPICH will not be able to make progress on communication. One solution is to poll the MPI runtime regularly to make progress by inserting MPI_Test to your iteration (even though you do not want to check the data). Another solution is to enable MPI's asynchronous progress thread to make progress for you. -- Huiwei On Thu, Apr 2, 2015 at 11:44 PM, Lei Shi <lshi(a)ku.edu> wrote: > Hi Junchao, > > Thanks for your reply. For my case, I don't want to check the data have > been received or not. So I don't want to call MPI_Test or any function to > verify it. But my problem is like if I ignore calling the MPI_Wait, just > call Isend/Irev, my program freezes for several sec and then continues to > run. My guess is probably I messed up the MPI library internal buffer by > doing this. > > On Thu, Apr 2, 2015 at 7:25 PM, Junchao Zhang <jczhang(a)mcs.anl.gov> wrote: > >> Does MPI_Test fit your needs? >> >> --Junchao Zhang >> >> On Thu, Apr 2, 2015 at 7:16 PM, Lei Shi <lshi(a)ku.edu> wrote: >> >>> I want to use non-blocking send/rev MPI_Isend/MPI_Irev to do >>> communication. But in my case, I don't really care what kind of data I get >>> or it is ready to use or not. So I don't want to waste my time to do any >>> synchronization by calling MPI_Wait or etc API. >>> >>> But when I avoid calling MPI_Wait, my program is freezed several secs >>> after running some iterations (after multiple MPI_Isend/Irev callings), >>> then continues. It takes even more time than the case with MPI_Wait. So my >>> question is how to do a "true" non-blocking communication without waiting >>> for the data ready or not. Thanks. >>> >>> _______________________________________________ >>> discuss mailing list discuss(a)mpich.org >>> To manage subscription options or unsubscribe: >>> https://lists.mpich.org/mailman/listinfo/discuss >>> >> >> >> _______________________________________________ >> discuss mailing list discuss(a)mpich.org >> To manage subscription options or unsubscribe: >> https://lists.mpich.org/mailman/listinfo/discuss >> > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss > _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Unexpected results
by Winkler, Ursula (ursula.winkler＠uni-graz.at) 03 Apr '15

03 Apr '15

Hi Ken, yes. I often make the same experience - as soon as one explaines a problem to somebody else, one finds the answer. You can call that "passive" help by the listener :) Hope you have a good and - now relaxed - weekend! Ursula Von: Ken Miller [mailto:[email protected]] Gesendet: Freitag, 03. April 2015 13:01 An: discuss(a)mpich.org Betreff: Re: [mpich-discuss] Unexpected results Ursula, No worries, just glad I could get it to work. Sometimes it just takes someone to help think differently :) Thanks again. Ken On Apr 3, 2015, at 6:43 AM, Winkler, Ursula (ursula.winkler(a)uni-graz.at<mailto:[email protected]>) <ursula.winkler(a)uni-graz.at<mailto:[email protected]>> wrote: >I tried disabling the firewall real quick and still got the same results. Disabling a potential error source for trial and error is always a good thing to isolate a problem. However, at one point I got the following error: [proxy:0:1@Pi02] launch_procs (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:641): unable to change wdir to /home/pi/mpi_test (No such file or directory) So I scratched my head and wondered if it was something as silly as the fact that I was calling mpiexec from a directory that existed on Pi01 and not on the other three. I quickly created the same directory on the other three Pis and bam: pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname Pi01 Pi04 Pi03 Pi02 Was it really that simple? Thanks. Ken Yes, That *IS* possible ! :) As you mention it now - I had the same problem some years ago. Unfortunately I didn't remember in time sparing you from dealing with the same trouble. Ursula _______________________________________________ discuss mailing list discuss(a)mpich.org<mailto:[email protected]> To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Unexpected results
by Ken Miller 03 Apr '15

03 Apr '15

Ursula, No worries, just glad I could get it to work. Sometimes it just takes someone to help think differently :) Thanks again. Ken On Apr 3, 2015, at 6:43 AM, Winkler, Ursula (ursula.winkler(a)uni-graz.at) <ursula.winkler(a)uni-graz.at> wrote: > >I tried disabling the firewall real quick and still got the same results. > > Disabling a potential error source for trial and error is always a good thing to isolate a problem. > > However, at one point I got the following error: > [proxy:0:1@Pi02] launch_procs (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:641): unable to change wdir to /home/pi/mpi_test (No such file or directory) > > So I scratched my head and wondered if it was something as silly as the fact that I was calling mpiexec from a directory that existed on Pi01 and not on the other three. I quickly created the same directory on the other three Pis and bam: > > pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname > Pi01 > Pi04 > Pi03 > Pi02 > > Was it really that simple? > > Thanks. > > Ken > > Yes, That *IS* possible ! J As you mention it now – I had the same problem some years ago. Unfortunately I didn’t remember in time sparing you from dealing with the same trouble. > > Ursula > > > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Unexpected results
by Winkler, Ursula (ursula.winkler＠uni-graz.at) 03 Apr '15

03 Apr '15

>I tried disabling the firewall real quick and still got the same results. Disabling a potential error source for trial and error is always a good thing to isolate a problem. However, at one point I got the following error: [proxy:0:1@Pi02] launch_procs (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:641): unable to change wdir to /home/pi/mpi_test (No such file or directory) So I scratched my head and wondered if it was something as silly as the fact that I was calling mpiexec from a directory that existed on Pi01 and not on the other three. I quickly created the same directory on the other three Pis and bam: pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname Pi01 Pi04 Pi03 Pi02 Was it really that simple? Thanks. Ken Yes, That *IS* possible ! :) As you mention it now - I had the same problem some years ago. Unfortunately I didn't remember in time sparing you from dealing with the same trouble. Ursula _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] [OMPI users] Buffered sends are evil?
by Jeff Squyres (jsquyres) 03 Apr '15

03 Apr '15

Yes. I think the blog post gives 10 excellent reasons why. :-) > On Apr 3, 2015, at 2:40 AM, Lei Shi <leishi(a)ku.edu> wrote: > > Hello, > > I want to use buffered sends. Read a blog said it is evil, http://blogs.cisco.com/performance/top-10-reasons-why-buffered-sends-are-ev… > > Is it true or not? Thanks! > > Sincerely Yours, > > Lei Shi > --------- > > _______________________________________________ > users mailing list > users(a)open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: http://www.open-mpi.org/community/lists/users/2015/04/26597.php -- Jeff Squyres jsquyres(a)cisco.com For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/ _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0

Re: [mpich-discuss] Unexpected results
by Ken Miller 03 Apr '15

03 Apr '15

I tried disabling the firewall real quick and still got the same results. However, at one point I got the following error: [proxy:0:1@Pi02] launch_procs (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmip_cb.c:641): unable to change wdir to /home/pi/mpi_test (No such file or directory) So I scratched my head and wondered if it was something as silly as the fact that I was calling mpiexec from a directory that existed on Pi01 and not on the other three. I quickly created the same directory on the other three Pis and bam: pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname Pi01 Pi04 Pi03 Pi02 Was it really that simple? Thanks. Ken On Apr 3, 2015, at 3:05 AM, Winkler, Ursula (ursula.winkler(a)uni-graz.at) <ursula.winkler(a)uni-graz.at> wrote: > Hi, > > did you check the firewall? > > Ursula > > Von: Ken Miller [mailto:[email protected]] > Gesendet: Freitag, 03. April 2015 02:34 > An: discuss(a)mpich.org > Betreff: [mpich-discuss] Unexpected results > > Hello, > > I am hoping someone might be able to point out what I am doing wrong. I have setup a Raspberry Pi cluster by going through a couple tutorials. The last step is to use MPI to test the cluster. Everything was going great until I ran the following command: > > mpiexec -f machinefile -n 4 hostname > > My machinefile contains the following: > > pi@Pi01 ~/mpi_test $ cat machinefile > 192.168.2.121 > 192.168.2.122 > 192.168.2.123 > 192.168.2.124 > > But, when I run the mpiexec command, I get the following error: > > pi@Pi01 ~/mpi_test $ mpiexec -f machinefile -n 4 hostname > Pi01 > [mpiexec@Pi01] control_cb (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmiserv_cb.c:200): assert (!closed) failed > [mpiexec@Pi01] HYDT_dmxu_poll_wait_for_event (/home/pi/mpich2/mpich-3.1/src/pm/hydra/tools/demux/demux_poll.c:76): callback returned error status > [mpiexec@Pi01] HYD_pmci_wait_for_completion (/home/pi/mpich2/mpich-3.1/src/pm/hydra/pm/pmiserv/pmiserv_pmci.c:198): error waiting for event > [mpiexec@Pi01] main (/home/pi/mpich2/mpich-3.1/src/pm/hydra/ui/mpich/mpiexec.c:336): process manager error waiting for completion > pi@Pi01 ~/mpi_test $ > > Clearly, I am missing something. Would appreciate any help in advance. > > Thanks. > > Ken > > ps. I am connected to the other Pis evident by the following ping results. I can also log into each of the other 3 Pis. > > ping 192.168.2.122 > PING 192.168.2.122 (192.168.2.122) 56(84) bytes of data. > 64 bytes from 192.168.2.122: icmp_req=1 ttl=64 time=0.807 ms > 64 bytes from 192.168.2.122: icmp_req=2 ttl=64 time=0.626 ms > 64 bytes from 192.168.2.122: icmp_req=3 ttl=64 time=0.614 ms > 64 bytes from 192.168.2.122: icmp_req=4 ttl=64 time=0.605 ms > 64 bytes from 192.168.2.122: icmp_req=5 ttl=64 time=0.603 ms > ^C > --- 192.168.2.122 ping statistics --- > 5 packets transmitted, 5 received, 0% packet loss, time 4002ms > rtt min/avg/max/mdev = 0.603/0.651/0.807/0.078 ms > pi@Pi01 ~/mpi_test $ ping 192.168.2.123 > PING 192.168.2.123 (192.168.2.123) 56(84) bytes of data. > 64 bytes from 192.168.2.123: icmp_req=1 ttl=64 time=0.794 ms > 64 bytes from 192.168.2.123: icmp_req=2 ttl=64 time=0.634 ms > 64 bytes from 192.168.2.123: icmp_req=3 ttl=64 time=0.628 ms > 64 bytes from 192.168.2.123: icmp_req=4 ttl=64 time=0.607 ms > ^C > --- 192.168.2.123 ping statistics --- > 4 packets transmitted, 4 received, 0% packet loss, time 3003ms > rtt min/avg/max/mdev = 0.607/0.665/0.794/0.081 ms > pi@Pi01 ~/mpi_test $ ping 192.168.2.124 > PING 192.168.2.124 (192.168.2.124) 56(84) bytes of data. > 64 bytes from 192.168.2.124: icmp_req=1 ttl=64 time=0.787 ms > 64 bytes from 192.168.2.124: icmp_req=2 ttl=64 time=0.632 ms > 64 bytes from 192.168.2.124: icmp_req=3 ttl=64 time=0.612 ms > ^C > --- 192.168.2.124 ping statistics --- > 3 packets transmitted, 3 received, 0% packet loss, time 2002ms > rtt min/avg/max/mdev = 0.612/0.677/0.787/0.078 ms > pi@Pi01 ~/mpi_test $ > _______________________________________________ > discuss mailing list discuss(a)mpich.org > To manage subscription options or unsubscribe: > https://lists.mpich.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss(a)mpich.org To manage subscription options or unsubscribe: https://lists.mpich.org/mailman/listinfo/discuss

1 0