Old moherboard RAM upgrade.

[Mitch Crane]

Fraid so, uncached system ram will ALWAYS be a
hell of a lot faster than virtual memory/the hard drive.

The only time that more than 64M would be worse than 64M
is when there is no use of virtual memory at all, and that wont
be the case in the OP's case and its just a virtual jukebox
anyway, so the speed will be invisible even if it does manage
to not use any virtual memory with 64M.

If it's just jukebox and speed isn't important then 64MB will be fine. If
speed is important then the apps may run slower if running in uncached
slow RAM (as will the OS if it is). If the PC would be used to multitask
and the apps running caused a lot of paging to disk then, sure, more slow
RAM would be better.

If I were using the system to run one not so memory hungry app in the
foreground all the time then I would stick with 64MB in this case. If
not, I'd get another board.

 

[Alex Fraser]

Unfortunately, the Windows OS loads at top of memory, this means that
frequent OS calls will go from cached to un-cached memory.

I assume by "top of memory" you mean "top of physical memory". I don't know
whether that is true or not, but I do know that under Win32, the OS is
mapped into the top of the virtual address space of each process. This fact
says nothing of where in physical memory the OS resides, but I think it
could easily have become twisted into what you state above.

In other words, it may be true, but there is reason to think it is just a
myth.

Alex

 

[johannes]

I assume by "top of memory" you mean "top of physical memory". I don't know
whether that is true or not, but I do know that under Win32, the OS is
mapped into the top of the virtual address space of each process. This fact
says nothing of where in physical memory the OS resides, but I think it
could easily have become twisted into what you state above.

In other words, it may be true, but there is reason to think it is just a
myth.

Alex

No it's not a myth. I have it from a leading PC expert. It's also quite
logical of an OS to load from the top, otherwise programs would need
detailed knowledge of last OS address, which would make it complicated
to load programs onto PCs running different versions of the OS.

 

[Rod Speed]

If it's just jukebox and speed isn't important then 64MB will be fine.

Nope, most obviously with the boot time and adding more files to the jukebox etc.

If speed is important then the apps may run slower if
running in uncached slow RAM (as will the OS if it is).

Yes, but we know he's running 2K and know that will use virtual memory/
the hard drive with 64M and that is a hell of a lot slower than that effect.

If the PC would be used to multitask and the apps running caused
a lot of paging to disk then, sure, more slow RAM would be better.

Not just a lot of paging, the paging you get with 2K and 64M too.

If I were using the system to run one not so memory hungry
app in the foreground all the time then I would stick with
64MB in this case. If not, I'd get another board.

That board with say 128M would be quite viable for a jukebox
running 2K and quite a bit cheaper than another board.

 

[Rod Speed]

Alex Fraser wrote

No it's not a myth. I have it from a leading PC expert.

Its also quite easy to test with a TX chipset motherboard and that has been done.

 

[Mitch Crane]

Nope, most obviously with the boot time and adding more files to the
jukebox etc.


Yes, but we know he's running 2K and know that will use virtual
memory/ the hard drive with 64M and that is a hell of a lot slower
than that effect.

Then the correct answer is, get a new board. If you need 128MB and Win2k
and your board is so ancient that it can only cache 64MB, get a new
board.

 

[Rod Speed]

Then the correct answer is, get a new board.

Nope, adding more ram to the current board will produce a very acceptible
performance with the current board and will be much cheaper.

If you need 128MB and Win2k and your board is so
ancient that it can only cache 64MB, get a new board.

Nope, adding more ram to the current board will produce a very acceptible
performance with the current board and will be much cheaper.

 

[Mitch Crane]

Nope, adding more ram to the current board will produce a very acceptible
performance with the current board and will be much cheaper.

It will be cheaper and very unsatifying.

 

[Rod Speed]

It will be cheaper and very unsatifying.

You dont know that. Bet it will be fine.

Basically because caching isnt that important for what he is doing.

What matters is eliminating the use of the virtual memory/hard drive.

 

[kony]

Nope, most obviously with the boot time and adding more files to the jukebox etc.

