[Paraview] [EXTERNAL] horrible slow performance -- I must be doing something very wrong

Berk Geveci berk.geveci at kitware.com
Thu Oct 31 07:36:39 EDT 2013


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 <cook47 at llnl.gov> 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" <cook47 at llnl.gov>
>  wrote:
>
>
>  On Oct 29, 2013, at 5:45 PM, "Scott, W Alan" <wascott at sandia.gov> 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:* paraview-bounces at paraview.org [mailto:paraview-
> bounces at paraview.org] *On Behalf Of *Cook, Rich
> *Sent:* Tuesday, October 29, 2013 6:16 PM
> *To:* paraview at paraview.org
> *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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20131031/7db0c076/attachment-0001.htm>


More information about the ParaView mailing list