Espera un ratillo a mi guia para configuracion y ajustes de controladores graficos
H
Eske como apenas e canviado nada...digo vaya.. jeje
Lo ke si me a ido muy bien a sido desabilitat canales IDE ke no utilizaba pero es lo unico ke e echo.. pero weno deleitanos de nuevo y haber si me animo 
Felicidades por tan excelente guia. He notado un aumento de rendimiento 
, pero en mi BIOS no encuentro estas opciones 
:
Video BIOS Cacheable OFF
Video BIOS Shadowing OFF
Video RAM Cacheable OFF
Veremos la importancia en este POST de la memoria cache. De las diferencias cuantitativas y cualitativas de la misma.
Repasaremos la asociatividad y los tipos de cache que en un micro cohabitan. Sin duda vereís como la complejidad aumenta un poco ahora que estamos todos mas familiarizados con los conceptos basicos de lo que es el Clock, Parametros de Memoria, Generadores de Señales, etc...
Para entender el trabajo que desempeña el cacheo en un sistema, nos puede ayudar tremendamente considerar las transacciones entre CPU y memoria como un aparato de producción-consumo.
La CPU consume información que le facilitan los subsistemas de almacenamiento y la memoria, los que actuan como productores.
Debido a las innovaciones y mejoras en la implementacion e integración de los fabricantes de integrados las CPUs tienen la CAPACIDAD DE CONSUMIR INFORMACION a unas frecuencias MUCHO mayores que las de los subsistemas de almacenamiento (HDs, RAM,…).
El problema es que los ciclos de reloj de la CPU (reloj interno) son mas rapidos y de un acceso mas corto que los del SYSTEM CLOCK. Asi que el numero del ciclos de reloj de la CPU que el procesador tiene que estar esperando antes de que la memoria complete su llenado de peticiones es cada vez mayor
**BUS del SISTEMA: SYSTEM CLOCK ó EXTERN CLOCK
**BUS de la CPU: CPU CLOCK ó INTERN CLOCK
Vemos que el factor limitante en este caso como hablabamos anteriormente son los delays en el ciclo de lectura de la memoria.
Para entender mas claro todas estas transacciones criticas acudamos a una analogía. Imaginemos la CPU como una PIZZERIA en Madrid Centro y la DRAM como un almacen de MOZZARELLA en Guadalajara.
Una solucion al problema seria alquilar un local al lado de la pizzería y almacenar todo el queso que pudiéramos. Éste pequeño almacen trabajaria como cache para la pizzería. Solo necesitaríamos una pequeña furgoneta para poder llevar mayores cantidades de queso Mozzarella. Por supuesto cuanto mayor fuera nuestro almacen al lado de la pizzería mucho mejor, ya que podriamos guardar diferentes tipos de queso.
En el caso de que necesitaramos un tipo de queso que no tuvieramos en almacen tendriamos que ir hasta Guadalajara, y claro a no ser de que nuestros pizzeros tuvieran que hacer otras taeras, gran parte de los cocineros estarian de brazos cruzados hasta que llegara el pedido.
Como espero que os hayáis dado cuenta en la analogía y si no lo habéis hecho os lo digo yo; El almacen al lado de la Pizzería es la cache L1.
La cache L1 puede ser accedida rapidamente por la CPU, asi que es un buen sitio para almacenar codigo y datos que la CPU es muy posible que solicite en un momento determinado. Mas tarde hablaremos de la prediccion de la L1 para adivinar los que la CPU solicite.
El rápido tiempo de acceso de la L1 es debido a que esta fabricada de la mas rapida y por supuesto cara memoria estatica (SRAM) . Cada celdilla de SRAM esta construida por 4 transistores, mientras que la DRAM es 1 transistor. El gasto es tan grande que no nos podemos permitir tener unas caches L1 grandes a no ser de que no nos importe que se nos dispare el precio del sistema.
****Recordaros que la cache trabaja a una frecuencia 1:1 con el CPU CLOCK, esto tb se denomina FULL SPEED.
En todas las CPUs actuales los L1 estan localizados en la misma pieza de silicio que el resto del procesador ( on-DIE), en terminos de nuestra grosera analogía es como tener el almacen en el mismo bloque de casas que la pizzería.
Tiene por tanto la ventaja de darle almacenamiento y transporte rapido y urgente al restaurante. Pero la desventaja es que nuestra DRAM esta en Guadalajara y si hay datos que no estan en la cache L1 (almacen al lado de la pizzería) aparecera una situación que se denomina CACHE MISS.
Ademas recordad que debido a que el procesador es mas rapido, la DRAM esta constantemente recibiendo peticiones y eso genera unos delays o retardos que hay que solucionar.
La solucion a este dilema es añadir mas cache engordando el L1, pero las consideraciones de grandisimos costes economicos es el factor limitante de la L1. En terminos de analogía podemos señalar que el alquiler en el Madrid Centro es mas elevado que en Guadalajara y que no nos podemos permitir un gasto similar
Una solucion mas inteligente que aumentar el L1 seria alquilar un almacen mas grande algo mas cerca que Guadalajara, por ejemplo en Vicálvaro.
La cache L2 suele tener todos los datos que estan en L1 mas algunos extra. Es una cache de nivel 2, tb ON-die en los microprocesadores actuales. Evidentemente la L2 cachea la L1 antes de que la ultima haga peticiones a la memoria. Tb actualmente 1:1 con el CPU CLOCK--> Full Speed
***¿Cómo las aplicaciones utilizan la cache???
Hay una forma muy simple que es basico para ver como la cache funciona:
LOCALIZACION y REFERENCIA:
Nosotros generalmente encontramos util hablar de 2 tipos de localizacion:
Localizacion Espacial y Localizacion Temporal:
Localizacion Espacial es la manera elegante de definir la necesidad que tiene la CPU de un item que esta en la DRAM, la necesidad de vecindad para que el transporte sea rapido.
Localizacion Temporal es el nombre que damos a la norma general de que si un item es solicitado por una CPU es muy posible que lo sea pedido en un futuro cercano. Tanto codigo, como datos como pueden presentar localizacion temporal y espacial.
Por ejemplo las aplicaciones MULTIMEDIA tienen buenas localizaciones espaciales, para codigo al igual que todos los juegos, sobre todos los que implementan el motor OpenGL, pero en su contra muy malas localizaciones para datos. Este hecho ha inspirado a las diseñadores de caches a dividir la L1 en dos regiones. Una para codigo y otra para datos. La mitad de codigos de llama i-cache ó cache de instrucciones y la otra mitad es llamada cache de datos ó d-cache.
http://www.cpuid.com/download/cpu-z-119a.zip
Con esta utilidad y en la pestaña cache , podreis observar lo que estamos diciendo de los tipos de L1
Esta partición hace que se gane algo de rendimiento dependiendo claro esta del tamaño de la cache.
Como mencionamos antes la cache captura datos en chunks llamandos bloques o lineas. Cada uno de estos bloques o lineas se alojan en un sitio especial llamado BLOCK FRAME. Estos bloques forman la unidad basica de la organización de la cache. La DRAM tb se organiza de esta forma y los diseñadores de cache pueden elegir diferentes esquemas para gobernar en que Bloques de Memoria pueden ser alojados los BLOCK FRAMES.
Tremendo, curradisimo 
Mi granito de arena sobre configuracion de la BIOS es esta guia muy muy completa, que viene a aconsejar practicamente lo mismo que el maestro ach3chin0:
The Definitive BIOS Optimization Guide - http://www.adriansrojakpot.com/Speed_Demonz/BIOS_Guide/BIOS_Guide_Index.htm
Gracias por tu post de apoyo Pitagoras. RojakPot es una de las mejores sin duda y su labor recopilatoria es tremenda.
Sin embargo lo mas interesante que podria hacer visto que casi todos los usuarios tienen NFORCE II es hacer una guia de Optimizacion de BIOS para ese CHipset.
H
si vale, pero dnd hago todo eso pq yo he entrado en la bios y en ningun lado m sale AGP, ni na.... y tngo opciones q no puedo entrar pfffff no m entero de na...
Qué gran hilo este...
En primer lugar saludar porque soy nuevo en este foro.
Este foro hace que empiece a sentir verdadero interés por la electrónica. Con las charlas del señor H estoy aprendiendo muchas cosas. Muchas gracias.
Hablando del ultimo post sobre memoria caché... decir que tengo un micro AMD K6-2 que creo que carece de L2, aunque por lo que he leído, la L2 suele están integrada en la placa base y no en el micro. ¿Alguien podría aclarar esto?. ¿Si mi placa o mi micro tuvieran L2, entonces notaría mucha diferencia de rendimiento?.
Recuerdo que en mis tiempos de demoscener donde la optimización era crucial, siempre estábamos pensando en cómo acceder a la memoria para minimizar los "Cache-miss" y que las rutinas gráficas volaran. Qué pena que ahora me dedique al software de gestión :-))))
Nada más, encantado de estar por aquí y espero ser de ayuda.
Saludos
Sergio.
Mi granito de arena.
Para los que tengais placas Gigabyte, hay placas que vienen con algunas de las opciones de la BIOS oculta, para hacer que aparezcan pulsad COLTROL+F1.
Y ahora una pregunta. No me acuerdo donde lo lei, pero se decia que el XP no detectaba bien las memoria L2 de mas de 256 kb, y habia que entrar en el registro para introducir el valor manualmente, ¿te suena de algo?
Según una página que habla sobre mi placa (http://www.hwupgrade.com/motherboard/socket7_comparison/index6.html), dice que sí que tiene instalado un chip de memoria cache L2. Pero dice que por encima de los 100Mhz de FSB, podría tener problemas de estabilidad con el L2, ya que funciona a la misma frecuencia (que el FS
.
Por cierto, que los K6-III llevan un caché de tercer nivel (L3), aunque la diferencia de rendimiento no debe ser gran cosa...
Saludos.
Bienvenido Sergiales y gracias por tu interes.
Pues bien, como hemos hablado antes del tema de la cache, tenemos que diferenciar claramente 2 conceptos fundamentales:
SYSTEM CLOCK: 133,166,200 Mhz
CPU CLOCK: Una frecuencia de reloj concretada mediante la resolucion del multiplicador seleccionado.
En los AMD K6-II la cache L2 esta situada fuera de la DIE, es decir reside en la placa pudiendo ser si no me equivoco de 512 Kb o 1 Mbyte segun los modelos.
Esta L2 out-DIE trabaja a la frec del SYSTEM CLOCK, BUS CLOCK ó HOST CLOCK.
Los AMD K6-III tenian como tu dices 3 niveles de cacheo:
L1:64 Kb (On-DIe) Full Speed
L2:128 Kb (On-Die) Full Speed
L3:1 Mbyte (Out-Die) BUS CLOCK
Date cuenta que todo lo integrado en la Die tiene unas frecuencias de trabajo tremendamente mayores.
A tu pregunta de que si la cache L2 la notarías..., buff casi en un 40%.
Esos fallos de cache se arreglan con un poquillo mas de vcore.
Por ahi hemos hablado del comportamiento del micro como un array de transistores y de los 2 estados ON y OFF....
Ya nos iras contando
H
Gracias por tu colaboracion KeteKojo.
Te explico tu duda, no es que sea mas o menos de 256 Kb de cache, la opcion para optimizar el cacheo distingue 2 valores:
0=Desktop
1=Server
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ Session Manager\
Memory Management]
Ahi tienes el registro, el nombre del valor en cuestion es LargeSystemCache.
0 , 1
IO lo hice y NO note ningun incremento en el rendimiento. Date cuenta que para un Desktop le interesa tener memoria para las aplicaciones que corre en un momento concreto, y los Server cachean para File Sharing, es por esto que no le veo gran sentido, y tampoco lo inclui en la GUIA.
No soy amigo de "toquetear" los registros de XP a menos que sean para cosas criticas, como ciertas BIOS sin controles de latencias de memoria (WCPRSet) y cosas por el estilo
H
Vale me e bajado el programa i estoy en la pestaña de cache.. ke tengo ke hacer para mejorar el rendimiento.. es mi pregunta tonta pero me kedo ahi.. no devo llegar a mas.. ya me lo e leido todo.. thz
EL CPUz te marcara los tipos de cache y su asociatividad. Es para que veais la aplicacion practica
H
[En primer lugar, si parece que soy muy novato en juegos, ya os lo digo yo, sí, lo soy]
Después de leer má o meno la rama.. me kedan unas dudillas. Ayer en el Dod puse "net_graph_3" para ver lo de los fps... suelo jugar con el sturmbot 1.6 y me daban unos 72 fps más o menos constantes, entre 69 y 72.
Todo lo de la Bios ya lo tengo bien optimizadito ( OC powa!), pero lo k no sé es que tengo que poner para que me pongan 100fps.
Por otro lado, lo de los fps me se ha puesto en la derecha, tapandome el contador de balas, no hay alguna forma de ponerlo centrao?
Salu2
D3VIL es solo informacion para que veais lo que hace o no hace la cache. Y como incide en el rendimiento.
La vision de estas cosas os hara entender como trabaja la maquinay os aclarara alguna duda que podais tener.
H
Osea esta guia era meramente informativa no? era pk como no pude modificar comandos por la placa ke tenia me dijiste ke aki podria modificar comandos de configuracion para ganar algo de rendimiento
No exactamente D3VIL, tambien tiene su parte eminentemente practica, pero tanto la introduccion al tema del cacheo, como la de la Integracion a gran escala y el del Tema Bandwidth-Latencys(Post que esta preparado en 15 minutos) son teoricos ya que para entender como funciona todo es de gran importancia al menos que os suene lo que es 1 CLOCK, dif entre HOST CLOCK e INTERN CLOCK, Tipos de Cache L1, etc...
Solo el conocimento nos hace libres
H
Pero vamos ... con decir en la guia eso que me has dicho de "FPS_MAX_100" ya bastaría?
Me refiero es que esta guía por ser esta muy bien, pero no se corresponde con el título que le has puesto a la rama.
Ancho de Banda y Latencias: Un aspecto que sin duda os sonara es el del Ancho de Banda. Muchos de vosotros lo habreis visto reflejado en utilidades como SANDRA y AIDA32, pues bien aqui os voy a comentar los mas brevemente posible como se calculan y por lo tanto su incidencia en el rendimiento. Entendereis el porqué de mi insistencia en la sincronia de BUSES. El aspecto opuesto al ancho de Banda es el de las latencias, pero mejor NO os adelanto nada y lo entendeis vosotros mismos:
Otro de los axiomas que tendriamos que dejar claros es la dif entre ANCHO DE BANDA y las LATENCIAS;
Mucha gente y tambien muchos de nosotros tenemos la idea de que el ancho de banda de nuestro SYSTEM BUS es un solo numero que cuantifica cuantos datos pueden circular por el.
En este sentido la apreciación del ancho de banda, de transimision de datos entre el HUB NORTE(NorthBridge) MEMORIA-SYSTEM CLOCK (FS la categorizamos como una propiedad fijada de transmisión de datos, un número al que no le afecta en absoluto los bagajes de los transmisores, ya sea al final o al principio.
Cuando se refieren al ancho de banda del BUS (System CLOCK) lo que quieren describir es un solo tipo de ancho de banda:
*EL MAXIMO ANCHO DE BANDA TEÓRICO de BUS, o tb llamado PEAK BANDWIDTH:
Este peak bandwidth es sencillo de calcular y realmente la información que nos nos proporiciona NO ES RELEVANTE en absoluto.
Es de hecho el bandwidth menos relevante que se puede usar para cuantificar la cantidad de datos transferidos del micro a la memoria via HUB NORTE.
Gralmente ese peak bandwidth en la vida real raras veces se puede conseguir (NUNCA)
Veamos mas de cerca como ese podemos calcular ese peak bandwidth que comentamos es tan sencillo como poco practico.
Tomamos como ejemplo que la memoria manda bloques de 8 byte hacia la CPU. Cada uno de esos bloques de 8 byte lo llamamos word , asi que el sistema envia sucesiones de 4 palabras desde la memoria hacia la CPU.
Ojo, que en este ejemplo asumimos un bus de memoria es de 64 bit (8 byte). Si el BUS de memoria fuera 32 bit solo transmitiríamos 4 bytes en cada ciclo de reloj. Un buen ejemplo es que el memory controller fuera de 128 bit (NFORCE II) entonces enviaríamos 16 bytes por ciclo de reloj
Tambien dejar claro que el ejemplo de transmisión es del tipo SDRAM ya que esos bloques de 8 bit los enviamos en el falling edge del memory clock.
***DDR dobla la transferencia por utilizar los 2 edges, el rising y el falling, aunque eso no tiene mucha importancia, prefiero que queden claros otros conceptos.
OJO dejar claro que un ciclo de reloj completo consiste en un UP BEAT y un DOWN BEAT, para simplificar la cuestion imaginaros ambos fusionados trabajando juntos.
Consideremos esos falling edges como pequeños ganchos en los que la memoria pueden colgar words de 8 bytes y mandarlos como una cadena transportadora hacia la CPU. Como el BUS CLOCK es un pulso continuo tenemos una cadena con ganchos vacios llendo y viniendo cada ciclo de reloj. Esos ganchos vacios representan oportunidades para transmitir codes y datos a la CPU y cada vez que uno circula vacio estamos perdiendo capacidad de transferencia, es decir ancho de banda inútil.
Lo ideal seria tener siempre esos ganchos llenos y usar todo el ancho de banda disponible en cada ciclo de reloj. Pero como veremos mas tarde mantener el Bus totalmente optimizado es muy complicado.
Como explicabamos anteriormente el CPU Clock corre bastante mas que el BUS Clock o System CLock (66,100,133,166,200 Mhz) asi que cada ciclo de Reloj del BUS corresponde a MULTIPLES ciclos de reloj de la CPU (MULTIPLICADORES 7,8,9,….)
Asi podemos entender que ese valor en Mbytes/Sec del SANDRA , AIDA32, etc.., no es en absoluto relevante.
El siguiente concepto a trabajar es un con una importancia mucho mayor, es el:
***ANCHO DE BANDA SOSTENIDO:
Hay veces que 1 unico el pulso u oscilación de reloj que lleva colgada una word o grupo de 8 bytes, los otro 3 pulsos estan vacios debido a la latencia de lectura, asi que el rendimiento del bus antes calculado teóricamente de 1064 mbytes/sec en bandwidth peak se transforma en 266 mbytes en bandwidth sostenido.
Ojo que es la 1/4 parte!!!!
Dependiendo en cuantos buses diferentes tengamos entre la CPU y la RAM y cuantos ciclos de reloj le cuesta a la memoria responder a una petición de datos, estas latencias de lecturas aumentan considerablemente.
En nuestro caso la latencia de lectura son 3 ciclos de BUS, lo que significa que cada vez que la CPU pide una petición de datos tiene que esperar 3 ciclos para que esos datos lleguen. Si la CPU pide 100 peticiones de datos significa 300 ciclos perdidos o ganchos de la analogía anterior que estan vacios.
Estamos perdiendo efectividad en nuestro bandwidth, que es empero uno de los factores que en OVERCLOCKING mas vamos a trabajar.
Asi que con el ejemplo anterior el ancho de banda efectivo seria Πdel ancho de banda maximo.
Para compensar los desastrosos efectos de la latencia de lectura, los sistemas actuales llevan un conjunto de podriamos llamarlos truquillos para mantener el BUS constantemente lleno a pesar de los delays o penalties anteriores (1/4 recordad)
Uno de esos truquillos es minimizar el numero de peticiones de lectura de la CPU para traer dtda cantidad de datos. Si la memoria puede anticipar los datos que la CPU necesitara de forma inmediata y mandarlos entonces la CPU no tendra que hacer peticiones ya que los tendra a su alcance.
Cuando una CPU pide un byte especifico de la memoria, esta no envia solo la petición sino que envia un grupo de ellos y sus vecinos en regiones contiguas, todo esperando que esos bytes vecinos sean necesitados posteriormente y evitar peticiones de datos que generen delays.
Observar tb que esas peticiones de datos tienen que ser escritos en la cache L1 y esta solo acepta una linea de cache entera desde la memoria y no byte individuales. Asi que la memoria manda una linea de cache consistente en los bytes pedidos y los vecinos contiguos.
En todos los diagramas y ejemplos el tamaño de la linea de la cache es de 32 byte o 4 palabras de 8 bytes. Asi que la cache L1 (on die) pide 32 byte de una sola vez.
Como el BUS de la memoria es de 8 bytes (64bit) entonces el system memory tiene que dividir la petición en series de 4 chunks de 8 bytes y enviar esos chunks a traves del BUS.
Son en parte de mis Charlas de Overclocking.
A las que estais todos invitados este año. Cierto cuando se habla en persona es mucho mas sencillo ir resolviendo las dudas que van surgiendo.
La base teorica se ha acabado ya, ahora estoy haciendo una FAQ de optimizacion de NFORCE II que estara en 15 minutos.
H
