low_cpu

• Type: Integer
• Range / Valid values: 0 - 100
• Default: 0 (disabled)
• Group: Obsolete

When this option is not zero motion will be in a low cpu mode while not detecting motion. In low cpu mode Motion reduces the framerate to the value given for this option. Value zero means disabled. ( DEPRECATED )

low_cpu

• Type: Integer
• Range / Valid values: 0 - 100
• Default: 0 (disabled)
• Option Topic

When this option is not zero motion will be in a low cpu mode while not detecting motion. In low cpu mode Motion reduces the framerate to the value given for this option. Value zero means disabled. ( DEPRECATED )

This is smart for running a server that also does other tasks such as running Apache, MySQL etc. Motion grabs this lower number of frames per second until it detects motion. Then it speeds up to normal speed and take pictures as set by the option "framerate".

Comments

---

I would like to remove this option/feature when doing the pre_capture redesign. It makes things unnecessary complex. I don't even know how smartmask performs with low_cpu turned on. With the MMX-ASM optimisation in alg_diff_standard, we shouldn't need this feature any longer.

-- JoergWeber - 14 Apr 2005

---

I sort of agree. The issue Motion has with CPU load is when Motion is beeing detected and then this parameter does not help at all.

-- KennethLavrsen - 14 Apr 2005

---

This feature would be VERY USEFUL for network cameras if it were modified slightly! I use motion this way for security cams. Checking every 5-10 seconds would be nicer to my network traffic, and then full speed only when motion is detected, but I don't see a way to do this with the current parameters. (in other words, something like low_cpu but the value is seconds between samples instead of frames per second)

-- TWikiGuest - 26 May 2005

---

I like this option. However, it should be determined by "gap". It makes sense that it should drop to low framerate after the end_of_event. At the moment, I'm not sure how it determines when to drop down, perhaps it's hard coded.

-- JoeFreel - 20 Sep 2006

The low_cpu condition is suspended when motion is detected above the threshold and re-entered when no Motion is detected AND the post_capture frames have been saved or added to the current movie. So it is the post_capture option that defines when to drop down. -- KennethLavrsen - 20 Sep 2006

---

What's the difference of setting this to 10 or to 90? By the description it looks like a boolean to me (0 and 1-100 the two choices), cause of that I don't understand why I can set it to other values than 0 or 1.

Thanks.

-- LuarRoji - 13 Feb 2007

---

The value given is the framerate used when Motion is not detected

-- KennethLavrsen - 14 Feb 2007

---

Thanks Kenneth, I can't believe I didn't see where it says: " In low cpu mode Motion reduces the framerate to the value given for this option"!

I'm using a network camera, and tried different settings for lowering the data transferred when no motion but didn't work. I think that maybe it's the camera that doesn't understand motion's parameters.. How can I know if the camera supports this capability?

Thanks again! (sorry for making this page a FAQ, I thought maybe the answers can help other ones too)

-- LuarRoji - 15 Feb 2007

---

Hi,

I am working on netcam fps at the moment.

My findings are that Motion cannot reduce the frame rate of a network camera, since it's the camera that sources the information. So low_cpu has no effect on a netcam. My own netcam (DLink DCS-900) has a throttling feature where you can specify the frame rate required (approximately) on the internal web page config.

I am also working on a patch to throttle a netcam in software, ie. Motion will dispose of frames, if the camera's measured fps is greater than that specified in the motion.conf file. It will work by just 'throwing away' frames before they get processed for despeckle etc. That saves cpu time. It is still very early days for this concept, and no patch file is yet available....

-- SimonW - 15 Feb 2007

---

-- SimonW - 07 Mar 2007

---

I now have a working patch to throttle a netcam. The patch can be found as part of " StatisticsDataPatch " latest version. I have verified that it works ok and still detects motion. I would welcome others testing it now.

Since netcams have a relatively fixed image-sending rate, if Motion is set to a lower fps than that rate, the 'throttle' algorithm throws away frames received. The retained frames are evenly spread out in time (1 every 'n' frames). Every second, the 'throttled fps' is compared with the requirement, and the rate of frame disposal adjusted if necessary.

Due to the way Motion works, although a netcam may send 20 frames per second, that does not mean that Motion processes (uses) them all, especially as it takes some time to decompress the jpeg image and then do motion-detection. The jpeg-decompress in particular is a mutally exclusive process (as far as I can tell from the code). Only when the jpeg-decompress routine is finished, is a new frame begun. Any frames arriving while it is busy are simply overwritten with the newer data. Thus the actual " MotionThruPut " is lower, due to mutual exclusion (and processor power). This figure is reported on the Statistics page for each thread, so the actual rate versus the expected rate can be compared.

The throttling patch supports fractional frame rates, by looking at the value of minimum_frame_time. (This is actually a standard Motion feature). Example: frame_limit is 2, but minimum_frame time is 3. The figure of 2 is ignored, giving a frame rate of 1/3 ie. 0.33 fps.

The benefit of throttling a netcam is that it permits the limited resource of the CPU for jpeg-decompression to be shared between more cameras. It reduces system load by not processing more frames per second than actually needed - this has not been possible until now.

Of course, if you throttle down a camera too much (say, less than 2 fps) then fast events will not be noticed. Don't forget that minimum_motion_frames must be adjusted to reflect the reduced (throttled) rate, or almost no motion will be ever be detected.

-- SimonW - 07 Mar 2007

---

Is this option being/has been removed?

I really liked this option. It allowed me to have 8 cameras at once on screen, and if there was motion in one of the cameras, I could still see it live with high fps and be able to see all the other cameras.

Without this option, I cannot have nearly as many cameras on screen at the same time without sending my CPU load on both the motion server and the client viewing the streams.

-- BobSaggeth - 26 Sep 2007

---

In version 3.2.10. this option will be removed, yes. It is imcompatible with several internal funtions of Motion. When motion is idle, low_cpu will most likely not save any noticable resources.

I suggest to use the webcam_motion feature instead. It should give the same result without affecting internal timing.

-- JoergWeber - 26 Sep 2007

---

I agree with BobSaggeth, it would be nice to be able to tell motion not to be pulling frames at max speed all the time, and save the bandwidth for when something is really going on.

-- MattCastelein - 18 Nov 2010

---