Swap Partitions... required, recommended or redundant in TC?

[CentralWare]

I have a semi-meaty machine (dual-core 3.x ghz with about 12GB ram) which depending on the app, acts like it's an old Geode thin client.
eg: Under TC4x64, running ffmpeg to convert a media file takes roughly 1.75 times longer than on a Win machine of lesser caliber.  This led me to wonder whether or not I had something misconfigured.

I then launched GV (guvcview) on the same machine capturing 1024x768 from a M$ webcam for 10 minutes.  The drop rate was horrendous and 8:51 out of 10:00 was saved.  Of course, Win had a few drops, but not even enough to cause a full second (30fps) of loss and on a machine with 4GB and a 2.2 dual processor.)  It's saving to a SATA-III drive and 6gbps controller, so I don't "imagine" it's storage related.

My rebellious side said "M$ can't outrun Linux!" and I'm determined to figure out what problems might exist.

The only thing I can think of is the swap or the amount of memory (virtual) being used for TC.
The swap isn't specified nor is there a dedicated partition, thus zram takes over that one, which I would have thought to be an increase in through-put as opposed to using a hard drive swap.  (Please enlighten me if possible on this one!?)

Any clues would be tremendously appreciated!

[Juanito]

I would have thought 12gb ram would be plenty.

Just in case, you could use the "noswap" boot code.

The tc-4.x version of ffmpeg is quite old, did you try the tc-6.x version to see if that makes a difference?

Edit: were you using core64 or corepure64?

[curaga]

Forcing the performance cpu governor might also help. If the load is on the borderline of low and high, ondemand may not notice it well enough.

[nitram]

centralware wrote:
The swap isn't specified nor is there a dedicated partition, thus zram takes over that one, which I would have thought to be an increase in through-put as opposed to using a hard drive swap.  (Please enlighten me if possible on this one!?)

You may want to trial the nozswap bootcode. As per wikipedia, zswap requires additional CPU cycles for compression. So if you're not running out of RAM, try disabling zswap.

zswap is a Linux kernel feature that provides a compressed write-back cache for swapped pages, as a form of virtual memory compression. Instead of moving memory pages to a swap device when they are to be swapped out, zswap performs their compression and then stores them into a memory pool dynamically allocated inside system's RAM. Later writeback to the actual swap device is deferred or even completely avoided, resulting in a significantly reduced I/O for Linux systems that require swapping; the trade-off are additional CPU cycles required for compression.

http://en.wikipedia.org/wiki/Zswap

[CentralWare]

Thanks to you all for your input!

@nitram: Will do!  I never read up on zram/swap (and thus never noticed it even compressed) so it's a good place to look.

@Curaga: I have not modified performance, but couldn't help but notice the cores running at around 50% on boot.  I imagine this was intended for power savings (by the author) but I can imagine it going from idle to red-line by launching an app and hiccups occurring, so this will also be a direction I'll investigate on low and high end machines to see what kind of tweaking might be needed to get more of a "perfect fit."

@Juanito: The same thought (12GB) is why I chose that machine to test under.  Now I'm curious as to how mapped memory (init setting 90%) affects this as in some cases I could imagine it being more fruitful to set up case/switch determination (ie: if RAM < xGB set 90%, if < yGB set 75% and so forth) allowing more untouched ram to exist in the pool thus preventing (in my eyes) remapping...  but I'll experiment to see how the numbers add up and whether or not a given change causes positive or negative results.

Updates:

TC4 core64.gz, not pure.

I have NOT tried more recent releases (ie: 6.x repo) as the software may get more improvements, but it's the core I'm zoomed in on for the moment.  I have 7 notebook sheets and a 4' white-board listing the tests which I've used on 4.x thus far and are intended to be done on 5.x and newer, so eventually I'll have a strength/weakness list to post, but that's probably a month away based on "free" time.

Concept: There are "x' millions or more lines of code which TC is comprised of when you think of it by taking a step back.  In some instances, adding program "A" or script "B" can cause negative results based on the kernel being used, the kernel settings internally, boot codes and the init/fs being loaded.  I "know" a fraction of a fraction of those lines of code thus sending out posts like this bring in others who have other fractions they're personally familiar with.  The test bench(es) here go only as far back as an i586 (686 with limitations, detected as 586) VIA embedded board and only go as far forward as dual-core AMD and Intel chips, with a few odd-balls like Vision-Bank (Geode) integrated kiosks, your run of the mill Wyse terminals and so forth, thus we like to beat something to a pulp from every walk of life we have access to "looking" for problems.  If a program I write passes the majority of these different breeds, I tend to feel much more secure knowing it'll handle "what's out there today."  TC is a recent addition to my long list of PXE and CD/HDD boot environments...  the ongoing support within this forum makes it that much more worthwhile to push forward!  Enough so, to where I've already begun revamping older hardware like network storage units (NAS-1500/NAS-3000 from Galaxy Metal-Gear/OmniTec Corp.) and media players (I was looking into reworking a Lacie Mini-HD, but their support staff is a bit less than cooperative) to see what can be done on different processor platforms with TC (custom) at the helm.  It's a pet project, but thus far looks promising!

Thanks again, take care and I'll post back here with results when time permits.

[Juanito]

TC4 core64.gz, not pure.

That means ffmpeg is limited to 4gb ram, whereas with corepure ffmpeg would have access to 12gb ram if required.