Is it just me, or does any computer running Flame need excessive reboots?
I generally only use flame on Linux in large facilities, where engineering’s first response to any issue is, ‘Did you reboot?’
Other studios where this isn’t the policy, you’ll jump on a machine that has a serious case of the slows, and just rebooting it, will sometimes make a render magically go 10x faster.
I haven’t noticed this as much on Macs running flame. And if I don’t use flame, I can let a mac go for a month without rebooting.
Windows machines doing just about anything seem to want a daily reboot, but you know, it’s windows…
Do people out there reboot all flames all the time, or I have just worked in places that have issues….
2 Likes
Well, Linux can routinely run 365 days and longer without a reboot. More or less a reboot should only be required for hardware maintenance or major OS upgrades. It’s one thing that sets Unix apart from Windows and other OSes.
This shouldn’t be different with Flame running. I’ve gone for months without rebooting.
For the most part Mac and Windows are not far behind these days. There are valid reasons to reboot, but the IT knee jerk is being a bit lazy in my mind.
1 Like
Flame leaks VRAM with motion vectors. Just reported another case 2 days ago. Generally a software restart fixes it, but our company policy is “don’t logout out, reboot” at end of days. Usually I do a good faith reboot in the mornings too.
1 Like
I reboot daily. It makes things less “buggy.”
I don’t know if you are talking about reboot “flame” the PC or “flame” , the software. I don’t think that reboot the PC is needed at all.
But flame is a complete vram devourer. More and more with each new version. For large batches, high resolutions, paints, it can wreck performance, even for rendering. There is no purge button, so the only solution is to restart flame, the software.
5 Likes
I tend to reboot several times a week, usually in the morning if I left an archive running overnight.
I recently gave up 49 days of uptime on my z840 when restarting tangenthub could no longer get it to see the element panels again. A reboot fixed it, but dang!
1 Like
I quite flame at the end of each day. I reboot the machine maybe every week or so.
I usually reboot once daily, and eventually when working with heavy textures, motion vectors, or bigger resolutions than 4K. Also, the “yellow” dots to cache the render node, when on, they kill the VRAM. It is better to use a hard render with a write node.
I don’t even reboot, I turn it off and on and it is a charm for the system! Suddenly I go from a render taking 30 minutes to 2/3 minutes, same render, same settings…all the same.
Companies don’t like rebooting the systems as in some cases, the reconnection takes 20 minutes. I never understood why it takes that much and always thought it was a bad system administrator who was running it, but I might be wrong and there are a good number of reasons up there for this to happen, but in any case, the systems would perform better just by turning them off daily, with a system to turn them on 30 minutes before starting the day. They would perform much better.
This is interesting. I often see a change in render time from restarting Flame (Linux). Exiting and restarting the software brings my VRAM back.
The only time I reboot is if I have had a crash or one of my services is being stubborn.
Yes, I think there’s a big distinction between rebooting the OS and restarting an application.
A lot of work has gone into making the OS itself resilient to stability issues, resources leaks, etc. The same cannot be said about most apps, especially ones which rely on a large number or 3rd party modules, etc.
No particular excuse, just facts. OS developers aren’t constantly pestered for new features and generally value stability a great deal. App developers are always behind the curve on features that should be added, so stability improvements often lag behind and then occasionally when the straw breaks, they’ll make a dedicated release towards squashing leaks and crashes.
Different circumstances and mentalities.
Most OS instability comes actually from 3rd party drivers. Of which Windows and MacOS of course have many more, since we have a habit of connecting a truck load of gadgets to them and lots of little tools for the daily conveniences. The lack of such tools and gadgets for Linux systems is probably a blessing in disguise. These system seem to be much more purpose driven than your main desktop.
I bet most Linux Flame reboots come from Wacom or Tangent drivers getting twisted up. Or monitors switching. There are commands to probe hardware changes and deal with this without a reboot, but sometimes it’s not worth the hassle. Of course you risk some other thing you started or network share you mounted and didn’t put into /etc/fstab not combing back automatically and you’ll be swearing about that.