Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.sys.mac.system > #58520 > unrolled thread
| Started by | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| First post | 2014-04-13 12:07 -0400 |
| Last post | 2014-04-19 16:37 +0000 |
| Articles | 20 on this page of 84 — 15 participants |
Back to article view | Back to comp.sys.mac.system
10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 12:07 -0400
Re: 10.9 - disabling memory compression billy@MIX.COM - 2014-04-13 17:57 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:35 -0400
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-13 14:50 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-13 21:18 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:55 -0400
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-13 15:37 -0400
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-13 15:51 -0400
Re: 10.9 - disabling memory compression Leonard Blaisdell <leoblaisdell@sbcglobal.net> - 2014-04-13 19:35 -0700
Re: 10.9 - disabling memory compression Your Name <YourName@YourISP.com> - 2014-04-14 16:34 +1200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-14 16:30 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 10:53 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-20 09:27 -0400
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-14 07:51 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-16 13:35 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-14 16:30 -0400
Re: 10.9 - disabling memory compression JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-04-14 17:36 -0400
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-14 18:06 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 09:15 +0200
Re: 10.9 - disabling memory compression me@home.spamsucks.ca (Király) - 2014-04-15 06:01 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-16 16:54 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 09:11 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-20 09:24 -0400
Re: 10.9 - disabling memory compression Jolly Roger <jollyroger@pobox.com> - 2014-04-15 02:10 +0000
Re: 10.9 - disabling memory compression Rick Jones <rick.jones2@hp.com> - 2014-04-14 23:32 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-14 19:58 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 09:45 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-20 09:26 -0400
Re: 10.9 - disabling memory compression Kevin McMurtrie <mcmurtrie@pixelmemory.us> - 2014-04-15 00:38 -0700
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-16 16:58 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-16 13:32 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-16 17:04 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-17 00:04 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 15:15 -0400
Re: 10.9 - disabling memory compression android <here@there.was> - 2014-04-17 21:29 +0200
Re: 10.9 - disabling memory compression android <here@there.was> - 2014-04-17 21:29 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 15:48 -0400
Re: 10.9 - disabling memory compression android <here@there.was> - 2014-04-17 21:58 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 16:07 -0400
Re: 10.9 - disabling memory compression billy@MIX.COM - 2014-04-19 16:06 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-19 12:37 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-19 17:27 +0000
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 08:33 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-20 09:13 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-18 05:55 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-18 10:00 -0400
Re: 10.9 - disabling memory compression JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-04-17 15:30 -0400
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 16:02 -0400
Re: 10.9 - disabling memory compression android <here@there.was> - 2014-04-17 22:10 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 16:33 -0400
Re: 10.9 - disabling memory compression Jolly Roger <jollyroger@pobox.com> - 2014-04-17 21:54 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-17 18:13 -0400
Re: 10.9 - disabling memory compression Jolly Roger <jollyroger@pobox.com> - 2014-04-17 23:59 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-18 17:59 -0400
Re: 10.9 - disabling memory compression Jolly Roger <jollyroger@pobox.com> - 2014-04-19 17:27 +0000
Re: 10.9 - disabling memory compression Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> - 2014-04-19 14:15 -0700
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-19 18:06 -0400
Re: 10.9 - disabling memory compression Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> - 2014-04-19 17:16 -0700
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-19 20:32 -0400
Re: 10.9 - disabling memory compression JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-04-19 21:40 -0400
Re: 10.9 - disabling memory compression Your Name <YourName@YourISP.com> - 2014-04-20 15:45 +1200
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-18 05:46 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-18 09:44 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-18 21:06 +0000
Re: 10.9 - disabling memory compression JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-04-18 17:21 -0400
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-18 17:30 -0400
Re: 10.9 - disabling memory compression nospam <nospam@nospam.invalid> - 2014-04-18 18:49 -0400
Re: 10.9 - disabling memory compression billy@MIX.COM - 2014-04-19 16:33 +0000
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 08:53 +0200
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-20 09:22 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-21 03:49 +0000
Re: 10.9 - disabling memory compression Alan Browne <alan.browne@FreelunchVideotron.ca> - 2014-04-18 17:24 -0400
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-18 17:25 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-19 03:09 +0000
Re: 10.9 - disabling memory compression billy@MIX.COM - 2014-04-19 15:21 +0000
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-19 16:01 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 10:47 +0200
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-21 03:52 +0000
Re: 10.9 - disabling memory compression JF Mezei <jfmezei.spamnot@vaxination.ca> - 2014-04-21 04:26 -0400
Re: 10.9 - disabling memory compression Lewis <g.kreme@gmail.com.dontsendmecopies> - 2014-04-22 04:07 +0000
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-22 08:15 -0400
Re: 10.9 - disabling memory compression Warren Oates <warren.oates@gmail.com> - 2014-04-21 08:44 -0400
Re: 10.9 - disabling memory compression Paul Sture <nospam@sture.ch> - 2014-04-20 10:42 +0200
Re: 10.9 - disabling memory compression billy@MIX.COM - 2014-04-19 16:37 +0000
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-19 12:37 -0400 |
| Message-ID | <YfadnQRfLtn5O8_OnZ2dnUVZ_rSdnZ2d@giganews.com> |
| In reply to | #58661 |
On 2014.04.19, 12:06 , billy@MIX.COM wrote:
> Alan Browne <alan.browne@freelunchvideotron.ca> writes:
>
>> it's noticeable as the compressed memory is now
>> disabled and therefore in the monitor shows as
>> zero compressed memory.
>
> On a machine with typically 4409MB used and 3783MB
> free, since this thread began I have yet to see any
> compressed memory.
On this machine (24 GB) there is compressed memory right out of the gate
on boot. Not much mind you (~100 MB). I suppose I could really load in
the apps and data and see if I could force the compression - maybe next
time I reboot.
I just looked on my SO's laptop (2 GB MBA) and she's at 1.98 GB used,
300 MB swap and 300 MP compressed...
I think I'll roll her back to Mountain Lion one of these days.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-04-19 17:27 +0000 |
| Message-ID | <slrnll5cga.1209.g.kreme@amelia.local> |
| In reply to | #58661 |
In message <liu6to$a6b$1@reader2.panix.com> billy@MIX.COM <billy@MIX.COM> wrote: > Alan Browne <alan.browne@freelunchvideotron.ca> writes: >> it's noticeable as the compressed memory is now >> disabled and therefore in the monitor shows as >> zero compressed memory. > On a machine with typically 4409MB used and 3783MB > free, since this thread began I have yet to see any > compressed memory. $ uptime 11:25 up 1 day, 19:09, 3 users, load averages: 1.72 2.12 2.41 <https://www.dropbox.com/s/zlon3riyg0qjk71/Screenshot%202014-04-19%2011.26.43.PNG> (I had to reboot yesterday to install drivers for the ix500). -- Today the road all runners come/Shoulder high we bring you home. And set you at your threshold down/Townsman of a stiller town.
[toc] | [prev] | [next] | [standalone]
| From | Paul Sture <nospam@sture.ch> |
|---|---|
| Date | 2014-04-20 08:33 +0200 |
| Message-ID | <6b6c2b-7ft2.ln1@news.chingola.ch> |
| In reply to | #58661 |
On 2014-04-19, billy@MIX.COM <billy@MIX.COM> wrote: > Alan Browne <alan.browne@freelunchvideotron.ca> writes: > >> it's noticeable as the compressed memory is now >> disabled and therefore in the monitor shows as >> zero compressed memory. > > On a machine with typically 4409MB used and 3783MB > free, since this thread began I have yet to see any > compressed memory. 16 GB RAM here, uptime 18.5 days. compressed memory currently sitting at 3.49 GB. It's running OS X Server with services I haven't used since boot, such as Wiki and Web servers. There's also VMware Fusion with a couple of Linux VMs, but I have stuff currently running in those at the moment. I did try closing all apps except for Terminal a day or two ago and compressed memory went down to 2.35 GB or so. Swap currently used is 1.21 GB. It would be interesting to have a means of seeing what is where because as I mentioned previously my VMs when left alone for long enough take some of prodding to give me adequate response times: the fastest way I have found so far is to suspend and resume the VMs or reboot them. I might be falling foul of energy saving options in the client VM systems here. P.S. I am currently chucking around files of up to 2 GB (some of those being edited in Amadeus Pro) so my file buffers are getting exercised. -- Paul Sture The final step of #heartbleed recovery is to call your mother, and advise her to change her maiden name -- @gojomo
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-20 09:13 -0400 |
| Message-ID | <gfqdnZ4U3b6QVc7OnZ2dnUVZ_rmdnZ2d@giganews.com> |
| In reply to | #58705 |
On 2014.04.20, 02:33 , Paul Sture wrote:
> On 2014-04-19, billy@MIX.COM <billy@MIX.COM> wrote:
>> Alan Browne <alan.browne@freelunchvideotron.ca> writes:
>>
>>> it's noticeable as the compressed memory is now
>>> disabled and therefore in the monitor shows as
>>> zero compressed memory.
>>
>> On a machine with typically 4409MB used and 3783MB
>> free, since this thread began I have yet to see any
>> compressed memory.
>
> 16 GB RAM here, uptime 18.5 days. compressed memory currently sitting
> at 3.49 GB.
>
> It's running OS X Server with services I haven't used since boot, such as
> Wiki and Web servers. There's also VMware Fusion with a couple of Linux
> VMs, but I have stuff currently running in those at the moment.
>
> I did try closing all apps except for Terminal a day or two ago and
> compressed memory went down to 2.35 GB or so. Swap currently used is
> 1.21 GB.
>
> It would be interesting to have a means of seeing what is where because as
> I mentioned previously my VMs when left alone for long enough take some
> of prodding to give me adequate response times: the fastest way I have
> found so far is to suspend and resume the VMs or reboot them. I might be
> falling foul of energy saving options in the client VM systems here.
Did you try turning off timer coalescing to see if your VM's would be
more responsive?
sudo sysctl -w kern.timer.coalescing_enabled=0
And/or AppNap for the VM's?
In Finder, applications, "Get Info" on the VM (Fusion or
whatever), and turn off AppNap in the GetInfo dialog.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Lewis <g.kreme@gmail.com.dontsendmecopies> |
|---|---|
| Date | 2014-04-18 05:55 +0000 |
| Message-ID | <slrnll1fhr.1v7.g.kreme@amelia.local> |
| In reply to | #58602 |
In message <braoc8Ft7gU1@mid.individual.net> android <here@there.was> wrote: > In article <lZednfcNMN_dtc3OnZ2dnUVZ_qCdnZ2d@giganews.com>, > Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >> And yes, there is a gain by turning it off. Compression, even as cpu >> efficient as the technique used, does use cpu cycles. > Have you noticed it? No, he hasn't. He's much like the audiodweeb, "See, now that I switched over to the $100/ft speaker wire, the sound is so much better!" *THAT* is ad hominem, btw. > Do you know what kind of compression it is? Is it > merely defraging the ram or is it reusing file fragments? John Siracusa: Like the HFS+ compression feature introduced in Snow Leopard, compressed memory trades relatively abundant CPU cycles for decreased disk I/O. The compression and decompression process is extremely fast, using the WKdm compression algorithm, and it will run in parallel, taking advantage of multiple CPU cores. Intuitively, a multi-core CPU grinding away compressing data in RAM does not seem like a winning strategy to save energy. But our intuition is often wrong when it comes to real-world energy use on modern hardware. Remember, it’s a race to sleep! Avoiding shuttling data between RAM and that hundreds-of-times-slower-than-RAM SSD is a big win as long as the compression task can be completed in a fraction of the time it would take to access the SSD. It can be, and it is. <http://arstechnica.com/apple/2013/10/os-x-10-9/17/> <<END In short, compressing memory is cheap (actually, much closer to out-right free), and it means the system is less likely to use the swap file. The more memory you have, the less likely you are to use the swapfile. Disabling it means that the system goes straight to the swapfile as soon as it wants to dump something out of RAM. Upshot, disabling compression will almost certainly cause the machine to be much slower under load. tl;dr version: don't do this. -- "There's sex and death and human grime in monochrome for one thin dime and at least the trains all run on time but they don't go anywhere."
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-18 10:00 -0400 |
| Message-ID | <F9qdnW3MJa1nsszOnZ2dnUVZ_vWdnZ2d@giganews.com> |
| In reply to | #58619 |
On 2014.04.18, 01:55 , Lewis wrote:
> In message <braoc8Ft7gU1@mid.individual.net>
> android <here@there.was> wrote:
>> In article <lZednfcNMN_dtc3OnZ2dnUVZ_qCdnZ2d@giganews.com>,
>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>
>>> And yes, there is a gain by turning it off. Compression, even as cpu
>>> efficient as the technique used, does use cpu cycles.
>
>> Have you noticed it?
>
> No, he hasn't.
Which I stated in my reply to him. It is subjectively not noticeable.
He's much like the audiodweeb, "See, now that I switched
> over to the $100/ft speaker wire, the sound is so much better!"
>
> *THAT* is ad hominem, btw.
Yes. And not unexpected from you. And a very poor analogy to boot.
Of course the difference is I'm not "adding" something for no
perceivable effect, I'm removing something that is not at all needed on
my system.
>> Do you know what kind of compression it is? Is it
>> merely defraging the ram or is it reusing file fragments?
>
> John Siracusa:
> Like the HFS+ compression feature introduced in Snow Leopard, compressed
> memory trades relatively abundant CPU cycles for decreased disk I/O. The
IOW: your assertion in the other post that it's not CPU based was wrong.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-04-17 15:30 -0400 |
| Message-ID | <53502bf1$0$33475$c3e8da3$9deca2c3@news.astraweb.com> |
| In reply to | #58600 |
On 14-04-17 15:15, Alan Browne wrote: > Without any firm reason to say so. Just because Apple added it (and > really, for laptops running on batteries - which is their largest > market), does not mean it is required. Were it bad then selecting the > mode as I did would have been disabled. It is interesting when you compare it to sleep mode. For a laptop, the sleep mode is different since by default it has the code to cause it to eventually write memory contents to disk when battery is too low and fully shutdown. By default, this is not enabled on desktops since it is not deemed to have any value (since they don't generally run on batteries) Apple could have done the same for the memory compression feature. On the other hand, a desktop with multiple cores and insufficient RAM might benefot from memory compression if it is performed by an otherwise idle core, since it wil reduce paging/swapping to disk.
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-17 16:02 -0400 |
| Message-ID | <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com> |
| In reply to | #58603 |
On 2014.04.17, 15:30 , JF Mezei wrote:
> On 14-04-17 15:15, Alan Browne wrote:
>
>> Without any firm reason to say so. Just because Apple added it (and
>> really, for laptops running on batteries - which is their largest
>> market), does not mean it is required. Were it bad then selecting the
>> mode as I did would have been disabled.
>
>
> It is interesting when you compare it to sleep mode. For a laptop, the
> sleep mode is different since by default it has the code to cause it to
> eventually write memory contents to disk when battery is too low and
> fully shutdown. By default, this is not enabled on desktops since it is
> not deemed to have any value (since they don't generally run on batteries)
>
> Apple could have done the same for the memory compression feature.
Except for the memory size issue^.
If they considered it at all, perhaps they believed there was more
complexity in having options for a) "desktop" machines with lots of
memory, b) desktops with modest memory and c) laptops.
Simpler to give everyone the same flavour.
Would be nice to have it as a reboot option - of course that's more code
to write and test.
> On the other hand, a desktop with multiple cores and insufficient RAM
> might benefot from memory compression if it is performed by an otherwise
> idle core, since it wil reduce paging/swapping to disk.
^As I pointed out in the OP, it's probably not appropriate to disable at
or below 8 GB - not to mention laptops.
I have 24 GB - more than ample for my iMac and my needs. Originally I
was going to add 8 GB for a 16 GB total. Lewis pointed out that I would
be better off to add 16 for a total of 24 as a long term plan. Made
great sense for less than $100 more.
Should my memory needs grow, I have an additional 8 GB of room that I
can grow this iMac - that day may never come - OTOH, I'll likely be
using this iMac through about 2020 unless silliness occurs. (I could
have wrung another year or so out of the other iMac - but the resale
value was still quite high...).
My next iMac may run on a slate of ARM processors...
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | android <here@there.was> |
|---|---|
| Date | 2014-04-17 22:10 +0200 |
| Message-ID | <braqplFprkU3@mid.individual.net> |
| In reply to | #58606 |
In article <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com>, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > I have 24 GB - more than ample for my iMac and my needs. Originally I > was going to add 8 GB for a 16 GB total. Lewis pointed out that I would > be better off to add 16 for a total of 24 as a long term plan. Made > great sense for less than $100 more. > > Should my memory needs grow, I have an additional 8 GB of room that I > can grow this iMac - that day may never come - OTOH, I'll likely be > using this iMac through about 2020 unless silliness occurs. (I could > have wrung another year or so out of the other iMac - but the resale > value was still quite high...). You can't have to much RAM... Max it out and make a RAM disk for your scratchy needs... ;-) -- teleportation kills http://tinyurl.com/androidphotography
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-17 16:33 -0400 |
| Message-ID | <58idnduyEu8Xp83OnZ2dnUVZ_jKdnZ2d@giganews.com> |
| In reply to | #58608 |
On 2014.04.17, 16:10 , android wrote:
> In article <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com>,
> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>
>> I have 24 GB - more than ample for my iMac and my needs. Originally I
>> was going to add 8 GB for a 16 GB total. Lewis pointed out that I would
>> be better off to add 16 for a total of 24 as a long term plan. Made
>> great sense for less than $100 more.
>>
>> Should my memory needs grow, I have an additional 8 GB of room that I
>> can grow this iMac - that day may never come - OTOH, I'll likely be
>> using this iMac through about 2020 unless silliness occurs. (I could
>> have wrung another year or so out of the other iMac - but the resale
>> value was still quite high...).
>
> You can't have to much RAM... Max it out and make a RAM disk for your
> scratchy needs... ;-)
I have a ram disk - allocates up to 10 GB. I use it for downloads so
container files can be zapped after the extraction is done to disk.
Downside (if any) is that it 'holds' that memory even if the files are
erased and trash emptied. So if I DL 2 GB, unpack the file and save it
to disk, then delete & empty the RAM disk, that 4 or 5 GB of memory
remains allocated to the RAM disk. If needed I can unmount/remount the
ramdisk but that's rare - I usually end up re-booting for some other
reason before that's needed.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-04-17 21:54 +0000 |
| Message-ID | <brb0seF2kksU1@mid.individual.net> |
| In reply to | #58609 |
On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.04.17, 16:10 , android wrote: >> In article <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com>, >> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >> >>> I have 24 GB - more than ample for my iMac and my needs. Originally I >>> was going to add 8 GB for a 16 GB total. Lewis pointed out that I would >>> be better off to add 16 for a total of 24 as a long term plan. Made >>> great sense for less than $100 more. >>> >>> Should my memory needs grow, I have an additional 8 GB of room that I >>> can grow this iMac - that day may never come - OTOH, I'll likely be >>> using this iMac through about 2020 unless silliness occurs. (I could >>> have wrung another year or so out of the other iMac - but the resale >>> value was still quite high...). >> >> You can't have to much RAM... Max it out and make a RAM disk for your >> scratchy needs... ;-) > > I have a ram disk - allocates up to 10 GB. I use it for downloads so > container files can be zapped after the extraction is done to disk. > > Downside (if any) is that it 'holds' that memory even if the files are > erased and trash emptied. So if I DL 2 GB, unpack the file and save it > to disk, then delete & empty the RAM disk, that 4 or 5 GB of memory > remains allocated to the RAM disk. If needed I can unmount/remount the > ramdisk but that's rare - I usually end up re-booting for some other > reason before that's needed. What do you use to create/destroy the RAM disk? -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-17 18:13 -0400 |
| Message-ID | <vPmdnRSCLN6_z83OnZ2dnUVZ_oGdnZ2d@giganews.com> |
| In reply to | #58610 |
On 2014.04.17, 17:54 , Jolly Roger wrote:
> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.04.17, 16:10 , android wrote:
>>> In article <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com>,
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>>
>>>> I have 24 GB - more than ample for my iMac and my needs. Originally I
>>>> was going to add 8 GB for a 16 GB total. Lewis pointed out that I would
>>>> be better off to add 16 for a total of 24 as a long term plan. Made
>>>> great sense for less than $100 more.
>>>>
>>>> Should my memory needs grow, I have an additional 8 GB of room that I
>>>> can grow this iMac - that day may never come - OTOH, I'll likely be
>>>> using this iMac through about 2020 unless silliness occurs. (I could
>>>> have wrung another year or so out of the other iMac - but the resale
>>>> value was still quite high...).
>>>
>>> You can't have to much RAM... Max it out and make a RAM disk for your
>>> scratchy needs... ;-)
>>
>> I have a ram disk - allocates up to 10 GB. I use it for downloads so
>> container files can be zapped after the extraction is done to disk.
>>
>> Downside (if any) is that it 'holds' that memory even if the files are
>> erased and trash emptied. So if I DL 2 GB, unpack the file and save it
>> to disk, then delete & empty the RAM disk, that 4 or 5 GB of memory
>> remains allocated to the RAM disk. If needed I can unmount/remount the
>> ramdisk but that's rare - I usually end up re-booting for some other
>> reason before that's needed.
>
> What do you use to create/destroy the RAM disk?
either an app called RamDisk (from "Un cadavre exquis"[1]) which
"protects" it - won't allow eject unless done via the app. But sometimes
it refuses to start correctly - (a couple times since Mavericks) - so
then I use a command line to set one up:
diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://20000000`
But that one can be ejected easily so you can lose the contents in a
jiffy if you're careless in the finder sidebar.
[1] Yes - that means what you think it means.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-04-17 23:59 +0000 |
| Message-ID | <brb87qF42q6U1@mid.individual.net> |
| In reply to | #58611 |
On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.04.17, 17:54 , Jolly Roger wrote: >> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >>> On 2014.04.17, 16:10 , android wrote: >>>> In article <IK2dnXxzA92prs3OnZ2dnUVZ_qmdnZ2d@giganews.com>, >>>> Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: >>>> >>>>> I have 24 GB - more than ample for my iMac and my needs. Originally I >>>>> was going to add 8 GB for a 16 GB total. Lewis pointed out that I would >>>>> be better off to add 16 for a total of 24 as a long term plan. Made >>>>> great sense for less than $100 more. >>>>> >>>>> Should my memory needs grow, I have an additional 8 GB of room that I >>>>> can grow this iMac - that day may never come - OTOH, I'll likely be >>>>> using this iMac through about 2020 unless silliness occurs. (I could >>>>> have wrung another year or so out of the other iMac - but the resale >>>>> value was still quite high...). >>>> >>>> You can't have to much RAM... Max it out and make a RAM disk for your >>>> scratchy needs... ;-) >>> >>> I have a ram disk - allocates up to 10 GB. I use it for downloads so >>> container files can be zapped after the extraction is done to disk. >>> >>> Downside (if any) is that it 'holds' that memory even if the files are >>> erased and trash emptied. So if I DL 2 GB, unpack the file and save it >>> to disk, then delete & empty the RAM disk, that 4 or 5 GB of memory >>> remains allocated to the RAM disk. If needed I can unmount/remount the >>> ramdisk but that's rare - I usually end up re-booting for some other >>> reason before that's needed. >> >> What do you use to create/destroy the RAM disk? > > either an app called RamDisk (from "Un cadavre exquis"[1]) which > "protects" it - won't allow eject unless done via the app. But sometimes > it refuses to start correctly - (a couple times since Mavericks) - so > then I use a command line to set one up: > > diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://20000000` > > But that one can be ejected easily so you can lose the contents in a > jiffy if you're careless in the finder sidebar. > > [1] Yes - that means what you think it means. Cool, thanks. I've created them in the past from the command line. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-18 17:59 -0400 |
| Message-ID | <CcWdnfhzNdnAPczOnZ2dnUVZ_qGdnZ2d@giganews.com> |
| In reply to | #58613 |
On 2014.04.17, 19:59 , Jolly Roger wrote:
> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> either an app called RamDisk (from "Un cadavre exquis"[1]) which
>> "protects" it - won't allow eject unless done via the app. But sometimes
>> it refuses to start correctly - (a couple times since Mavericks) - so
>> then I use a command line to set one up:
>>
>> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://20000000`
>>
>> But that one can be ejected easily so you can lose the contents in a
>> jiffy if you're careless in the finder sidebar.
>>
>> [1] Yes - that means what you think it means.
>
> Cool, thanks. I've created them in the past from the command line.
Oops - the app RamDisk does not protect from eject - but it does
immediately remount the drive with the same name if you do eject it.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Jolly Roger <jollyroger@pobox.com> |
|---|---|
| Date | 2014-04-19 17:27 +0000 |
| Message-ID | <brfpv4F1mt9U1@mid.individual.net> |
| In reply to | #58632 |
On 2014-04-18, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > On 2014.04.17, 19:59 , Jolly Roger wrote: >> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > >>> either an app called RamDisk (from "Un cadavre exquis"[1]) which >>> "protects" it - won't allow eject unless done via the app. But sometimes >>> it refuses to start correctly - (a couple times since Mavericks) - so >>> then I use a command line to set one up: >>> >>> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://20000000` >>> >>> But that one can be ejected easily so you can lose the contents in a >>> jiffy if you're careless in the finder sidebar. >>> >>> [1] Yes - that means what you think it means. >> >> Cool, thanks. I've created them in the past from the command line. > > Oops - the app RamDisk does not protect from eject - but it does > immediately remount the drive with the same name if you do eject it. Good to know. Thanks. -- E-mail sent to this address may be devoured by my ravenous SPAM filter. I often ignore posts from Google. Use a real news client instead. JR
[toc] | [prev] | [next] | [standalone]
| From | Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> |
|---|---|
| Date | 2014-04-19 14:15 -0700 |
| Message-ID | <myzjjh3ts1.fsf@Sunburn.Stanford.EDU> |
| In reply to | #58632 |
Alan Browne <alan.browne@FreelunchVideotron.ca> writes: > On 2014.04.17, 19:59 , Jolly Roger wrote: > > On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote: > > >> either an app called RamDisk (from "Un cadavre exquis"[1]) which > >> "protects" it - won't allow eject unless done via the app. But > >> sometimes it refuses to start correctly - (a couple times since > >> Mavericks) - so then I use a command line to set one up: > >> > >> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://200> 00000` > >> > >> But that one can be ejected easily so you can lose the contents > >> in a jiffy if you're careless in the finder sidebar. > >> > >> [1] Yes - that means what you think it means. > > > > Cool, thanks. I've created them in the past from the command line. > > Oops - the app RamDisk does not protect from eject - but it does > immediately remount the drive with the same name if you do eject it. With or without the data that was on the RAM disk before the eject??? Martin
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-19 18:06 -0400 |
| Message-ID | <3v2dnT1ZtJHubs_OnZ2dnUVZ_q6dnZ2d@giganews.com> |
| In reply to | #58680 |
On 2014.04.19, 17:15 , Martin Frost me at invalid stanford daht edu wrote:
> Alan Browne <alan.browne@FreelunchVideotron.ca> writes:
>
>> On 2014.04.17, 19:59 , Jolly Roger wrote:
>>> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>>
>>>> either an app called RamDisk (from "Un cadavre exquis"[1]) which
>>>> "protects" it - won't allow eject unless done via the app. But
>>>> sometimes it refuses to start correctly - (a couple times since
>>>> Mavericks) - so then I use a command line to set one up:
>>>>
>>>> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://200> 00000`
>>>>
>>>> But that one can be ejected easily so you can lose the contents
>>>> in a jiffy if you're careless in the finder sidebar.
>>>>
>>>> [1] Yes - that means what you think it means.
>>>
>>> Cool, thanks. I've created them in the past from the command line.
>>
>> Oops - the app RamDisk does not protect from eject - but it does
>> immediately remount the drive with the same name if you do eject it.
>
> With or without the data that was on the RAM disk before the eject???
Blown away.
If I get a RoundTUIT I'll write a program to sniff in memory to look for
files after such an eject.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | Martin Frost me at invalid stanford daht edu <nospam@stanford.edu.invalid> |
|---|---|
| Date | 2014-04-19 17:16 -0700 |
| Message-ID | <myeh0sx3bm.fsf@Sunburn.Stanford.EDU> |
| In reply to | #58682 |
Alan Browne <alan.browne@FreelunchVideotron.ca> writes: > On 2014.04.19, 17:15 , Martin Frost me at invalid stanford daht edu wrote= > : > > Alan Browne <alan.browne@FreelunchVideotron.ca> writes: > > > >> On 2014.04.17, 19:59 , Jolly Roger wrote: > >>> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:= > > >> > >>>> either an app called RamDisk (from "Un cadavre exquis"[1]) which > >>>> "protects" it - won't allow eject unless done via the app. But > >>>> sometimes it refuses to start correctly - (a couple times since > >>>> Mavericks) - so then I use a command line to set one up: > >>>> > >>>> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://2= > 00> 00000` > >>>> > >>>> But that one can be ejected easily so you can lose the contents > >>>> in a jiffy if you're careless in the finder sidebar. > >>>> > >>>> [1] Yes - that means what you think it means. > >>> > >>> Cool, thanks. I've created them in the past from the command line. > >> > >> Oops - the app RamDisk does not protect from eject - but it does > >> immediately remount the drive with the same name if you do eject it. > > > > With or without the data that was on the RAM disk before the eject??? > > Blown away. OK, that's what I would have expected. Your comment about immediately remounting it hinted that maybe that could save the data. So RamDisk makes an accidental ejecting look like a mysterious erasure. Not a whole lot of benefit in that. Martin
[toc] | [prev] | [next] | [standalone]
| From | Alan Browne <alan.browne@FreelunchVideotron.ca> |
|---|---|
| Date | 2014-04-19 20:32 -0400 |
| Message-ID | <UJ6dnQgwffoEiM7OnZ2dnUVZ_uKdnZ2d@giganews.com> |
| In reply to | #58689 |
On 2014.04.19, 20:16 , Martin Frost me at invalid stanford daht edu wrote:
> Alan Browne <alan.browne@FreelunchVideotron.ca> writes:
>
>> On 2014.04.19, 17:15 , Martin Frost me at invalid stanford daht edu wrote=
>> :
>>> Alan Browne <alan.browne@FreelunchVideotron.ca> writes:
>>>
>>>> On 2014.04.17, 19:59 , Jolly Roger wrote:
>>>>> On 2014-04-17, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:=
>>
>>>>
>>>>>> either an app called RamDisk (from "Un cadavre exquis"[1]) which
>>>>>> "protects" it - won't allow eject unless done via the app. But
>>>>>> sometimes it refuses to start correctly - (a couple times since
>>>>>> Mavericks) - so then I use a command line to set one up:
>>>>>>
>>>>>> diskutil erasevolume HFS+ 'RamDisk' `hdiutil attach -nomount ram://2=
>> 00> 00000`
>>>>>>
>>>>>> But that one can be ejected easily so you can lose the contents
>>>>>> in a jiffy if you're careless in the finder sidebar.
>>>>>>
>>>>>> [1] Yes - that means what you think it means.
>>>>>
>>>>> Cool, thanks. I've created them in the past from the command line.
>>>>
>>>> Oops - the app RamDisk does not protect from eject - but it does
>>>> immediately remount the drive with the same name if you do eject it.
>>>
>>> With or without the data that was on the RAM disk before the eject???
>>
>> Blown away.
>
> OK, that's what I would have expected. Your comment about immediately
> remounting it hinted that maybe that could save the data.
>
> So RamDisk makes an accidental ejecting look like a mysterious
> erasure. Not a whole lot of benefit in that.
The benefit of a ramdisk is as described earlier. I have accidentally
ejected the volume but well after I disposed of the data of interest as
needed (deleted or copied to other media).
I've yet (excuse me, need some wood to knock on) to lose data because of
an premature ejection. If that day should come, then the worst of the
damage will be to DL the file(s) again.
--
"Big data can reduce anything to a single number,
but you shouldn’t be fooled by the appearance of exactitude."
-Gary Marcus and Ernest Davis, NYT, 2014.04.07
[toc] | [prev] | [next] | [standalone]
| From | JF Mezei <jfmezei.spamnot@vaxination.ca> |
|---|---|
| Date | 2014-04-19 21:40 -0400 |
| Message-ID | <53532580$0$10660$c3e8da3$33881b6a@news.astraweb.com> |
| In reply to | #58691 |
On 14-04-19 20:32, Alan Browne wrote: > I've yet (excuse me, need some wood to knock on) to lose data because of > an premature ejection. If that day should come, then the worst of the > damage will be ... Your wife making fun of your premature ejection problem :-)
[toc] | [prev] | [next] | [standalone]
Page 3 of 5 — ← Prev page 1 2 [3] 4 5 Next page →
Back to top | Article view | comp.sys.mac.system
csiph-web