On Thu, Jul 25, 2013 at 4:35 AM, Gaetan Bisson wrote:

[2013-07-24 21:27:11 -0600] Chris Moline:

...

I installed anything-sync-daemon but I have no idea what to sync.

General question: isn't the effect of that software exactly the same thing as increasing the vm.dirty_expire_centiseconds kernel parameter?

Except maybe in the case of a given application calling sync() all the time, but then it usually has a good reason to do so (such as the written data being too important to be in cache during a power cut).

-- Gaetan

Yeah, it shouldn't increase performance except where it's causing possible data loss by ignoring `fsync`/`fdatasync`. There's no need to "guess and benchmark" because the kernel is already managing this for you.

On Wed, 24 Jul 2013 21:27:11 -0600 Chris Moline wrote:

Hi, I have 7 GiB of ram but I'm only using 300 MiB, so I thought I would put stuff into it to speed up my system.

A great way to utilize RAM is to run several VMs :) Also I wonder what is your chipset/RAM type, because on a typical desktop board with modern CPU and RAM modules, your memory size should be even for the optimal (dual-channel) performance. Or is your video memory shared?

I installed anything-sync-daemon but I have no idea what to sync. Is there a tool that can tell which dirs are being used the most? I'd rather not guess and benchmark, I don't have the patience for that. What are common dirs that would benefit from being in ram?

It all depends on your usage pattern. One procedure which really benefits from being done in RAM is building packages, especially large ones like gcc, glibc or qemu. In some circumstances, you'd want to store systemd journal and/or part of syslog log files in RAM. For example, HostAP (wireless authentication) daemon can log a lot. As a result, the journal grows dozens of MiB a day which quickly makes reading it off the disk rather painful. Since the journal cannot be fine tuned, I usually configure it to be volatile, and also tell syslog to write hostapd-related messages to e.g. /tmp/log/hostapd.log. For a regular desktop, people put in RAM ~/.mozilla, ~/.local/chromium (or whatever Chrome uses these days), etc. However, in my experience the resulting speedup is next to none and not worth the risk of data loss in case of a power failure or a system freeze... The truth is that on desktop machine which does not do virtualization, you don't need more than 2GiB or RAM. Remember, memory modules do consume power so it may be sensible to remove most of them. Cheers, -- Leonid Isaev GnuPG key: 0x164B5A6D Fingerprint: C0DF 20D0 C075 C3F1 E1BE 775A A7AE F6CB 164B 5A6D

Daniel Micay wrote:

There's no need to "guess andbenchmark" because the kernel is already managing this for you.

A great way to utilize RAM is to run several VMs :) Also I wonder what is your chipset/RAM type, because on a typical desktop board with modern CPU and RAM modules, your memory size should be even for the optimal (dual-channel) performance. Or is your video memory shared?

AMD A6-5400K APU DIMM DDR3 Synchronous, 2x8Gs I didn't see an option in my bios for shared memory so im assuming it's not, or that I'm blind

It all depends on your usage pattern.

I've installed a system monitor and I've found that the only time my disk io is high is when i'm running deluged. Would my torrents dir be a good candidate for tmpfs? It's rather larger than my torrents dir but is it possible to have the most intensive torrents put into it? Or is this unneccesary?

One procedure which really benefits from being done in RAM is building packages, especially large ones like gcc, glibc or qemu.

In some circumstances, you'd want to store systemd journal and/or part of syslog log files in RAM. For example, HostAP (wireless authentication) daemon can log a lot. As a result, the journal grows dozens of MiB a day which quickly makes reading it off the disk rather painful. Since the journal cannot be fine tuned, I usually configure it to be volatile, and also tell syslog to write hostapd-related messages to e.g. /tmp/log/hostapd.log.

I've put in ~/src/<specific-dirs> but logging doesn't apply to me.

For a regular desktop, people put in RAM ~/.mozilla, ~/.local/chromium (or whatever Chrome uses these days), etc. However, in my experience the resulting speedup is next to none and not worth the risk of data loss in case of a power failure or a system freeze...

I've installed profile-sync-daemon. I haven't noticed any improvement yet but I will keep using it for a month or so

The truth is that on desktop machine which does not do virtualization, you don't need more than 2GiB or RAM. Remember, memory modules do consume power so it may be sensible to remove most of them.

Interesting, I've always thought the more ram the better :P Thanks for your input guys.

[2013-07-25 12:28:59 -0600] Chris Moline:

very slow network connection when I'm running deluged

Look up "qos" (quality of service): Linux can be configured to prioritize sending small packets over larger ones. Small packets correspond almost exclusively to interactive connections... -- Gaetan

On Fri, Jul 26, 2013 at 8:35 AM, Daniel Micay wrote:

On Thu, Jul 25, 2013 at 5:39 PM, Gaetan Bisson wrote:

...

[2013-07-25 12:28:59 -0600] Chris Moline:

...

very slow network connection when I'm running deluged

Look up "qos" (quality of service): Linux can be configured to prioritize sending small packets over larger ones. Small packets correspond almost exclusively to interactive connections...

-- Gaetan

I have transmission set to use `tcp_lp` as `peer-congestion-algorithm` in the configuration file and it works quite well.

Deluged doesn't seem to have a similar option. But I'm going with Gaetan's suggestion to use traffic shaping. It's a bit of reading since I haven't done much with iptables and tc but I will get there.