Overclock en Intel Core 2 Duo
- Iniciador del tema SeveoR
- Fecha de inicio
La mas alta es la 10. Aunque yo siempre se los paso de unas 10-12 horas a nivel 9, yo diría que es suficiente para decir que es estable 100%, aunque alguno habrá que te dirá por ahi lo contrario.
En 5 no esta mal, pero desde mi punto de vista es bajo, claro.
En 5 no esta mal, pero desde mi punto de vista es bajo, claro.
la prioridad es cuando se abren otros programas.. entonces si tiene 10 y abre otro programa no se le va asignar nada de cpu al nuevo programa porque todo lo esta usando el orthos en cambio si es 5 y abre otro programa pues se repartiran por mitades el cpu... si lo pone en 5 y no abre ningun otro pues es lo mismo que si estuviera en 10 y no abre nada... ya que se le asigna todo el cpu al prog
Teniendo en cuenta que aplicaciones no solamente son las visibles, ni las ejecutadas por el usuario, su apreciación no es matemáticamente precisa. Lo cierto es que son niveles de prioridad y el 10 es la máxima prioridad, que no implica que nivel de prioridad que tendrán las otras aplicaciones, que técnicamente también podrían existir otras aplicaciones con la misma prioridad, incluso la prioridad máxima.
En síntesis en asunto de las prioridades no es un asunto divisible, no es digamos que el sistema reparte: prioridad 8 entonces la otra aplicacion tiene por lógica 2, no, podría tener digamos dos aplicaciones con máxima prioridad y el resto (que incluye tooodo lo que está corriendo en el sistema, visible o no) con prioridad normal.
yo tengo entendido que por mas prioridad que le de a una aplicación (en administrador de tareas de windows) no va a hacer que la misma trabaje mas rápido, solo va a darle "justamente" mas prioridad en caso de que otras aplicaciones esten abiertas y ejecutando procesos. por tanto y en cuanto pienso:
si no ejecuté ninguna otra aplicación mas que el orthos en 8 horas, en prioridad 5. quizás hubiera sido lo mismo que en 10, porque no existía otra aplicación que se estuviera ejecutando.
si esa idea NO esta errada, entonces ejecutar únicamente el orthos en cualquier prioridad seria lo mismo.
pero si por el contrario, la calidad del testeo variara de acuerdo a la prioridad del proceso, mas allá de que existan o no otros programas abiertos. entonces si seria recomendable hacer la en 10.
osea, en resumen:
ejecutando ÚNICAMENTE el orthos ¿da lo mismo prioridad 5 que 10?
si no ejecuté ninguna otra aplicación mas que el orthos en 8 horas, en prioridad 5. quizás hubiera sido lo mismo que en 10, porque no existía otra aplicación que se estuviera ejecutando.
si esa idea NO esta errada, entonces ejecutar únicamente el orthos en cualquier prioridad seria lo mismo.
pero si por el contrario, la calidad del testeo variara de acuerdo a la prioridad del proceso, mas allá de que existan o no otros programas abiertos. entonces si seria recomendable hacer la en 10.
osea, en resumen:
ejecutando ÚNICAMENTE el orthos ¿da lo mismo prioridad 5 que 10?
Estas errado,
La cuestión es diferente, en el caso de Orthos, bajarle la prioridad significa que no tomará el acceso que necesita al procesador para hacer el adecuado testing de estabilidad. Este caso hay que tratarlo diferente, porque se trata de una prueba extrema.
Bajarle prioridad permitirá que el sistema sea más interactivo, permitiendo mejor refresco en la GUI, más proceso para otras actividades que permiten más disponibilidad del sistema.
En síntesis, para una prueba de esta, debería exclusivamente ejecutar el Orthos en su máxima prioridad sin emplear el computador por el tiempo recomendado.
Me quito las palabras de la boca.
Bueno, cambié la fuente y ahora sí puedo hacer OC con el Quad. de hecho me mejoró la estabilidad de la máquina en OC (por ahora básicos) y bajó el voltaje necesario (probablemente por ser mas estable el ripple). Ahora tengo mi primera prueba de OC (para 24/7) de 3000 MHz a FSB 333 con todos los voltajes en estándar (1.2 FSB - 1.25 North - 1.50 South - 1.057 ICH) y el vcore a 1.275V. Asimismo subió el rendimiento de la P. video y logré un ínfimo OC de 702/1620/2106.
Obviamente no me voy a quedar acá con el OC, pero es la primera prueba.
Ahora vuelvo al orthos. El tema es con los quad. Para estresar los 4 núcleos debo ejecutar 2 instancias de orthos, 1 con el 0 y 1, y la otra dándole afinidad manualmente al 2 y 3. Entonces volvería la pregunta sobre la prioridad, aunque creo, que con los post de arriba se responde sola... le pongo a las 2 instancias una prioridad de 9?, porque si es así igualmente la que quedaría en foreground tendría privilegios.
Igualmente creo que con 2 instancias de orthos saturando los 4 núcleos aunque haya una pequeña diferencia de prioridad entre los mismos sería igualmente extremo.
Aunque igualmente me queda otra cosa que acotar. Yo le asignaría prioridad 9 al orthos, pero igualmente no cerraría los programas de background. (ni siquiera la barra lateral del vista), obviamente puede consumir recursos, y bajarle la prioridad absoluta de acceso al orthos, pero el cambio de instrucción bajo tortura también es prueba de estabilidad.
Otra pregunta (hoy estoy molesto!
) Está el Prime95 multicore 25.5.. alguien lo probó? ya que está también en 64 bits nativos y eso estresaría aún mas el CPU. (no puedo probarlo hasta la tarde ya que estoy en el trabajo :nervios: )PD: ya que estamos les comento que le hice OC en la máquina que uso en el trabajo
. Es un celeron D 2.66 GHz en un mother Asrock 775i65G con 512 Mb DDR333. Lo uso permanentemente a 3.61 GHz (181 x 20) con la memoria a 226 MHz (451 MHz DDR). Se la banca la porquería!!! y eso con un BIOS que es una lástima.Bueno, cambié la fuente y ahora sí puedo hacer OC con el Quad. de hecho me mejoró la estabilidad de la máquina en OC (por ahora básicos) y bajó el voltaje necesario (probablemente por ser mas estable el ripple). Ahora tengo mi primera prueba de OC (para 24/7) de 3000 MHz a FSB 333 con todos los voltajes en estándar (1.2 FSB - 1.25 North - 1.50 South - 1.057 ICH) y el vcore a 1.275V. Asimismo subió el rendimiento de la P. video y logré un ínfimo OC de 702/1620/2106.
Obviamente no me voy a quedar acá con el OC, pero es la primera prueba.
Ahora vuelvo al orthos. El tema es con los quad. Para estresar los 4 núcleos debo ejecutar 2 instancias de orthos, 1 con el 0 y 1, y la otra dándole afinidad manualmente al 2 y 3. Entonces volvería la pregunta sobre la prioridad, aunque creo, que con los post de arriba se responde sola... le pongo a las 2 instancias una prioridad de 9?, porque si es así igualmente la que quedaría en foreground tendría privilegios.
Igualmente creo que con 2 instancias de orthos saturando los 4 núcleos aunque haya una pequeña diferencia de prioridad entre los mismos sería igualmente extremo.
Aunque igualmente me queda otra cosa que acotar. Yo le asignaría prioridad 9 al orthos, pero igualmente no cerraría los programas de background. (ni siquiera la barra lateral del vista), obviamente puede consumir recursos, y bajarle la prioridad absoluta de acceso al orthos, pero el cambio de instrucción bajo tortura también es prueba de estabilidad.
Otra pregunta (hoy estoy molesto!
PD: ya que estamos les comento que le hice OC en la máquina que uso en el trabajo
La verdad este tipo de aplicaciones deberían ejecutarse en un modo texto, algo así como esos test de memorias que pueden ejecutarse arrancando el sistema, anticipandose al mismo sistema operativo, eso ofrece un acceso total y exclusivo a la máquina, sin temor a interferencia alguna de terceras aplicaciones, pero parece para la mayoría más confortable ya estar en la interfaz gráfica de Windows. De todos modos tampoco es muy relevante ejecutarlo como se viene haciendo generalmente.
La diferencia entre la ejecución de 32 bits y 64 bits es el modo en que emplean los registros del procesador, pero es la frecuencia de reloj y en la mayoría de los casos la misma cantidad de instrucciones (a menos que venga optizado el software),... bueno el caso es, que teoricamente 64 bits no supondría más carga o más exigencia al procesador, los 32 bits solo emplean la mitad del registro, pero eso supone un tiempo de acceso igual ... bueno, pero con el asunto del tamaño del registro podría tener un procesamiento numérico más ágil, pero esto no quiere decir más carga, sólo que haría más cálculos en menos tiempo.
Exactamente, pero a mayor cantidad de información de instrucciones por ciclo... no haría mas cálculos por ciclo ya que como decís el tiempo de acceso es el mismo, hay mayor cantidad de instrucciones y utiliza un caudal de datos mas grande por ciclos en el registro... por lo tanto ¿No tendría que procesar + caudal, por lo que hay mas probabilidades (casi el doble) de que un dato falle? Solo por estadística, al añadir mayor cantidad de datos, mas probabilidades de fallo a detectar.
Se me ocurre nomás! :nervios:
Exactamente, pero a mayor cantidad de información de instrucciones por ciclo... no haría mas cálculos por ciclo ya que como decís el tiempo de acceso es el mismo, hay mayor cantidad de instrucciones y utiliza un caudal de datos mas grande por ciclos en el registro... por lo tanto ¿No tendría que procesar + caudal, por lo que hay mas probabilidades (casi el doble) de que un dato falle? Solo por estadística, al añadir mayor cantidad de datos, mas probabilidades de fallo a detectar.
Se me ocurre nomás! :nervios:
Lo de instrucciones uno lo ven una materia llamada Lenguaje Maquina y tu suposicion, me parece bastante valida ya que se manejan mas registros y aumenta la informacion a procesar, recordar que cada registro maneja diferentes aspectos.
Nada,
La clave de los 64 bits es esta: "se procesan más datos por cada ciclo del reloj", por eso más resultados en el mismo tiempo.
Ud ejecuta digamos 4 horas de Orthos, por ejemplo, asumiendo que Orthos está aprovechando las ventajas de los 64 bits, entonces realizaría más cálculos porque necesita menos registros, algunas operaciones en 32 bits necesitan doble acceso, en algo que los 64 bits podrían ejecutar en uno solo. Pero en ninguno de los casos el procesador se carga más, el procesador sólo hará lo que puede hacer, lo único es que con 64 bits puede hacerse más eficientemente los cálculos y producir más resultados que con 32 bits, pero el acceso es igual.
Pero hagamos más pedagógica la explicación, llamemos acceso a cualquier operación escritura/lectura, sin entrar en esos detalles que podrían hacer enrredado el asunto (y sí que lo es):
Operacion X: en 32 bits necesita dos accesos al registro, en 64 bits necesita sólo un acceso. Pero digamos que por segundo el procesador solo puede realizar 10,000 ciclos (por decir cualquier barbarie numérica, ese 10,000 no significa nada), entonces ¿Cuántos cálculos se habran hecho en 1 segundo?, 64 bits habrán hecho 10,000, 32 bits 5,000; pero finalmente el procesador hizo 10,000 iteraciones con las dos arquitecturas. Esto es un ejemplo muy didactico, pero eso tampoco es tan así 1 a 2, hay más variables, pero es una aproximación que permite comprender el asunto.
En el caso particular de una prueba extrema como esta, la carga no será mayor en una arquitectura que en otra.
La clave de los 64 bits es esta: "se procesan más datos por cada ciclo del reloj", por eso más resultados en el mismo tiempo.
Ud ejecuta digamos 4 horas de Orthos, por ejemplo, asumiendo que Orthos está aprovechando las ventajas de los 64 bits, entonces realizaría más cálculos porque necesita menos registros, algunas operaciones en 32 bits necesitan doble acceso, en algo que los 64 bits podrían ejecutar en uno solo. Pero en ninguno de los casos el procesador se carga más, el procesador sólo hará lo que puede hacer, lo único es que con 64 bits puede hacerse más eficientemente los cálculos y producir más resultados que con 32 bits, pero el acceso es igual.
Pero hagamos más pedagógica la explicación, llamemos acceso a cualquier operación escritura/lectura, sin entrar en esos detalles que podrían hacer enrredado el asunto (y sí que lo es):
Operacion X: en 32 bits necesita dos accesos al registro, en 64 bits necesita sólo un acceso. Pero digamos que por segundo el procesador solo puede realizar 10,000 ciclos (por decir cualquier barbarie numérica, ese 10,000 no significa nada), entonces ¿Cuántos cálculos se habran hecho en 1 segundo?, 64 bits habrán hecho 10,000, 32 bits 5,000; pero finalmente el procesador hizo 10,000 iteraciones con las dos arquitecturas. Esto es un ejemplo muy didactico, pero eso tampoco es tan así 1 a 2, hay más variables, pero es una aproximación que permite comprender el asunto.
En el caso particular de una prueba extrema como esta, la carga no será mayor en una arquitectura que en otra.
Muchas gracias! entiendo!
Probé el Prime95 25.5a multicore 64 bits, y anda de lujo. Lo dejaré corriendo, ya que bajé el vcore a 1.2625V (El vcore real medido por everest es 1.256)
Adjunto captura: toma automáticamente los 4 cores, lo que para mi caso lo hace mejor que el orthos y agrego captura del coretemp.
Archivos adjuntos
Muchas gracias! entiendo!
Probé el Prime95 25.5a multicore 64 bits, y anda de lujo. Lo dejaré corriendo, ya que bajé el vcore a 1.2625V (El vcore real medido por everest es 1.256)
Adjunto captura: toma automáticamente los 4 cores, lo que para mi caso lo hace mejor que el orthos y agrego captura del coretemp.
Fernandz para las pruebas de tu Q6600, te aconsejo usar el OCCT en su ultima version ya que ha sido mejorada y plantea las mismas interacciones que el Orthos, ademas soporta los 4 nucleos.
Link de Descarga del OCCT
http://files.filefront.com/OCCTPT111brar/;9216164;/fileinfo.html
No puedes subirle frecuencie al FSB del procesador ni por hardware " BIOS " y parece que tampoco por software, asi que te toca implementar esta solucion que es practica y sencilla...
http://www.laneros.com/showpost.php?p=1811494&postcount=324
No entendi fue nada! Ni pio!
Pero gracias
Entonces estas en el lugar equivocado..................
Exacto.
Además, dado el desconocimiento no se le aconseja aún intentar un OC y poner en riesgo su hardware, debería instruirse un poco más al respecto para proseguir con su primer intento.
Los últimos temas
-
Vendo PC Gamer Combo Ryzen 9 5900x / 32Gb Ram / Rtx 3080 / Monitor 4k- Iniciado por Dav1ds
- Respuestas: 2
-
Vendo O Cambio Gran Lote de Celulares de todas las Marcas Nuevos y Usados- Iniciado por filp
- Respuestas: 0
-
-
-
