Memory, Speed, and SSDs in DAWs
Frank Stearns
recently moved to Protools 8.
I'm beginning to see some performance hits (1.4 Gbytes of pagefile use, for
example). The system works fine, it's just "sticky" (probably because of the paging)
which is annoying.
I have no problem adding more memory, but the motherboard manual informs me that
32-bit XP can't address more than 3 GBytes of RAM anyway and will ignore anything
more than 3.
I'm not inclined at this point to mess with a *very* stable OS installation by
changing the OS. (Oh, I'm sure XP-64 works great -- except for numerous
to-be-discovered gotchas. Don't really want to go there just yet.)
So I've been looking at SSDs for the system drive (or perhaps a dedicated page file
drive, as we used to do in the olden days for performance increases).
I've satisfied that the manufacturers (particularly Intel) have addressed the "wear"
problem with write cycles in SSDs, but have seen mixed reviews about speed
increases over a modern SATA II conventional HD.
Anybody been messing with SSDs for DAW use? Dramatic speed increases?
Thanks in advance for your thoughts,
Frank
Mobile Audio
--
.
Arny Krueger
message
news:vcmdne-D2pAsU5_W...@posted.palinacquisition
> I've got an Intel quad-core machine with 3 Gbytes of RAM
> running XP Pro, and recently moved to Protools 8.
>
> I'm beginning to see some performance hits (1.4 Gbytes of
> pagefile use, for example). The system works fine, it's
> just "sticky" (probably because of the paging) which is
> annoying.
What is the swapfile size? Figure that its max should be set at 1.5 to 2 x
the size of RAM.
> I have no problem adding more memory, but the motherboard
> manual informs me that 32-bit XP can't address more than
> 3 GBytes of RAM anyway and will ignore anything more than 3.
Pretty much the case. Some motherboards will let you go up to 3.5 GB with 4
GB installed.
> I'm not inclined at this point to mess with a *very*
> stable OS installation by changing the OS. (Oh, I'm sure
> XP-64 works great -- except for numerous to-be-discovered
> gotchas. Don't really want to go there just yet.)
The hot tip in 64 bit OSs is Windows 7.
> So I've been looking at SSDs for the system drive (or
> perhaps a dedicated page file drive, as we used to do in
> the olden days for performance increases).
If you want to get rid of the stickiness, make sure that the SWAP file is
not limiting you.
I've run various 32 bit audio and video programs under Windows 7/ in 64 bit
mode with 8 GB of RAM. Very smooth. Alleviates a number of bottlenecks.
Laurence Payne
<franks.pa...@pacifier.net> wrote:
>I've got an Intel quad-core machine with 3 Gbytes of RAM running XP Pro, and
>recently moved to Protools 8.
>
>I'm beginning to see some performance hits (1.4 Gbytes of pagefile use, for
>example). The system works fine, it's just "sticky" (probably because of the paging)
>which is annoying.
Where are you getting this figure of 1.4 GB from? Are you sure it's
referring to a swapfile on disk? You have control over the size of
this file. What happens if you set it to something smaller? What
happens if you set it to zero (oh yes you can, and most applications
will run perfectly well on a computer with sufficient RAM).
Peter Larsen
> I've got an Intel quad-core machine with 3 Gbytes of RAM running XP
> Pro, and recently moved to Protools 8.
Hmmm .... that should be able to haul plenty.
> I'm beginning to see some performance hits (1.4 Gbytes of pagefile
> use, for example). The system works fine, it's just "sticky"
> (probably because of the paging) which is annoying.
If you go by the task managers info, then it says "pagefile use" when it
means committed memory".
> I have no problem adding more memory, but the motherboard manual
> informs me that 32-bit XP can't address more than 3 GBytes of RAM
> anyway and will ignore anything more than 3.
That is correct. I'm right now taking a new daw in use, a second hand HP
ML115 with dual core opteron and same amount of ram. I'll probably rebuild
it later tonight, because I got the disk setup wrong. It came with 4 -
assumed server grade - disks configured in raid5, and I kinda like that, but
it is the mobo raid5 and at best I get 6 megabytes pr. second writes, I
think I'll take the gamble and split them into two simple stripe sets and
save to an external disk and protect the installation via imaging.
> I'm not inclined at this point to mess with a *very* stable OS
> installation by changing the OS. (Oh, I'm sure XP-64 works great --
> except for numerous to-be-discovered gotchas. Don't really want to go
> there just yet.)
Check driver availability, it's probably gonna be faster.
> So I've been looking at SSDs for the system drive (or perhaps a
> dedicated page file drive, as we used to do in the olden days for
> performance increases).
Disable pagefile and wait and see. You may not need to do anything else.
> I've satisfied that the manufacturers (particularly Intel) have
> addressed the "wear" problem with write cycles in SSDs, but have seen
> mixed reviews about speed increases over a modern SATA II
> conventional HD.
Frank, you need to tell us how you work with that box, is it for multitrack
work?
> Anybody been messing with SSDs for DAW use? Dramatic speed increases?
I have not followed this intensely, I think they still have a speed issue.
> Thanks in advance for your thoughts,
Simple system optimisation: have multiple sets of spindles so that you never
read and write to the same set of spindles, that gives you a relative speed
increase of about 4 times. If you need a pagefil, then distribute it over
all other sets of spindles than the one the OS is residing on. With 2
gigabyte ram or more: disable pagefile and only enable it if it gets
requsted. With 3 gigabytes of ram having one gets pointless if you run only
one application on a 32 bit box. Here is why: the application gets a 4
gigabyte address table to use, half of that is for chatting with the OS and
the other half is for the aspplication and its datacaches.
I tried a demo version of 64 bit server 2003 on that box, way faster than
XP, but I have an XP prof I bought for having on the shelf if I needed one,
and the server OS is darn costly. To really move to 64 bit computing you'd
also need a 64 bit version of the application. Interestingly Server2003 64
bit was completely happy with the midiman drivers for the duo that I'm gonna
use with that box ....
Such a server-box is not designed for use with a physical display ... its on
board graphics are rudimentary but its mobo design is designed for moving
data, and as I do a lot of my AA3 work in the edit window it seems to be an
attractive choice. The current version would be a ML110G5. It is great to be
able to open a remote application with a lot of hardware power from a petite
laptop and allows good listening conditions.
We do have this great pcdaw list on yahoo, hosted by Geoff.
> Frank
> Mobile Audio
Kind regards
Peter Larsen
Frank Stearns
>On Tue, 17 Nov 2009 10:26:25 -0600, Frank Stearns
><franks.pa...@pacifier.net> wrote:
>>I've got an Intel quad-core machine with 3 Gbytes of RAM running XP Pro, and
>>recently moved to Protools 8.
>>
>>I'm beginning to see some performance hits (1.4 Gbytes of pagefile use, for
>>example). The system works fine, it's just "sticky" (probably because of the paging)
>>which is annoying.
>Where are you getting this figure of 1.4 GB from? Are you sure it's
>referring to a swapfile on disk? You have control over the size of
Yes; "Page File Usage" and "Page File Usage History" monitors within XP.
>this file. What happens if you set it to something smaller? What
Probably don't want to do that, not if the system is claiming 1+ Gbytes are in use
when PT8 is loaded.
>happens if you set it to zero (oh yes you can, and most applications
>will run perfectly well on a computer with sufficient RAM).
Problem is, Windows often has stupid VM utilization, compared to other OS's VM use.
(Remember the bad old days of MS apps going out and simply grabbing 100 MB (or more)
of swap just by loading the program? No files even opened?)
And of course, you can run without VM -- if you have enough RAM, and the OS can
address that RAM. I don't fully trust windows to realize that it could run without
VM, however, and have always kept VM turned on.
This system has VM minimum set to 4 Gbytes and max to 12 Gbytes. I've done this to
somewhat minimize fragmentation of the swap file.
Hmm. I might just see about putting a large, fixed-size swap file on my backup data
drive, which never gets accessed during production, thus removing any VM access on
the system drive. Just like the good old days! Separate physical drive (not just a
partition) for the OS, drive for data and apps, and drive for swap.
Thanks,
Frank
--
.
Tobiah
> I've got an Intel quad-core machine with 3 Gbytes of RAM running XP Pro,
> and recently moved to Protools 8.
>
> I'm beginning to see some performance hits (1.4 Gbytes of pagefile use,
> for example). The system works fine, it's just "sticky" (probably
> because of the paging) which is annoying.
What are you doing that causes you to swap with 3Gig of ram?
You must be using an audio program that holds all sound data in
memory. You really think more memory is going to fix your problem?
Peter Larsen
> This system has VM minimum set to 4 Gbytes and max to 12 Gbytes. I've
> done this to somewhat minimize fragmentation of the swap file.
To minimize fragmenation - and to skip the os using cpu time wondering
whether to resize it - set it to a fixed size.
More that twice the size of physical ram is meaningless. For a single
application workstation with 3 GB ram, first try with pagefile set to zero,
next with pagefile fixed to 1 GB if application paranoid.
You're only really really likely to need a pagefile if you run a graphics
application concurrently with ptools. And if you need one, then the system
or the graphics application will tell you.
> Frank
Kind regards
Peter Larsen
mikea
If he's running something that is memory-starved, and if that's why he's
seeing stuff get written to the swapfile(s), then why wouldn't relieving
the memory starvation (a) remove the need to swap that stuff out, and
(b) thereby fix the problem?
It's the technique I've used with great success for years on large IBM
mainframe computers and on servers of various sizes from tiny through
humungous: swapping? Add RAM. Back before semiconductor RAM, I added
real, gen-you-wine ferrite toroid core memory, but that was a long, long
time ago. I've been fighting computers for a living since 1965.
I grant that removing the _NEED_ for all that storage may be A Good
Thing in its own right, but I don't know what all he has running in that
box besides Protools 8, and RAM is certainly faster than disc.
--
Mike Andrews, W5EGO
mi...@mikea.ath.cx
Tired old sysadmin
Arny Krueger
news:9mebt6-...@mikea.ath.cx
> It's the technique I've used with great success for years
> on large IBM mainframe computers and on servers of
> various sizes from tiny through humungous: swapping? Add
> RAM.
Computers with 32 bit addressing, whether mainframes or micros, exhaust that
option when you try to expand RAM above 4 GB unless some kind of
bank-switching scheme is in place.
Us old-timers remember when 4 GB (or even 16 MB!) used to be an
incomprehensibly large amount of RAM, but now it is less than $100 worth.
Peter Larsen
> If he's running something that is memory-starved, and if that's why
> he's seeing stuff get written to the swapfile(s), then why wouldn't
> relieving the memory starvation (a) remove the need to swap that
> stuff out, and (b) thereby fix the problem?
He isn't running something that is memory-starved, task manager is
misleading him because it says pagefile usage when it means ram usage. He is
using half is available physical ram and does not need a pagefile unless I
gravely misread him.
An application can not get more than 2 gigabytes memory-space, paged or not,
and xp32 is not going to need more than 1 gigabyte memoryspace, paged or
not, on this side of Ginnunagagap. All the pagefile does for him is to
create an extra thread of usage on is - assumed - single drive with os and
application and that is likely to be a brake on actual total system
performance.
Kind regards
Peter Larsen
Peter Larsen
> What are you doing that causes you to swap with 3Gig of ram?
> You must be using an audio program that holds all sound data in
> memory.
Application + data in ram + application specific cache (also just data in
ram for this context) can not exceed 2 gigabytes in xp32.
> You really think more memory is going to fix your problem?
Not unless he uses a 64 bit OS.
Kind regards
Peter Larsen
Tobiah
> If he's running something that is memory-starved, and if that's why he's
> seeing stuff get written to the swapfile(s), then why wouldn't relieving
> the memory starvation
Of course it would. I just doubt that he's really doing anything
related to audio that would actually swap over 3Gig.
Soundhaspriority
> I've got an Intel quad-core machine with 3 Gbytes of RAM running XP Pro,
> and
> recently moved to Protools 8.
>
> I'm beginning to see some performance hits (1.4 Gbytes of pagefile use,
> for
> example). The system works fine, it's just "sticky" (probably because of
> the paging)
> which is annoying.
>
> I have no problem adding more memory, but the motherboard manual informs
> me that
> 32-bit XP can't address more than 3 GBytes of RAM anyway and will ignore
> anything
> more than 3.
>
Throw some more RAM in the machine and let'her rip.
Bob Morein
(310) 237-6511
Peter Larsen
It is only when running multiple large applications it makes sense to enable
a pagefile with that much ram in the box, one application CAN NOT get more
than 2 gigabytes, paged or not, in xp32.
Kind regards
Peter Larsen
Laurence Payne
<franks.pa...@pacifier.net> wrote:
>Problem is, Windows often has stupid VM utilization, compared to other OS's VM use.
>(Remember the bad old days of MS apps going out and simply grabbing 100 MB (or more)
>of swap just by loading the program? No files even opened?)
>
>And of course, you can run without VM -- if you have enough RAM, and the OS can
>address that RAM. I don't fully trust windows to realize that it could run without
>VM, however, and have always kept VM turned on.
>
>This system has VM minimum set to 4 Gbytes and max to 12 Gbytes. I've done this to
>somewhat minimize fragmentation of the swap file.
You (and Windows, in its use of the word) are confusing Virtual Memory
with the actual swap file on disk.
Sean Conolly
news:4b032ff2$1$56782$edfa...@dtext02.news.tele.dk...
Application or process? Applications can spawn mulitiple processes, each
with it's own memory.
May not apply in the OP's circumstance, but it's worth noting.
Sean
Sean Conolly
news:vcmdne-D2pAsU5_W...@posted.palinacquisition...
> and
> recently moved to Protools 8.
>
> I'm beginning to see some performance hits (1.4 Gbytes of pagefile use,
> for
> example). The system works fine, it's just "sticky" (probably because of
> the paging)
> which is annoying.
Depending on the role of the server I prefer to disable swap entirely and
just add enough memory to support whatever the server is supposed to do. For
a DAW I'd expect you to run out of CPU before you run out of memory, even
with 3GB of RAM.
> I have no problem adding more memory, but the motherboard manual informs
> me that
> 32-bit XP can't address more than 3 GBytes of RAM anyway and will ignore
> anything
> more than 3.
On XP you should be able to use up to 4 GB, but you'll need to run at least
SP2 on it to use all of it.
http://msdn.microsoft.com/en-us/library/aa366778(VS.85).aspx
> I'm not inclined at this point to mess with a *very* stable OS
> installation by
> changing the OS. (Oh, I'm sure XP-64 works great -- except for numerous
> to-be-discovered gotchas. Don't really want to go there just yet.)
If it ain't broke - don't fix it :-) My fav for windows right now is Server
2003 - it's lean, fast and easy to manage. It can go up to 64 GB for the 32
bit version - not that I've tried it.
> So I've been looking at SSDs for the system drive (or perhaps a dedicated
> page file
> drive, as we used to do in the olden days for performance increases).
>
> I've satisfied that the manufacturers (particularly Intel) have addressed
> the "wear"
> problem with write cycles in SSDs, but have seen mixed reviews about speed
> increases over a modern SATA II conventional HD.
>
> Anybody been messing with SSDs for DAW use? Dramatic speed increases?
I haven't used these yet, but I've been researching them as part of some
storage upgrades I'm planing for my testbed (at my day job :-)
The big performace increase is when you are reading/writing lots of small
blocks of data scattered all over the disk. With a spinning hard disk you
have the time for the actuator to move to right cylinder on the platter, and
then wait for the platter to rotate to the right sector. This overhead
occurs every time the disk has to access data in a different area, and
typically averages in the 6 to 12 millisecond range. Obviously if the system
is accessing lots of little blocks and has to apply this overhead to every
request the I/O rate is going to be much, much slower than reading a set of
continuous blocks. This is why defragging the disk improves performance, by
reducing the seek time to get to the next block.
In an SSD there is no physical seek time - when accesing lots of small
blocks there's no differenence between accessing a nearby block or one at
the other end of the 'disk'. It is still a little faster to read continuous
blocks because of the way the memory works, but not nearly as much as with a
real hard disk.
I'm hoping to add one of these to my home workstation in the next couple of
weeks, and I'm planning on doing some tests to see where it helps the most.
Obviously putting the Windows boot partition on the SSD will improve the
boot and load times for the core apps. I'm also going to test it with a
couple of audio projects moved to the SSD. At some parts of my workflow I
spend up to a third of my time waiting on files to write, or read, or
waveform displays to update, etc. If I can cut that down it will be a big
help for me.
Sean
Frank Stearns
>On Tue, 17 Nov 2009 13:50:21 -0600, Frank Stearns
><franks.pa...@pacifier.net> wrote:
snips
>>This system has VM minimum set to 4 Gbytes and max to 12 Gbytes. I've done this to
>>somewhat minimize fragmentation of the swap file.
>You (and Windows, in its use of the word) are confusing Virtual Memory
>with the actual swap file on disk.
Er, how would you chose to draw the distinction?
Frank
--
.
Frank Stearns
Thanks to all who replied.
I solved the immediate problem ("sticky" UI in PT8) by placing the swap file on a
separate drive that is not in use during production (thanks to the responder who
mentioned separate "spindles", confirming what I was pondering).
So now there is a 500 Gbyte system/apps drive, a 1Tbyte data drive, and an otherwise
idle 1Tbyte backup drive that now hosts the swap file.
It seems that the root of the issue in this specific case is how PT8 now handles
waveform representations (moved from 8 to 16 bit, as I understand it), and this is
an impact here because our PT sessions tend to have 100-200 minutes of waveforms
represented in them (classical performances and classical sessions, where it's
generally easier management having all the material in a single PT session).
The idea of running without swap is interesting; not sure I entirely trust XP to
handle that, even if theoretically it should.
Also, I do occasionally open other apps; it'd be something of a pain to shut down PT
to safely do that.
The RAM disk suggestion (Bob?) is interesting; will be taking a look at that as
well.
Arny Krueger
Windows virtual memory can significantly exceed the size of the swap file.
Example: memory mapped file(s).
The swap file needs to be large enough to store all virtual memory. Since
multiple address spaces (up to 2 or 3 GB each) may be in use, the sum of all
space used by all active address spaces can be very large.
Laurence Payne
<franks.pa...@pacifier.net> wrote:
>>You (and Windows, in its use of the word) are confusing Virtual Memory
>>with the actual swap file on disk.
>
>Er, how would you chose to draw the distinction?
Set the swap file size to a small value (or zero) in System
Properties/Advanced. Then see what numbers are shown in Task
Manager.
Soundhaspriority
"Frank Stearns" <franks.pa...@pacifier.net> wrote in message
news:usCdnViOQNqJzZnW...@posted.palinacquisition...
Frank,
The RAM disk is fastest of all, because the data is moved by DMA (direct
memory access) from one area to another. This is far faster than a solid
state disk, which must pass through the serial SATA interface.
Bob Morein
(310) 237-6511
Peter Larsen
Thank you, that is shat I have tried to convey, his total memory allocation
on a box with 3 Gigabytes ram is 1.6 gigabytes. I have seen this laptop with
2 gigs of ram ask for "more pagefile" once, but that was when opening
multiple raw images simultanously and it didn't crash, it just whined a bit.
Which is to say that I stand by my suggestion to Frank of trying it, the
likely worst case is a requester and an application halt, and checking
whether it is an actual problem.
Some years ago, back in win98 days, I was in a somewhat similar discussion,
I wanted to reduce the size of the vcache in win98 so as to be able to
reliably burn CD's - I found out later that the actual problem was a flatbed
scasnner daemon running in realtime priority looking for a scanner that was
turned off, but reducing the systems administrative chores was a usable
remedy.
The folks over at microsoft.* were very worried about restricting the size
of the vcache, and warned about all kinds of imaginary issues. However the
worst that could happen was that the box crashed and would need a reinstall
of the OS to reset normal values, and it was a new box, and I couldn't catch
on to being worried about how the OS ran, I wanted the application
CD-burning to run.
Finally I benchmarked transfer of a 600 megabyte file from drive to drive
with a stopwatch with different fixed Vcache sizes and documented that too
large a Vcache slowed things down, ie. transfer was faster with 48 megs
cache than with 64 megs cache. Only then did they give in and say that "yes,
with large amounts of ram it can be a problem that Vcache grows too large
during a tranfer of a very large file, but operatios on large files were
very unusual - or words to that effect. In the end I set miminum vcache to
48 megs and max to 96 megs, later I just locked it at 48 megs, for some
reason 24 megs and 48 megs were faster than values in between.
I wonder if that network file transfer I'm waiting for is done now ....
There are better performance benchmarking tools in windows than the task
manager btw. - it can be elucidating to check actual pagefile usages there
.... or to set it to automatic, that's what I do on unattended boxes or
where a restart is not permissible and where there is no-one to click "ok"
to the requester about the system increasig the pagefile. Kinda funny to see
that one in front of the railway timetable and announcements, especially
when it is for several days .... O;-)
I have also used the time required to test a new box, if it is my own box I
tend to install as I think will be bright, give it a test run and perhaps
try a different configuration based on how it is in initial use. It is in my
opinion required to know in advance how a system behaves under heavy
workload.
Kind regards
Peter Larsen
Laurence Payne
<dig...@hotmail.com> wrote:
>Finally I benchmarked transfer of a 600 megabyte file from drive to drive
>with a stopwatch with different fixed Vcache sizes and documented that too
>large a Vcache slowed things down, ie. transfer was faster with 48 megs
>cache than with 64 megs cache. Only then did they give in and say that "yes,
>with large amounts of ram it can be a problem that Vcache grows too large
>during a tranfer of a very large file, but operatios on large files were
>very unusual - or words to that effect. In the end I set miminum vcache to
>48 megs and max to 96 megs, later I just locked it at 48 megs, for some
>reason 24 megs and 48 megs were faster than values in between.
Are you taking credit for discovering the vcache bug in W98? The
algorithm that set its size was faulty, and with large amounts of RAM
installed it could get far too big. There was an easy fix.
Mr Soul
> recently moved to Protools 8.
>
> I'm beginning to see some performance hits (1.4 Gbytes of pagefile use, for
> example). The system works fine, it's just "sticky" (probably because of the paging)
> which is annoying.
>
> I have no problem adding more memory, but the motherboard manual informs me that
> 32-bit XP can't address more than 3 GBytes of RAM anyway and will ignore anything
> more than 3.
>
> I'm not inclined at this point to mess with a *very* stable OS installation by
> changing the OS. (Oh, I'm sure XP-64 works great -- except for numerous
> to-be-discovered gotchas. Don't really want to go there just yet.)
your RAM and is paging? You could try a SSD for the drive with the
pagefile but you are not really solving the problem, you are just
trying to making the page swaps faster.
I used XP-64 at work (no audio) and have had very good luck with it.
Does your DAW program support 64-bit? Is your DAW program multi-
threaded? If so, then I would really consider going to a 64-bit OS
and get more memory. You could go to XP-64 but MS is going to stop
supporting that in the future and you are just delaying when you will
have to switch. My recommendation is to: 1) short-term: try the SSD
for your pagefile or put your pagefile on a faster SATA3 disk, and 2)
long-term: switching to W7-64.
Peter Larsen
> On Thu, 19 Nov 2009 09:47:15 +0100, "Peter Larsen"
> <dig...@hotmail.com> wrote:
>> Finally I benchmarked transfer of a 600 megabyte file from drive to
>> drive with a stopwatch with different fixed Vcache sizes and
>> documented that too large a Vcache slowed things down, ie. transfer
>> was faster with 48 megs cache than with 64 megs cache. Only then did
>> they give in and say that "yes, with large amounts of ram it can be
>> a problem that Vcache grows too large during a tranfer of a very
>> large file, but operatios on large files were very unusual - or
>> words to that effect. In the end I set miminum vcache to 48 megs and
>> max to 96 megs, later I just locked it at 48 megs, for some reason
>> 24 megs and 48 megs were faster than values in between.
> Are you taking credit for discovering the vcache bug in W98?
No or yes, I didn't know it was a "bug", I just had a brand new Pentium2 300
megahertz with 192 megs of ram that couldn't burn CD's.
Kind regards
Peter Larsen
Peter Larsen
>> I've got an Intel quad-core machine with 3 Gbytes of RAM running XP
>> Pro, and recently moved to Protools 8.
>>
>> I'm beginning to see some performance hits (1.4 Gbytes of pagefile
>> use, for example). The system works fine, it's just "sticky"
>> (probably because of the paging) which is annoying.
>>
>> I have no problem adding more memory, but the motherboard manual
>> informs me that 32-bit XP can't address more than 3 GBytes of RAM
>> anyway and will ignore anything more than 3.
>>
>> I'm not inclined at this point to mess with a *very* stable OS
>> installation by changing the OS. (Oh, I'm sure XP-64 works great --
>> except for numerous to-be-discovered gotchas. Don't really want to
>> go there just yet.)
> So I gather that you have verified that your project has used up all
> your RAM and is paging? You could try a SSD for the drive with the
As I understood this it isn't and he has 1.4 gigabytes of ram unused or used
as system cache.
Kind regards
Peter Larsen
Mr Soul
> as system cache.
There is a registry setting to causes the OS itself to always remain
in memory (don't remember what it is) but I always set that, so that
could be the cause or it could be something else.
Mike
Laurence Payne
wrote:
>So I gather that you have verified that your project has used up all
>your RAM and is paging?
I'm not sure he has. But I've suggested an easy, quick way to check.
Peter Larsen
>> As I understood this it isn't and he has 1.4 gigabytes of ram unused
>> or used as system cache.
> OK then he needs to figure out what is causing the page swapping.
OS dumping dll-files to pagefile and then reloading them comes to mind as a
first guess.
> There is a registry setting to causes the OS itself to always remain
> in memory (don't remember what it is)
There was something about that, yes, didn't worry for years.
> but I always set that, so that
> could be the cause or it could be something else.
> Mike
Kind regards
Peter Larsen
Arny Krueger
> Mr Soul wrote:
>
>>> As I understood this it isn't and he has 1.4 gigabytes
>>> of ram unused or used as system cache.
>> OK then he needs to figure out what is causing the page
>> swapping.
Reading the OP, he considers the fact that 1.4 GB of the swap file are in
use as a problem.
In my book, that's just a statistic.
A problem is where there are significant hang-ups while running important
applications in sensible way. He does mention the system being "sticky",
but that is very indistinct. It could be a hardware problem like a
badly-fragged hard drive or even a hard drive that is stepping out the door.
I often observe systems that run like crap, sticky and all, and simply
replacing a $80 hard drive works wonders. If you have a hard drive that is
questionable, run a CHKFDK full scan. If that temporarily alleviates or
improves the situation, you probably have a hard drive that is slowly
walking out the door. They seem to like to do that these days - get slow and
sticky without coming right out and failing dead hard stopped.
> OS dumping dll-files to pagefile and then reloading them
> comes to mind as a first guess.
OSs are generally written better than that. I note that there are also
applications running. Perchance the application is not well-written?
>> There is a registry setting to causes the OS itself to
>> always remain in memory (don't remember what it is)
That sounds like a step in the wrong direction.
One of the benefits of dynamic paging is that lesser-used or unused code and
data gets swapped out to disk where the space it takes is virtually
unlimited and costs very little. Elmininating the swap file destroys that
option.
Dominique
news:vcmdne-D2pAsU5_W...@posted.palinacquisition:
> I've got an Intel quad-core machine with 3 Gbytes of RAM running XP
> Pro, and recently moved to Protools 8.
>
<snip>
>
> I'm not inclined at this point to mess with a *very* stable OS
> installation by changing the OS. (Oh, I'm sure XP-64 works great --
> except for numerous to-be-discovered gotchas. Don't really want to go
> there just yet.)
>
<snip>
> Frank
> Mobile Audio
>
"XP-64 works great", don't even think about it, many hardware
manufacturers don't even support it.
You have a Core2Quad, if you want to go 64bits use Windows7, most 64bits
Vista drivers work with it if there's not "Seven" drivers yet.
I have a Core2Quad that I upgraded to 8 gb of RAM and installed Win7 Home
Premium 64 bits and it's lightning fast.
The only driver I didn't found was for my M-Audio Midisport 4x4 USB MIDI
interface so I recycled it to my laptop (Win7 - 32bits with XP/Vista
drivers) and got a Cakewalk (Edirol) 3 ports USB MIDI interface for the
Core2Quad and everything works great.
H...@ao1.com
>example). The system works fine, it's just "sticky" (probably because of the paging)
>which is annoying.
I use a large single-allocation pagefile (in xp).
The sysinternals team at MS have many many useful utilities.
"contig" will show how many segments make a file.
"pagedfrg" will defrag a pagefile
(google "pagedfrg" site:microsoft.com)
1- set pagefile to zero.
2- defrag the disk.
3- allocate a large fixed-size pagefile.
4- contig the pagefile if needed (probably is needed).
- - - - -
To analyze (or recover) a HD, you can't beat "spinrite" at grc.com.
Arny Krueger
news:a2ac81fb-6f40-4b5c...@1g2000vbm.googlegroups.com
> I used XP-64 at work (no audio) and have had very good
> luck with it. Does your DAW program support 64-bit? Is
> your DAW program multi- threaded? If so, then I would
> really consider going to a 64-bit OS and get more memory.
> You could go to XP-64 but MS is going to stop supporting
> that in the future and you are just delaying when you
> will have to switch. My recommendation is to: 1)
> short-term: try the SSD for your pagefile or put your
> pagefile on a faster SATA3 disk, and 2) long-term:
> switching to W7-64.
XP64 may work under some conditions, but if you want a really nice
implementation of 64 bits, try Windows 7.
Frank Stearns
>>I'm beginning to see some performance hits (1.4 Gbytes of pagefile use, for
>>example). The system works fine, it's just "sticky" (probably because of the paging)
>>which is annoying.
>I use a large single-allocation pagefile (in xp).
>The sysinternals team at MS have many many useful utilities.
>"contig" will show how many segments make a file.
>"pagedfrg" will defrag a pagefile
>(google "pagedfrg" site:microsoft.com)
>1- set pagefile to zero.
>2- defrag the disk.
>3- allocate a large fixed-size pagefile.
>4- contig the pagefile if needed (probably is needed).
Excellent ideas; I will use them on my other systems. I always had started with
fairly large swap files, fixed size, to stop fragmentation.
I seemed to solve the original problem (and actually improve overall system
performance from what it'd been prior to install PT8) by moving the swap file to a
3rd internal drive (backup drive, used only when backing up).
What goes around comes around; IIRC having a separate drive for app/os, data, & swap
was the trick with older drive technology. Seems that apps and OS massiveness easily
caught up to drive performance.
>To analyze (or recover) a HD, you can't beat "spinrite" at grc.com.
Yep. We have it here in house.
Thanks again,