<div dir="ltr">> <span style="font-size:12.8px">It's been </span><span style="font-size:12.8px">uncommon to have such a configuration AFAIK, frankly I was a little</span><br style="font-size:12.8px"><span style="font-size:12.8px">surprised to see someone mentioning some modern G200 use case.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Supermicro servers uses the Nuvoton WPCM450 BMC and it is off of that where the Matrox G200eW resides (for the console/video output/display). (The manual for the system has a copyright date of 2014, so it's fairly recent. Their newer stuff uses Aspeed AST chips instead.)</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">Now I'm curious, what exactly is it you're doing? Is your task</span></div><span style="font-size:12.8px">actually using the GUI or is it a console thing running in a terminal</span><br style="font-size:12.8px"><span style="font-size:12.8px">and scrolling output? Is there any visual output at all during the</span><br style="font-size:12.8px"><span style="font-size:12.8px">analysis? Are you just using a heavyweight desktop shell like gnome</span><br style="font-size:12.8px"><span style="font-size:12.8px">shell and that's what is contending for CPU now that it's</span><br style="font-size:12.8px"><span style="font-size:12.8px">unaccelerated?</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">- If the slowdown is just due to scrolling terminal text, redirect</span><br style="font-size:12.8px"><span style="font-size:12.8px"> output to a file rather than having X display it all realtime.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">- If it's a fancy composited desktop environment hogging CPU when</span><br style="font-size:12.8px"><span style="font-size:12.8px"> unaccelerated, try using something lightweight like xfce or twm.</span><div><span style="font-size:12.8px"><br></span></div><div>I perform computer aided engineering (CAE) analyses (so finite element analysis (FEA) and computational fluid dynamics (CFD)).</div><div><br></div><div>What I have is a FEA case that I had set up some time ago that I now use as a benchmark case because that case is well known to me and the results have been well validated. I use it to assess both hardware (e.g. when I get new hardware) and software (when new releases of the analysis software are published) to make sure that hardware and software are both able to produce the validated results.</div><div><br></div><div>As such, I have a shell script that I run where it will perform 16 runs sequentially (of the validated model) (it is actually two models, two solvers, two different types of contacts that are being used, and whether the files are on a SSD or on a HDD).</div><div><br></div><div>I start the shell script via a terminal on the console and then it just runs in the foreground, but nothing is being displayed. (The only reason why anything is even shown is being ahead of the command that actually executes the analysis, I have a <font face="monospace, monospace">time -p</font> command in front of it.) If it weren't for that, literally nothing would be output back to the terminal window in the desktop/GUI environment.</div><div><br></div><div>Yes, I am using GNOME. (Not sure how and/or IF you can switch the default GUI from GNOME to something else like KDE. GNOME was the option available during the installation.)</div><div><br></div><div>The other way that run these analysis, I will actually start the graphical analysis environment and I will actually open the model (graphically), and click on the solve button, and it will have more stuff going on graphically (e.g. periodic update showing the latest status of the run).</div><div><br></div><div>But that isn't what I am currently running right now. Right now, it is still just the shell script running from the terminal window on the console.</div><div><br></div><div>I think that the slowdown is because the CPU now has to draw the desktop/GUI using CPU cycles rather than the graphics adapter, regardless of whether there are any "visual" updates. My theory is that the mere fact that it has to draw it (and keep drawing/redrawing it at the refresh rate) is taking up CPU cycles and that's causing the slowdown as it is stealing CPU resources to do that (away from the actual numerical/computational analysis).</div><div><br></div><div>I was trying to use ssh -Y (and cygwin/X), but people advised against it. There was a suggestion for me to try and use Xvnc instead. I haven't tried that yet. In another source online, (re: ssh -Y), they suggest using Xming (source: <a href="https://www.redwireservices.com/remote-x11-for-linux-unix">https://www.redwireservices.com/remote-x11-for-linux-unix</a>). I haven't tried that yet either (but being that it is still ssh -Y, the advice against doing that still stands regardless of whether I'm using cygwin/X or Xming).</div><div><br></div><div>The presence of a GUI is required because for some use cases of the analysis application, the analysis features/functionality is integrated into their desktop application environment which requires the GUI to "kick off"/initiate. (Please see this thread on the SuSE forums for a more detailed explanation of that: <a href="https://forums.suse.com/showthread.php?9728-memory-leak-issue/page5">https://forums.suse.com/showthread.php?9728-memory-leak-issue/page5</a>)</div><div><br></div><div>(That thread also talks about what the analysis software developer calls that if I try to perform the analysis outside of the graphic environment, it can cause a type 3 error state with respect to the integrated file manager inside the desktop application such that there are now new files in the project directories that the file manager doesn't recognize and therefore; thinks they don't belong there. It puts the project out of sync with its file manager - a part of the desktop application that's responsible for making sure that the project data stays consistent.)</div><div><br></div><div>Hope that helps.</div><div><br></div><div>Thanks.</div><div><br></div><div>Sincerely,</div><div>Ewen</div><div><div><span style="font-size:12.8px"><br></span></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 7, 2017 at 1:30 PM, <span dir="ltr"><<a href="mailto:xorg@pengaru.com" target="_blank">xorg@pengaru.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Thu, Dec 07, 2017 at 11:22:30AM -0500, Ewen Chan wrote:<br> > Hi-Angel:<br> ><br> > > Yes, now it should be using CPU for rendering.<br> ><br> > Hmmm...I am not so sure if that was really what I want.<br> ><br> > It just reminds me of the adage of where you fix a leak/problem at one<br> > part/section of a pipe, but then create another one problem somewhere else<br> > down the pipe.<br> ><br> > > That's one more of beauties of open source<br> ><br> > The thing that I can think of that would be even more beautiful than that<br> > would be if this didn't happen at all in the first place. :D<br> ><br> > This "memory leak" or high consumption of memory from the subsystem that<br> > draws/renders the desktop/GUI doesn't happen at all with Windows no matter<br> > how many times I run the same analysis script.<br> ><br> > My early subjective analysis (with this mgag200 blacklist) puts the time it<br> > takes to run the simulations now on par with Windows and Windows just<br> > worked (properly) like this from the get go.<br> ><br> > People keep talking about great and wonderful Linux is, but this experience<br> > has been anything but.<br> ><br> > I think that I've spent about as much time trying to find a resolution to<br> > this issue as I have had doing my actual analysis work.<br> ><br> > Pros (for Linux): It's faster when it is running at runlevel 3.<br> ><br> > Cons: Can't use the GUI (because if I blacklist the driver for runlevel 5,<br> > then the performance is about the same as it is in Windows, at which point,<br> > why not just use Windows? The set up of a Windows system to get it up and<br> > running to this same level/state is significantly faster.)<br> ><br> </div></div>> Such a pity really that this has the potential to be **A**, if not **THE**<br> <span class="">> solution to this problem.<br> ><br> > Hmmm....it's been interesting.<br> ><br> > I can still try other stuff (like iomem=relaxed), both either with the<br> > mgag200 or without it.<br> ><br> <br> </span>For the record, the mga driver is quite old, pre-dating x86_64 and<br> most of its life was even pre hardware 3D acceleration. Prior to<br> these transitions Matrox Milleniums were some of the best supported<br> graphics cards in Linux/X.<br> <br> It would not surprise me if the problem you're experiencing is a<br> relatively trivial bug in the mga driver on x86_64. It's been<br> uncommon to have such a configuration AFAIK, frankly I was a little<br> surprised to see someone mentioning some modern G200 use case.<br> <br> Now I'm curious, what exactly is it you're doing? Is your task<br> actually using the GUI or is it a console thing running in a terminal<br> and scrolling output? Is there any visual output at all during the<br> analysis? Are you just using a heavyweight desktop shell like gnome<br> shell and that's what is contending for CPU now that it's<br> unaccelerated?<br> <br> - If the slowdown is just due to scrolling terminal text, redirect<br> output to a file rather than having X display it all realtime.<br> <br> - If it's a fancy composited desktop environment hogging CPU when<br> unaccelerated, try using something lightweight like xfce or twm.<br> </blockquote></div><br></div>