On 05/06 02:47, Ashley Dixon wrote: > On Wed, May 06, 2020 at 09:16:33AM -0400, Walter Dnes wrote: > > It looks like blender is a heavy-duty program that bogs down your > > system. You could buy a new machine, or you could try the "nice" > > command. The tradeoff is that your system becomes more responsive > > because the program is launched with a lower priority. The usual > > priority levels range from 20 (lowest priority for your program) to > > -19 (highest priority for your program). Note that you have to use > > root or sudo to use negative nice-level (higher priority). > > Considering the specifications of Meino machine, this is not expected > behaviour > from any application. I doubt it is possible for a standard consumer to buy > a > machine with much better hardware; this is certainly a more serious > issue, > whether it be faulty hardware or misbehaving software. > > What else is running at the time of Blender locking up ? Are you absolutely > sure > that it is Blender causing this issue ? > > -- > > Ashley Dixon > suugaku.co.uk > > 2A9A 4117 > DA96 D18A > 8A7B B0D2 > A30E BF25 > F290 A8AA >
Hi Ashley! ;) Short explanation: With blender you can do animation. For animations you need to "explain to Blender" how thing should move. This is done in the so called "graph editor" which is - amthemtically spoken - nothing more than a lot of X/Y graphs, where X is identical to the current frame number - hence the time axis - and Y is the amount of movement in direction of one of the Ds in "3D". Rendering is no problem (ok, the system "lacks" a little, but that is expected since a lot of calculation power is drawn). But if I click into the graph editor to directly jump to quite different frame than the previous or next one, everything freezes. Blender hast to end its calculations and THEN everything goes back to normal. In this time the CPU goes not in full load -- otherwise the fans would become very busy (as they do when starting rendering). The problem here is not, that a sudden load is put onto the system - that is normal and intended - the problem is, that everyting locks up. As said, it /feels/ like a lock on a system bus or whatelse, what will only be released, when the calculation for the frame jump has been ended. Since Linux is a multitasking and multithreading OS and the PC has six cores and 12 threads, there should be at least one thread left to handle the keyboard while calculating frames - IF the CPU get the bus at all. The example with the bus being locked is AN EXAMPLE ONLY. I have no clue, whether something gets locked at all and if so, what gets locked. There is "nothing" else running except for the usual daemons, the kernel, openbox, a shell, a terminal. Or with other words: Nothing stressful. And I /think/ (read: I don't know), I could have something to do with the communication with the GPU...: If I switch of the preview, there are no locks anymore. And I think my PC is causing the problem (instead of blender) since the problem arises with three different versions of blender. Blender is used quite often, my PC is a combination, which is used quite often and I didn't find anything (including the bugtracker of the Blender development), which could point me to the root of that problem. On the other hand: I included the gpu-related USE flags into make.conf and recompiled all related software. Chances are there, that I would have triggered the problem with another application if this problem is caused by a bogus hardware (includind me screwing up some awkward BIOS setting). I am NOT overclocking and I am using "stock settings" in the BIOS (beside the XMP settings for the RAM - but those are settings quaranteed to work by the vendor of the RAM). If any reader of the "Book of possible bogus hardware" is now that confused as I am - you are welcome ! :) Cheers! Meino
