Hi Rich, I suspect that this is a software rendering issue (Mesa). That's ~ 1.5M quads so I am still surprised that it is slow with 4 MPI ranks but I guess that's Mesa's performance on that machine. The simplest test is to use the sphere source with MPI rank and adjust the number of triangles to get a feel for triangles/second that Mesa can handle on 1 process. That should give you a feel for how many ranks you need to handle a certain geometry size. Mesa can now be compile multi-threaded so that may be one thing to try.
Best, -berk On Wed, Oct 30, 2013 at 8:02 PM, Cook, Rich <[email protected]> wrote: > I think I just wasn't throwing enough horsepower at it. I underestimated > the rendering requirements of a 512^3 mesh. My bad. Adding more servers > sped things up dramatically. Duh. > > On Oct 30, 2013, at 3:33 PM, "Cook, Rich" <[email protected]> > wrote: > > > On Oct 29, 2013, at 5:45 PM, "Scott, W Alan" <[email protected]> wrote: > > Rich,**** > You are probably doing something wrong. :-) I assume you are using PV > 4.0.1.**** > > After setting up the local client/ remote server, using more than one > server, try the following:**** > · Help/ About. Click on Connection Information. You should see > the correct number of Processes (i.e., pvservers). Now you know you are > running in parallel with MPI. > > Yep. > > **** > · Edit/ Settings/ Server. Change Remote Render Threshold to 0. > You are now rendering remotely on the cluster. Make the ParaView window > quite small. Tools/ Timer log. Clear. Close. Sources/ Sphere. Apply. > Spin it. Tools/ Timer log. Is it fast enough? On redsky, going through > a disgusting number of layers from my ParaView client to my desktop (think > X forwarding), I am getting 15 to 30 frames/second. Clear the timer log. > > 0.054 sec/render == 18.5 FPS > > > **** > · Make ParaView full screen. Spin, spin. Timer log. I get > about 10 frames/second interactive, 2 frames /second still. (This > represents time with my finger on the mouse, time with finger off the > mouse). This tells you how fast your network is pushing 2d images from the > server to the client. (As I said, for me, it is a SSLLOOWW pipe between me > and my client.) > > About 4.5-5 FPS interactive, 3.5-5.0 still > I guess this means my network from our cluster to my desktop is crappy, I > guess because of ssh tunnel? Tunnel is necessary due to topology. > > **** > · Make ParaView small screened once again. Change the sphere’s > Theta resolution to 1000 and Phi Resolution to 1000. You now have around 2 > million cells. Spin, spin. Timer log. This represents the speed of the > cluster, since we are having to render all of those triangles (cells) > (actually vertexes) in the Mesa3d software renderer. > > Interactive Render, 0.229963 seconds > > OpenGL Dev Render, 7e-05 seconds > > OpenGL Dev Render, 0.000525 seconds > > OpenGL Dev Render, 1.6e-05 seconds > > Interactive Render, 0.212467 seconds > > OpenGL Dev Render, 6.7e-05 seconds > > OpenGL Dev Render, 0.000532 seconds > > OpenGL Dev Render, 1.7e-05 seconds > > Still Render, 0.734462 seconds > > OpenGL Dev Render, 0.000118 seconds > > OpenGL Dev Render, 0.000521 seconds > > OpenGL Dev Render, 1.6e-05 seconds > > Still Render, 0.723525 seconds > > > > > > **** > · Clear the timer log. Delete the Sphere. View/ Memory > Inspector. (This lets you know if you are overflowing memory. Further, > you should have as many pvservers as you think you have. If you see one, > you have an MPI issue.) Sources/ Wavelet. > > > No memory problems. Expected number of servers. > Should I do something with the wavelet? > > **** > > By the way, if I were running the client locally (which I often do), I > will get frame rates over 60/second connecting to the clusters. Connecting > to clusters across state lines will slow things down to 4 to 10 FPS or less. > **** > > Huge, hero size data will also slow things down a lot.**** > > Another thing to try is use the Process Id Scalars filter. That will > show you how your data is being spread around. It is very possible that > your data is being read through a serial reader, and only going into one > process (server). > > > I thought this would show the problem, but it looks like data is > decomposed correctly. > > > **** > > Don’t turn volume rendering on or opacity on (at first, anyway).**** > > If that doesn’t help, I will be in tomorrow (and tonight for another > hour) – if we need to chat. > > > Would like that -- must still be missing something obvious… > > **** > > > Alan**** > > > > *From:* [email protected] [mailto:paraview- > [email protected]] *On Behalf Of *Cook, Rich > *Sent:* Tuesday, October 29, 2013 6:16 PM > *To:* [email protected] > *Subject:* [EXTERNAL] [Paraview] horrible slow performance -- I must be > doing something very wrong**** > ** ** > Hello**** > I am running paraview in client-server mode. I start the client on my > desktop, run pvserver in parallel with four instances and connect my client > to the "ringleader" pvserver through an ssh tunnel. The data is a > 512x512x512 rectilinear grid in Miranda format. **** > I open my data and attempt to render a simple picture of my data and it > is so slow I'm going to kill myself. Maybe one frame every 5 or 10 > seconds. I'm imagining that the geometry is being shipped to my client, > and the client is doing the rendering, but I don't know that. **** > Am I doing some basic thing wrong? How can I get reasonable > performance?**** > Thanks **** > ** ** > -- **** > ✐Richard Cook **** > ✇ Lawrence Livermore National Laboratory**** > Bldg-453 Rm-4024, Mail Stop L-557 **** > 7000 East Avenue, Livermore, CA, 94550, USA**** > ☎ (office) (925) 423-9605 **** > ☎ (fax) (925) 423-6961**** > ---**** > Information Management & Graphics Grp., Services & Development Div., > Integrated Computing & Communications Dept.**** > (opinions expressed herein are mine and not those of LLNL)**** > > > > **** > ** ** > > > -- > ✐Richard Cook > ✇ Lawrence Livermore National Laboratory > Bldg-453 Rm-4024, Mail Stop L-557 > 7000 East Avenue, Livermore, CA, 94550, USA > ☎ (office) (925) 423-9605 > ☎ (fax) (925) 423-6961 > --- > Information Management & Graphics Grp., Services & Development Div., > Integrated Computing & Communications Dept. > (opinions expressed herein are mine and not those of LLNL) > > > > > -- > ✐Richard Cook > ✇ Lawrence Livermore National Laboratory > Bldg-453 Rm-4024, Mail Stop L-557 > 7000 East Avenue, Livermore, CA, 94550, USA > ☎ (office) (925) 423-9605 > ☎ (fax) (925) 423-6961 > --- > Information Management & Graphics Grp., Services & Development Div., > Integrated Computing & Communications Dept. > (opinions expressed herein are mine and not those of LLNL) > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the ParaView Wiki at: > http://paraview.org/Wiki/ParaView > > Follow this link to subscribe/unsubscribe: > http://www.paraview.org/mailman/listinfo/paraview > >
_______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the ParaView Wiki at: http://paraview.org/Wiki/ParaView Follow this link to subscribe/unsubscribe: http://www.paraview.org/mailman/listinfo/paraview
