home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
PC World Komputer 1999 January
/
pcwk_01_1999.iso
/
Tajnepp
/
MCLK093
/
SETTINGS.TXT
< prev
next >
Wrap
Text File
|
1997-05-04
|
9KB
|
191 lines
12/30/96
settings.txt v0.92ß (beta-version)
------------------------------------------------
If you haven't done so already, please read MCLK.TXT.
Q: What's inside this text file?
Explanations of the rather cryptic options you may see, from my
program's output. MCLK doesn't have the most friendly
user-interface. I hope that users give some thought to what they
are doing with MCLK, before plugging in random values.
-------------------------------------------------
Q: Phrases like "VL-bus only" or "PCI only" accompany some settings.
What do they mean?
Some settings are only applicable to a particular bus architecture.
Settings designated "local-bus only" generally refer to VL-bus
(and NOT PCI)
Q: What is "RAS" and "CAS"?
RAS and CAS are related to memory access timing. Depending on
the context, RAS and CAS usually refer to the latencies involved
with the initial access to a memory bank. A lower CAS/RAS delay
translates into faster memory access operations. On the other
hand, the fastest RAm timing doesn't necessarily translate into
the best overall performance for a particular video board.
Larger (slower) CAS/RAS delays may permit higher DRAM-clock
frequencies, mitigating the performance penalty associated with
extended delay timing.
Changes to RAS/CAS timing aren't immediately perceptible (unless
the new value causes RAM accesses to fail.) Therefore changes to
these settings aren't likely to be noticeable. These settings
are best left alone.
Q: What about "RDY" or "LRDY", etc.?
RDY/LRDY relate to bus timing. Bus transactions, like memory
transactions, are governed by timed control signals.
Reducing the # waitstates on bus-transactions can improve your
raw video-write thruput. By how much depends on your video chipset,
your motherboard chipset, and the difference between the factory
default-timing and the most aggressive timing possible.
.........................
Q: What is the "MCLK"?
By naming my video-utility "MCLK", I've probably caused some
confusion. In this text, "MCLK" refers to two distinct things.
1) My program!
2) Video RAM-clock frequency ("MCLK" = Memory CLocK)
MCLK refers to your video card's "clock." The memory-clock
(not to be confused with the "dot clock") of your video board
controls the processing speed of your video chipset. The concept
of clock frequency ought to be familiar to you -- your CPU runs
at a fixed frequency (75MHz, 100MHz, 120MHz, 133MHz, etc.)
Host (CPU) accesses, BITBLT (accelerator) operations, and
screen update (CRT refresh) are all instances where your video
chipset performs some form of processing. Increasing the MCLK
frequency of a video board increases the available memory bandwidth.
It should come as no surprise that increasing the MCLK frequency
will boost video performance.
Some video operations are more bandwidth dependent than others.
DOS/VGA (games, text-character mode, non-GUI environments)
treat the video-card as a "dumb framebuffer." Direct reads &
writes to/from video memory are rarely accelerated. So in practice,
DOS/VGA performance is bottlenecked at the bus-interface, and not
by memory bandwidth. More bandwidth will not speed-up DOS thruput
if there is already sufficient bandwidth to service all host
transactions and screen-refresh.
GUI environments ( OS/2, Windows, etc.) are a different story.
Thanks to vendor device-drivers which utilize the video chipset's
accelerator circuitry, many host-requested graphics operation
can be offloaded to the accelerator. The accelerator's processing
speed is governed by the DRAM-clock (MCLK). Since graphics
operations within Windows applications are likely to be offloaded
to the video accelerator, increasing the MCLK will produce a
perceptible improvement in terms of screen response.
If you the Plus Pack for Windows 95, enable full-window drag and
switch your desktop resolution to the maximum resolution & color
depth possible. Try DECREASING your MCLK frequency -- you'll
see the effect.
Q: I didn't understand the preceding discussion. In layman's terms,
what is the benefit of increasing my SVGA adapter's "MCLK" ?
+Possible performance gains under DOS/VGA, and Windows
(Unless your video chipset has adjustable bus-transaction timings,
DOS/VGA performance won't be adjustable.)
Q: And the dangers?
Unreliable screen redraws, system-lockups, in extreme occasions
(such as pushing MCLK -> 80MHz...) possible VIDEO CARD DAMAGE.
"Incremental" testing can help diagnose. This means boosting your
MCLK a small bit at a time, verifying nominal computer operation each
step of the way. Certainly, don't change too many settings at once--
try to test one variable at a time.
As long as you avoid entering extreme/outrageous MCLK values, your
video card is in no danger. If your entered MCLK value exceeds the
video card's tolerances, the video card will exhibit very strange
behavior, long before any permanent damage.
Q: If I set MCLK too high, what kind of symptoms will I see?
System lock-ups. Partially corrupted displays ( screen doesn't refresh
properly, screen isn't redrawn properly ), video "noise" (random dots.)
While visually distracting, these symptoms aren't usually damaging to
the video card. But you should take them as a warning sign,
to lower the MCLK.
..........................................
Q: How can I measure the benefits, if any, afforded by MCLK?
You can always check the performance of your system with a good
benchmark program.
DOS PERFORMANCE
VIDSPEED4 and PROFILE (included with UNIVBE) are my
favorites (note, there are other benchmark programs out there.)
VIDSPEED benchmarks a video board's DOS/VGA (CPU-write) thruput.
Vidspeed performs its speed-test in banked memory-access mode.
PROFILE can test the framebuffer in linear-mapped mode. With the
rise of VESA 2.0 SVGA DOS games, PROFILE is the way to go. Visit
Scitechsoft's www-site (http://www.scitechsoft.com) for an
evaluation copy of Display Doctor. The SDD package includes
PROFILE.
WINDOWS PERFORMANCE
In some situations, you'll be able to eyeball the screen and
see the difference between a stock video-card and an tweaked-one.
But more often than not, you'll need a benchmark program like
Winbench96 to resolve the performance issue.
Q: What's the difference between all these timing modes --
"FPM, 2-cycle EDO, and 1-cycle EDO?"
EDO and FPM are two types of RAM. They are similar in access
protocol, with EDO allowing system-designers to shave off one
cycle from consecutive reads between page accesses. In plain
English, EDO RAM offers superior read performance over
conventional (FPM) RAM, but only when the read-operations are
arranged within the same memory block. EDO does not directly
improve random access reads, or write operations.
Block transfers, video FIFO fills (display drawing) benefit the
most from EDO timing. And coincidentally, graphics display
happens to be an application where block transfers (BITBLT) and
consecutive reads (screen refresh) predominate.
Now, if you switch a Trio64 from FPM timing to 2-cycle EDO,
you'll see no improvement. Why? Most video boards already use
2-cycle page-accesses, even for FPM memory banks. So at a given
MCLK frequency, 2-cycle EDO offers no improvement over FPM.
BUT...EDO timing's pipelined profile does offer one benefit, and
that's a higher clock frequency. Depending on the particular
design in question, an EDO based system can clock faster than a
FPM based system.
In terms of performance, 1-cycle EDO timing is roughly equal to
SDRAM or SGRAM. Obviously, there are differences, but suffice it to
say, 1-cycle EDO theoretically offers 2X the burst performance compared
to 2-cycle EDO timing.
For prolonged block transfers, 1-cycle EDO can actually approach
2X performance of 2-cycle EDO. In graphics display applications
where memory operations are large, consecutive, and few (as
opposed to small, random, and numerous), 1-cycle EDO delivers
a substantial performance boost over 2-cycle EDO, as tested by a
benchmark program like Winbench96.
For more information, please visit my www-page.
liaor@uci.edu
http://www.oac.uci.edu/~rliao