64MB is enough if background apps and services are minimized
(I mean, not running), even Win2k on GbE can exceed 40Mb/s
which is certainly fast enough for audio and then some.
Most significant is still the processor speed or if enough
memory being used as uncached, if that performance hit were
enough to combine with the marginal processing power of the
CPU to result in dips below necessary total system
performance needed for the playback.

Yes, but we know he's running 2K and know that will use virtual memory/
the hard drive with 64M and that is a hell of a lot slower than that effect.

For a single purpose system the amount of virtual memory
utilization will depend on the task. Win2k can boot to the
desktop using less than 50MB, and if 20MB of the OS were
swapped out, that's only a one-time event when the single
application use doesn't ever require paging that OS code
back into main memory. Certainly the ideal would be more
memory, but it's still do-able.

That board with say 128M would be quite viable for a jukebox
running 2K and quite a bit cheaper than another board.

Unless OP finds a very limited supply of SIMMs, he can just
buy 2 x 32MB and try it with 64MB total, buying a couple
more SIMMs if it seems necessary.

 

[kony]

No it's not a myth. I have it from a leading PC expert.

That doesn't make it true. Many so-called experts tend to
have a little less grasp of some things than they'd like to
believe.

It's also quite
logical of an OS to load from the top, otherwise programs would need
detailed knowledge of last OS address, which would make it complicated
to load programs onto PCs running different versions of the OS.

Memory mapping does not require top-down in real memory.
Remember this is a virtualized memory environment.

 

[Rod Speed]

64MB is enough if background apps and
services are minimized (I mean, not running),

You dont know that, you dont know how he changes the files in the jukebox.

even Win2k on GbE can exceed 40Mb/s which
is certainly fast enough for audio and then some.

I said that. The other ops like varying the files
may well see a useful improvement past 64M tho.

Most significant is still the processor speed or if enough
memory being used as uncached, if that performance hit
were enough to combine with the marginal processing
power of the CPU to result in dips below necessary
total system performance needed for the playback.

I wasnt talking about playback there. It can certainly do playback fine.

For a single purpose system the amount of
virtual memory utilization will depend on the task.
Duh.

Win2k can boot to the desktop using less than 50MB,
and if 20MB of the OS were swapped out, that's only
a one-time event when the single application use doesn't
ever require paging that OS code back into main memory.
Certainly the ideal would be more memory, but it's still do-able.

Never said it wasnt doable, I JUST said that adding
more memory past 64M would make it more usable
even if it isnt cached, particularly for the other ops like
manipulating the files, as opposed to just playing them etc.

Unless OP finds a very limited supply of SIMMs,
he can just buy 2 x 32MB and try it with 64MB total,
buying a couple more SIMMs if it seems necessary.

Duh. Thats what I said too.

 

[Mitch Crane]

Duh. Thats what I said too.

So the correct answer is, in fact, to get 64MB.

 

[kony]

You dont know that, you dont know how he changes the files in the jukebox.

I do know this. There is no app that needs to consume over
30MB to play audio. Some "could" be set to cache files in
memory to reduce continual # of HDD or network transfers,
but it's not necessity and most cannot even do this.

I said that. The other ops like varying the files
may well see a useful improvement past 64M tho.

In benchmarks, maybe. In the actual use, he'll have to test
it. He could buy 128MB and then remove half and retest, or
he could buy 64MB then buy more if it isn't a suitable
performance level.

I wasnt talking about playback there. It can certainly do playback fine.

What then?

Never said it wasnt doable, I JUST said that adding
more memory past 64M would make it more usable
even if it isnt cached, particularly for the other ops like
manipulating the files, as opposed to just playing them etc.

For editing, sure, but can we randomly assume these more
advanced things will be done? If so, we could as easily
assume random things would exceed 128MB or 256MB enough that
the platform itself is entirely unusable, while it is
probably fine IF that CPU has enough muscle to play the
audio realtime.

 

[johannes]

That doesn't make it true. Many so-called experts tend to
have a little less grasp of some things than they'd like to
believe.

This is not a 'so-called' expert, it's the from the best known author
in the field. But since you don't provide any evidence for your point,
I leave it to do your own research.

 

[Rod Speed]

