[ I'm yanking these from the archives, so they will not thread proper
with Message-ID. This is only temporary for e-mails I did not receive
from the list prior. ]
Chuck Hast (wchast@gmail.com) wrote:
> Not what I expected. The machine had 64m of ram, I increased it to
> 160m but now X is even SLOWER. Any idea of what I need to change?
What does: /sbin/lspci -v |grep -i bridge
Return?
Ronald KA4INM Youvan (ka4inm@tampabay.rr.com) wrote:
> I think your swap partition is suppose to grow if your RAM grows,
> go figure. Try a lot more RAM and see if it improves, I have
> 1 gig of RAM (purchased to allow an entire music CD be loaded
> into RAM and edited W/O using any swap disk space) I have no
> swap! I consider my X performance to be better than any Winblows
> I have seen. ???
Going without swap will force everything to stay in memory. Do note
that some early patchlevels of kernel 2.4 and 2.6 do have VM/Scheduler
bugs/issues that sometimes cause unpredictable results though.
> Other than swapping to disk, I never heard of the amount of memory
> effecting LINUX stuff's operating speed, I thought that was a
> proprietary property of Winblows.
Various VM/Scheduler approaches have caused issues, especially in early
patchlevles of kernel 2.4 and 2.6.
Eben King (eben1@tampabay.rr.com) wrote:
> Is it possible the firmware sensed the capabilities of the RAM, and
> the new RAM had lower speed (or whatever) than the old, so it brought
> everything down to its speed?
Not likely. The various latencies of read, row, column and other DRAM
cells can affect performance -- even resulting in supposedly "faster"
synchronous DRAM (SDRAM) memory actually reducing performance than
supposedly "slower" SDRAM that has better latency times -- but typically
this is minimal (10% or lower).
Eben King (eben1@tampabay.rr.com) wrote:
> There was some deal a while back where some BIOSes would only cache
> the first 64 MB of RAM, so if you went past that (a prodigous amount
> of RAM in those days IIRC), it would be uncached. Net effect, more RAM
> gets you a slower computer. Could that be the problem?
It's not the BIOS, but a combination of the "northbridge" chip, chipset
cache size and/or possibly any JTAG on the GTL (Pentium) interconnect.
The common issue was with the Intel i430 "Triton" series of chipsets.
The i430FX (I), i430VX (III) and i430TX (IV) had cache logic limited to
26-bit addressing (2^26 = 64MiB). What made the Tritons such an issue
is that the _entire_ L2 cache was _disabled_ if you passed the 64MB --
not just no caching for the memory above 64MB.
The i430HX (Triton II) did not have this limitation (and supported up to
512MiB RAM, all cached). Other chipsets from ViA and SiS had various
limitations ranging from 64MB to 512MB -- typically a factor of the
chipset, the L2 cache size and any JTAG circuitry. But these
limitations would just not cache above the limitation -- not disable the
entire cache circuitry altogether (like the Triton I/III/IV did).
Starting with the GTL+ (Pentium Pro) interconnect, the L2 logic and
cache were placed on the CPU package or die. Early Slot-1 Pentium II
"Klammath" processors (to 300MHz) actually had a 384MiB limitation, but
subsequent designs did not. All GTL+ (PPro-P3-Xeon), AGTL+
(P4-Xeon-"P5"), EV6 (Athlon32/Alpha264) and NUMA/HT (A64/Opteron) will
cache anything they can address.
<MEGA-TANGENT>
There _are_ memory paging and resulting performance issues with
GTL+/AGTL+ above 32-bit/4GiB when 36-bit/64GiB (this is known as PAE36
from a "programmer" standpoint) are used. At this time, only EV6 (A32
"hacked" long story) and NUMA/HT (A64/Opteron) offer a true 40-bit/1TiB
implementation (and is known as PAE52 from a "programmer" standpoint),
which means that are serious limitations with even Intel's 64-bit
extensions on its current AGTL+ platform (which was not designed for
beyond 32-bit/PAE36).
In a nutshell, if a program is using more than 512MiB or moving more
than 512MiB of memory mapped I/O around, then you do _not_ want to be
running Intel right now (not even EM64T 64-bit Intel "Prescott"
versions), but _only_ NUMA/HT c/o A64/Opteron. ;->
</TANGENT>
-- Bryan
P.S. Despite comments to the contrary or any that assigned unilateral
"blame," I just needed a "break" from the list for a few days. And from
what I saw, the list looked like it needed a "break" from me too. Don't
read anything into my absence.
-- Bryan J. Smith b.j.smith@ieee.org -------------------------------------------------------------------- Subtotal Cost of Ownership (SCO) for Windows being less than Linux Total Cost of Ownership (TCO) assumes experts for the former, costly retraining for the latter, omitted "software assurance" costs in compatible desktop OS/apps for the former, no free/legacy reuse for latter, and no basic security, patch or downtime comparison at all.----------------------------------------------------------------------- This list is provided as an unmoderated internet service by Networked Knowledge Systems (NKS). Views and opinions expressed in messages posted are those of the author and do not necessarily reflect the official policy or position of NKS or any of its employees.
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 17:24:09 EDT