According to 3DMark 99, when mipmapping support is disabled, the AGP bus with SBA is the fastest AGP configuration. With mipmapping support enabled however, the AGP bus with SBA dropped to the bottom and the overclocked AGP bus took the top stop. In any case, the AGP bus with SBA proved to be much faster than other two AGP configurations when the texture size grew too big for the onboard memory. Why?

Well, in the texture tests, 3DMark 99 generates as many 256x256 textures as needed for each test. That means when the texture size increases, so does the number of textures and consequently, the number of AGP requests needed. And when AGP memory is used, the number of AGP transactions increases further because there will be a lot of read and writes to and from the graphics controller.

When that happens, the SBA reduces congestion on the main AD lines and allows data transfer there to continue flowing irregardless of how many AGP requests have been issued. Even though the overclocked AGP bus has a higher overall AGP bandwidth, the AD lines are easily clogged up by the increased number of AGP requests. So, the AGP bus with SBA support will end up the faster solution if the size of the individual texture element is small and there's a high number of texture elements used by the 3D application.

But if the size of the texture itself is large (2048x2048), the ratio of MBs of textures transferred to the number of AGP requests sent will greatly increase. This greatly favours the overclocked AGP bus because its higher throughput will enable it to deliver the large textures to the graphics controller faster. Because its speed has essentially remained the same, the AGP bus with SBA will only be able to deliver those large textures at the same throughput.

Looking at it from a latency point of view, the overclocked AGP bus' latency for each and every AGP request and data retrieval is reduced over that of the baseline AGP bus. That means that each AGP transaction across the overclocked AGP bus now incurs less delay to initiate.

On the other hand, the effect of SBA on AGP latency is different. Because SBA does not increase AGP throughput, the initial latency incurred by the first AGP request remains unchanged. But the latency of any subsequent request thereafter is effectively masked because AGP requests can proceed down the SBA without disrupting the AD lines.

This greatly contrasts with the use of the AD lines (in the case of AGP cards that don't support SBA or have it disabled) to transmit AGP requests and commands. In those cases, the AGP pipeline has to be flushed before and after a solitary AGP request is transmitted because it is often in the opposing direction of data transfer. Needless to say, that reduces the efficiency and the effective throughput of the AGP bus tremendously. Even if multiple AGP requests are transmitted in a pipelined fashion, the latencies are still not eliminated or masked although the performance penalty incurred when the pipeline is flushed is reduced.