So the correct answer is, in fact, to get 64MB.

There is no 'correct answer', it should be noticeably
faster with 128MB for the non playback ops.

 

[Rod Speed]

I do know this.
Nope.

There is no app that needs to consume over 30MB to play audio.

I WASNT TALKING ABOUT THE PLAYING OF THE AUDIO THERE.

I WAS TALKING ABOUT THE OTHER OPS, REDOING
WHAT FILES ARE THERE TO BE PLAYED ETC.

Some "could" be set to cache files in memory to reduce continual # of HDD

Doesnt happen in that use.

or network transfers, but it's not necessity and most cannot even do this.

In benchmarks, maybe. In the actual use, he'll have to test it.

Nope, the other ops OTHER THAN PLAYING AUDIO will be faster,

He could buy 128MB and then remove half
and retest, or he could buy 64MB then buy
more if it isn't a suitable performance level.

And 64M is so cheap that there isnt a lot of point obsessing about it.

What then?

Redoing what files are there to be played on the jukebox, stupid.

For editing, sure,

I wasnt talking about editing.

but can we randomly assume these more advanced things will be done?

We know that the system has to have audio files on it so they can be played.

No point in relying on the fairys at the bottom
of the garden to organise them on that system.

If so, we could as easily assume random things

No assumption what so ever that the files will have
to put on that system so they can be played etc, and
nothing random what so ever about that op either.

would exceed 128MB or 256MB enough
that the platform itself is entirely unusable,

Its entirely usable right now. He want more convenience, stupid.

while it is probably fine IF that CPU has
enough muscle to play the audio realtime.

I WASNT TALKING ABOUT THE PLAYING OF THE AUDIO THERE.

I WAS TALKING ABOUT THE OTHER OPS, REDOING
WHAT FILES ARE THERE TO BE PLAYED ETC.

 

[Mitch Crane]

There is no 'correct answer', it should be noticeably
faster with 128MB for the non playback ops.

Then one has to wonder why you suggested he get 64MB to start if 128MB
will be noticeably faster. Of course, you don't really know that it will
be noticeably faster, you're just guessing. He may find it slow with 64MB
and then buy another 64MB and find it not noticeably faster.

I'm sure you'll say now that you aren't just guessing, because you know
without question that it will be noticeably faster with the extra 64MB of
uncacheable RAM, which then raises the question as to why, considering
your infallible knowledge of how that old board will run, you don't
already know whether he should get 128MB or 64MB.

You seemed to know with certainty that 128MB was better before you
admitted that you had already suggested trying 64MB first. I guess you
just like to contradict people (including yourself). (There I go, stating
the obvious again.)

 

[Mitch Crane]

I WASNT TALKING ABOUT THE PLAYING OF THE AUDIO THERE.

I WAS TALKING ABOUT THE OTHER OPS, REDOING
WHAT FILES ARE THERE TO BE PLAYED ETC.

What, copying files to a directory? Opening a text file in notepad?

I WASNT TALKING ABOUT THE PLAYING OF THE AUDIO THERE.

I WAS TALKING ABOUT THE OTHER OPS, REDOING
WHAT FILES ARE THERE TO BE PLAYED ETC.

Those operations are trivial.

 

[Rod Speed]

Then one has to wonder why you suggested he get 64MB to start

I didnt.

if 128MB will be noticeably faster. Of course, you don't really
know that it will be noticeably faster, you're just guessing.

Wrong, as always. Read his original post.

He may find it slow with 64MB

That is what he has already got.

and then buy another 64MB and find it not noticeably faster.

I'm sure you'll say now that you aren't just guessing, because
you know without question that it will be noticeably faster with the
extra 64MB of uncacheable RAM, which then raises the question as to
why, considering your infallible knowledge of how that old board will
run, you don't already know whether he should get 128MB or 64MB.

HES GOT 64M NOW, cretin.

You seemed to know with certainty that 128MB was better before
you admitted that you had already suggested trying 64MB first.

You're lying now.

I guess you just like to contradict people (including yourself).
(There I go, stating the obvious again.)

Never ever could bullshit and lie its way out of a wet paper bag.