Tweaking Optimizing Windows.pdf - GEGeek

VLink 8X support
V-Link refers to VIA's proprietary interchip bus. Previously, VIA used the PCI bus for connecting the North Bridge and the South
Bridge. However, with high-speed PCI devices already saturating the PCI bus, VIA had to turn to an alternative bus for chipset's
interchip communication. So, they designed their own bus to link the North Bridge with the South Bridge of their chipsets. The
initial version used a quad-pumped 8-bit bus running at 66MHz to provide 266MB/s of interchip bandwidth. This gave them a
dedicated bus with twice the bandwidth of the PCI bus (which incidentally has to be shared with other PCI devices). The V-Link
debuted in the VIA Apollo KT266 chipset.
VIA has recently enhanced their V-Link technology to provide even more bandwidth for interchip communication. Starting with the
Apollo KT400 and P4X400 chipsets, the clock speed of the V-Link bus will be doubled to 133MHz. This doubles the bandwidth of the
V-Link bus to 533MB/s. Although the new bus is only four times faster than the PCI bus, VIA chose to call the new bus 8X V-Link.
The VLink 8X Support BIOS feature is used to toggle the doubling of the V-Link bus' clock speed. When enabled, the quad-pumped
8-bit V-Link bus will run at 133MHz, thereby delivering a bandwidth of 533MB/s. When disabled, the V-Link bus will use a clock
speed of 66MHz, essentially reverting to the original V-Link standard. This BIOS feature was most likely included for
troubleshooting purposes. It is recommended that you enable it for better performance.
SYSTEM RESOURCE MANAGEMENT
AGP anti-aliasing
The origin of this feature can be traced back all the way to the original IBM PC. When the IBM PC was designed, it only used ten
address lines (10-bits) for IO space allocation. Therefore, the IO space back in those days was only 1KB or 1024 bytes in size. It
was also maintained that the first 256 addresses would be exclusively reserved for the motherboard's use, leaving the last 768
addresses for use by add-in devices. This would become a critical factor later on.
Later, motherboards began to utilize 16 available address lines for IO space allocation. This was supposed to create a contiguous IO
space of 64KB in size. Unfortunately, many ISA devices by then would only do 10-bit decodes. As such, they fragmented the 64KB
IO space into 1KB chunks. To make things worse, the rule that the first 256 addresses is exclusively reserved for the motherboard
meant that the first (or lower) 256 bytes of each 1KB chunk would be decoded in full 16-bits. This automatically restricted the 10-
bits-decoding ISA devices to the last (or top) 768 bytes of the 1KB chunk of IO space.
Therefore, those ISA devices only had 768 IO locations to use. Because there are so many ISA devices in those days, this limitation
created a lot of compatibility problems because the chances of two ISA cards using the same IO space were high. When that
happened, one or both of the cards would not work. Although standardizing the IO locations used by various classes of ISA devices
ameliorated the situation, it was still not good enough.
A workaround was eventually designed in which the ISA device would first take up a smaller number of IO locations in the 10-bit
range. It would then extend its IO space by using 16-bit aliases of the few 10-bit IO locations that it allocated to itself. Because
each IO location in the 10-bit decode area have sixty-three16-bit aliases, the total number of IO locations expanded from just 768
locations to a maximum of 49,152 locations! More importantly, each ISA card will now require very few IO locations in the 10-bit
range. This drastically reduced the chances of two ISA cards conflicting each other in the limited 10-bit IO space. This workaround
became known as ISA Aliasing.
Now, that's all well and good for ISA devices. Unfortunately, the 10-bit limitation of ISA devices is a liability when there are devices
that require 16-bit addressing. AGP and PCI devices come to mind. As noted earlier, only the first 256 addresses of the 1KB chunks
support 16-bit addressing. As such, all 16-bit addressing devices are limited to only 256 bytes of contiguous IO space! When a16-
bit addressing device requires a larger contiguous IO space, it will be have to encroach on ISA IO space. If, for example, an AGP
card r equires 8KB of contiguous IO space, it will cover eight of the 1KB IO chunks. Because ISA devices are using ISA Aliasing
to extend their IO space, this brings about a high chance of IO space conflicts between ISA devices and the AGP card. Again, when
that happens, the affected cards may fail to work.
There are two ways out of this mess. First method would be to limit the AGP card to a maximum of 256 bytes of contiguous IO
space. The second, and naturally the preferred method, would be to throw away the restriction and provide the AGP card with all
the contiguous IO space it wants. Here's where the AGP ISA Aliasing BIOS feature comes in. The default setting of Enabled forces
the system controller to alias ISA addresses using address bits [15:10]. Only the first 10-bits (address bits 0 to 9) are used for
decoding. As mentioned above, this restricts all 16-bit addressing devices to a maximum contiguous IO space of 256 bytes.
When disabled, the system controller will not perform any ISA aliasing and all 16 address lines can be used for IO address space
decoding. This gives 16-bit addressing devices access to the full 64KB IO space.
It is recommended that you disable AGP ISA Aliasing for optimal AGP (and PCI) performance. Enable it only if you have ISA
devices that are conflicting with your AGP or PCI cards.
APIC function
The APIC Function BIOS feature is used to enable or disable the motherboard's APIC (Advanced Programmable Interrupt Controller).
The APIC is a new distributed set of devices that make up an interrupt controller. In current implementations, it consists of three
parts - a local APIC, an I/O APIC and an APIC bus. The local APIC delivers interrupts to a specific processor so each processor in a
system has to have its own local APIC. Therefore, a dual processor system must have two local APICs. Because a local APIC has
been integrated into every processor since the debut of the original Intel Pentium P54C processor, there's no need to worry about
the number of local APICs.
The I/O APIC is the replacement for the old chained 8259 PIC (Programmable Interrupt Controller) still in use in many
motherboards. It collects interrupt signals from I/O devices and send messages to the local APICs via the APIC bus which connects
it to the local APICs. There can be up to eight I/O APICs in a system, each supporting anywhere from 24 (usually) to 64 interrupt
lines. As you can see, this allows a lot more IRQs than is currently possible with the 8259 PIC. Note that without at least one I/O
APIC, the local APIC is useless and the system functions as if it's based on the 8259 PIC.