[APLICACION] Iris Manager (v3.00)

Ya se ha dicho 500 veces que la red no es suficientemente estable para hacer un trabajo así

te comento que he transferido cientos de gigabytes tanto por ETHERNET (1 Gigabit LAN) como por WiFi (300mbps de la PC al AP y de ahi al PS3 por ETHERNET) lo que anteriormente lo hacia via MultiMan o via BlackBox y nunca vi nada igual, luego con la salida de Iris y la inclusion del nuevo FTP-Server tambien recuerdo haber transferido por horas de manera continua, no fue hasta ayer que note este comportamiento del auto-shutdown, quiza porque acabo de cambiar el HDD interno e instalar el Iris mas reciente, pero te digo si mal no recuerdo el Iris anterior a la 2.30 podia estar semanas transfiriendo sin apagarse

Entonces esto tiene solucion, THANKS, si he detectado un bug espero que se me pague mi parte en comision . . .

BillGates escribió:

Ya se ha dicho 500 veces que la red no es suficientemente estable para hacer un trabajo así

te comento que he transferido cientos de gigabytes tanto por ETHERNET (1 Gigabit LAN) como por WiFi (300mbps de la PC al AP y de ahi al PS3 por ETHERNET) lo que anteriormente lo hacia via MultiMan o via BlackBox y nunca vi nada igual, luego con la salida de Iris y la inclusion del nuevo FTP-Server tambien recuerdo haber transferido por horas de manera continua, no fue hasta ayer que note este comportamiento del auto-shutdown, quiza porque acabo de cambiar el HDD interno e instalar el Iris mas reciente, pero te digo si mal no recuerdo el Iris anterior a la 2.30 podia estar semanas transfiriendo sin apagarse

Entonces esto tiene solucion, THANKS, si he detectado un bug espero que se me pague mi parte en comision . . .

Y sin embargo, la red es inestable: si la tienes siempre conectada, al menos via WIFI, apreciarás que simplemente, hay veces que es imposible conectar (a veces, simplemente, entras y tienes que intentar varias veces la conexión) y el mismo pavo que hizo el server FTP, tiene porciones de código repartidas por ahí para intentar resolver algunos de los problemas que aparecen. Ignoro si por cable la cosa mejora, pues nunca he conectado así, pero paso muchas horas usando el FTP como para no ver estos problemas, ya que es mi herramienta de programación: o bien subo el nuevo Iris Manager, desde el propio Iris Manager via FTP, o bien utilizo una aplicación con el FTP antiguo, que tiene la facilidad de que es más rápido para conectar y pulsando X sale al XMB)

A veces, es cuestión de ser pesado: pruebas 10 veces de desconectar/conectar desde flashFXP y acabas conectando. Otras, ni a tiros (y se ve que es que se ha caído de culo toda la puñetera red) y tienes que salir al XMB y cuando reentras, se conecta de inmediato y te quedas con cara de decir: pero que cojones le pasa a ésto . En transferencia no recuerdo nunca que se me haya parado en medio de alguna, pero claro, yo no transfiero 400GB e ignoro si por ejemplo, te salta la pila por los aires o si excedes el número de tareas o algo similar, por que no he estado en ese caso y no es un código que yo conozca a fondo.

Sobre tu "comisión", ya la has cobrado (como suele pasar en estos casos, al que le toca, se jode ) y en realidad el bug lo he detectado yo, que he dicho donde y porqué ocurre el problema (y encima, me tocará arreglarlo, cuando para mí no es un problema ) : tu solo sufriste las consecuencias por usar el FTP "por encima de sus posibilidades" , pero no te preocupes, que en el 2014, "empezaremos a crear empleo"

el FlashFXP sencillamente lo deje porque con ese si que tenia problemas de todo tipo, opte por FileZilla que me ha dado los mejores resultados y no lleva crack ... xD

hace un tiempo atras tenia algunos problemas de conexion y transferencia usando cualquier FTP-Server de la consola (BlackBox y MultiMan), sucedia que algunos archivos eran como doblemente transferidos como si los clientes hicieran un segundo intento de transferir el mismo archivo, la solucion que le encontre a esto fue limitar el numero de conexiones simultaneas a 1 y conectar en modo pasivo, a partir de ahi mas nunca he tenido problemas por FTP.

ayer haciendo unas pruebas realize una conexion rapida al Iris y aparecio el mismo problema de la doble transferencia pero me di cuenta que cuando el FileZilla FTP realiza ese tipo de conexion rapida sin haberle creado un perfil de conexion entonces no limita el numero de conexiones simultaneas, lo solucione con un perfil y limitando otra vez a 1 sola conexion al servidor.

Duda rápida, ¿se puede hacer que cargue los juegos desde un HDD USB?, es que en las opciones de datos de juego, hay varias opciones pero todas son del HDD interno.

Crea la carpeta GAMEZ en el externo y listo.
Siempre se pudo, es para eso.

A ver si alguien me ayuda con esto gente. Tengo el god of war ascension instalado en el interno y con el iris manager emulando el BD el juego anda a las mil maravillas.
Ahora tengo el mismo juego en un disco externo (Spliteado por el archivo grande que lleva) y cuando intento arrancarlo desde el disco externo queda la pantalla en negro y despues vueve al menu de la consola. ¿Alguien tiene alguna idea de cual puede ser el problema?

cristian156 escribió:A ver si alguien me ayuda con esto gente. Tengo el god of war ascension instalado en el interno y con el iris manager emulando el BD el juego anda a las mil maravillas.
Ahora tengo el mismo juego en un disco externo (Spliteado por el archivo grande que lleva) y cuando intento arrancarlo desde el disco externo queda la pantalla en negro y despues vueve al menu de la consola. ¿Alguien tiene alguna idea de cual puede ser el problema?

Creo que te das la respuesta tu mismo, en externo el juego esta spliteado, y salvo que pases a la cache del iris el archivo grande, no te va funcionar. Por cierto, a mi no me hace falta emular BD, para lanzarlo, solo me pide disco dentro. Y con la última versión del Iris y el modo discless lo lanzo sin disco.

HKJ escribió:

cristian156 escribió:A ver si alguien me ayuda con esto gente. Tengo el god of war ascension instalado en el interno y con el iris manager emulando el BD el juego anda a las mil maravillas.
Ahora tengo el mismo juego en un disco externo (Spliteado por el archivo grande que lleva) y cuando intento arrancarlo desde el disco externo queda la pantalla en negro y despues vueve al menu de la consola. ¿Alguien tiene alguna idea de cual puede ser el problema?

Creo que te das la respuesta tu mismo, en externo el juego esta spliteado, y salvo que pases a la cache del iris el archivo grande, no te va funcionar. Por cierto, a mi no me hace falta emular BD, para lanzarlo, solo me pide disco dentro. Y con la última versión del Iris y el modo discless lo lanzo sin disco.

Perfecto eso era lo que queria saber, como ago para pasar el archivo spliteado a la cache del disco?

belmonte_drums escribió:Hola Estwald, he sufrido un error en el manejador de archivos, cuando voy a copiar o mover un juego desde la raíz del USB a hdd/Gamez la play se congela tras darle que si a copiar. En la versión 2.35 no me pasaba,ahora tengo la 2.36 con los archivos parcheados (los detecta bien). Estoy en 4.40 MLT (un crack también este hombre).
He descartado que haya problemas con el disco externo.

Un saludo

Hola de nuevo, como no se ha comentado nada de este error supongo que solo me pasa a mí. He de decir que el juego que estaba copiando estaba en la raíz del disco duro externo, y no dentro de la carpeta GAMEZ (supongo que no debería influir en nada, pero por si acaso sirve de pista). El juego en cuestión es el Batman Arkham City.

He de decir que lo he tenido que copiar con Multimierda, pero si esto se me soluciona desinstalaré MM de mi play, no me gusta que ocupe 300 MB cuando Iris es muchíiiismo más ligero, rápido y mejor en todos los aspectos funcionales para la carga de backups

cristian156 escribió:

HKJ escribió:

cristian156 escribió:A ver si alguien me ayuda con esto gente. Tengo el god of war ascension instalado en el interno y con el iris manager emulando el BD el juego anda a las mil maravillas.
Ahora tengo el mismo juego en un disco externo (Spliteado por el archivo grande que lleva) y cuando intento arrancarlo desde el disco externo queda la pantalla en negro y despues vueve al menu de la consola. ¿Alguien tiene alguna idea de cual puede ser el problema?

Creo que te das la respuesta tu mismo, en externo el juego esta spliteado, y salvo que pases a la cache del iris el archivo grande, no te va funcionar. Por cierto, a mi no me hace falta emular BD, para lanzarlo, solo me pide disco dentro. Y con la última versión del Iris y el modo discless lo lanzo sin disco.

Perfecto eso era lo que queria saber, como ago para pasar el archivo spliteado a la cache del disco?

si se splitea con OpenSplit v1.2 puede pasar, no lo sé,
lo que es seguro, es que si se usa ComgenieAwesomeFilesplitter funciona desde externo

saludos

BillGates escribió:

Ya se ha dicho 500 veces que la red no es suficientemente estable para hacer un trabajo así

te comento que he transferido cientos de gigabytes tanto por ETHERNET (1 Gigabit LAN) como por WiFi (300mbps de la PC al AP y de ahi al PS3 por ETHERNET) lo que anteriormente lo hacia via MultiMan o via BlackBox y nunca vi nada igual, luego con la salida de Iris y la inclusion del nuevo FTP-Server tambien recuerdo haber transferido por horas de manera continua, no fue hasta ayer que note este comportamiento del auto-shutdown, quiza porque acabo de cambiar el HDD interno e instalar el Iris mas reciente, pero te digo si mal no recuerdo el Iris anterior a la 2.30 podia estar semanas transfiriendo sin apagarse

Entonces esto tiene solucion, THANKS, si he detectado un bug espero que se me pague mi parte en comision . . .

aqui tienes tu salario




xDDDDDDDDDDDDDDDD

saludos estwald , veo que estás rompiendo esquemas ,

MiralaTijera escribió:

BillGates escribió:

Ya se ha dicho 500 veces que la red no es suficientemente estable para hacer un trabajo así

te comento que he transferido cientos de gigabytes tanto por ETHERNET (1 Gigabit LAN) como por WiFi (300mbps de la PC al AP y de ahi al PS3 por ETHERNET) lo que anteriormente lo hacia via MultiMan o via BlackBox y nunca vi nada igual, luego con la salida de Iris y la inclusion del nuevo FTP-Server tambien recuerdo haber transferido por horas de manera continua, no fue hasta ayer que note este comportamiento del auto-shutdown, quiza porque acabo de cambiar el HDD interno e instalar el Iris mas reciente, pero te digo si mal no recuerdo el Iris anterior a la 2.30 podia estar semanas transfiriendo sin apagarse

Entonces esto tiene solucion, THANKS, si he detectado un bug espero que se me pague mi parte en comision . . .

aqui tienes tu salario




xDDDDDDDDDDDDDDDD

saludos estwald , veo que estás rompiendo esquemas ,

Tu como siempre tan sutil MiraLaTijera!!

MiralaTijera escribió:

BillGates escribió:

espero que se me pague mi parte en comision . . .

aqui tienes tu salario

xDDDDDDDDDDDDDDDD

saludos estwald , veo que estás rompiendo esquemas ,

Jjajajajaj xDDD eres un caso unico

Estwald como va el tema de controlar velocidad y temperatura de nuestras negritas??

MiralaTijera escribió:

BillGates escribió:

Ya se ha dicho 500 veces que la red no es suficientemente estable para hacer un trabajo así

te comento que he transferido cientos de gigabytes tanto por ETHERNET (1 Gigabit LAN) como por WiFi (300mbps de la PC al AP y de ahi al PS3 por ETHERNET) lo que anteriormente lo hacia via MultiMan o via BlackBox y nunca vi nada igual, luego con la salida de Iris y la inclusion del nuevo FTP-Server tambien recuerdo haber transferido por horas de manera continua, no fue hasta ayer que note este comportamiento del auto-shutdown, quiza porque acabo de cambiar el HDD interno e instalar el Iris mas reciente, pero te digo si mal no recuerdo el Iris anterior a la 2.30 podia estar semanas transfiriendo sin apagarse

Entonces esto tiene solucion, THANKS, si he detectado un bug espero que se me pague mi parte en comision . . .

aqui tienes tu salario




xDDDDDDDDDDDDDDDD

saludos estwald , veo que estás rompiendo esquemas ,

Jajajajaj, pobre tio Bill...

Que hable con sony...

Saludos...

Yo no se que es mejor si la comision de BillGates



O los creditos a miralatijera



Que grande eres Estwald

Donde esta ese imagen dando credito a MLT?¿

Como le gusta a la gente ir ensuciando los hilos, no hay muestra de respeto a su creador ni a los demás

en fin, MLT, no creo que le haga gracia esa imagen que pusiste a Estwald. fijo que por menos ya empiezas a reportar si es tu hilo que te lo hacen.

kikeadsl escribió:Estwald como va el tema de controlar velocidad y temperatura de nuestras negritas??

Bueno, por no ensuciar el hilo de Miralatijera y ahora que estoy en casa de mis padres y no currando , aprovecho para comentar como voy:

Veamos, tengo hecho un programa que permite conectar 4 modos:

- Modo 0, ventilador a toda leche (esto es bueno para expulsar mierda acumulada )

- Modo 1, que como comenté, es el que usa el SYSCON para regular la temperatura

- Modo 2, que nos permite ajustar la velocidad a mano (una fija, que no se puede variar de forma automática, por lo que debería ser razonablemente alta: si no es así, saltará la alarma del SYSCON y nos ajustará el ventilador a toda velocidad )

- Modo 3, que no es otra cosa más que un payload que captura algunas syscalls y de forma mas directa , en ulseep() para tratar de monitorizar las temperaturas.

Y aquí es donde estoy teniendo los problemas: el modo este, no interviene ni en el XMB (ahí lo que hago es dejar una velocidad razonablemente alta), ni por ejemplo, en el emulador de PS1 y supongo que en otras cosas, ocurrirá igual. O sea, la utilidad práctica sería en los juegos de PS3, pero aquí también he tenido problemillas:

En los juegos que he probado hasta el momento (que no son muchos), todo iba bien, excepto en uno que en principio, lo achacaba a algún tipo de problema, pero parece que no es así, si no que la temperatura de la CPU y/o RSX se disparan formando picos que luego decaen rápidamente. Hablo de mantener las revoluciones del ventilador bastante por encima de como la suele tener ajustada el sistema... y que es insuficiente para mantener por debajo de 70º en apariencia (de hecho, antes usaba en ese caso 0xa0 de velocidad (0xff es el máximo y suena como un aspirador ) y lo he tenido que cambiar por que son insoportables las aceleraciones/deceleraciones).

De hecho, me costaba tanto aceptarlo que le echaba la culpa a otras cosas y al final, me las he apañado para poder alojar 64KB para usos propios y el problema persiste igual, con lo que no parece que sea una lectura "defectuosa" (un error de caché que provoque que lea un valor erróneo, pero que no produzca error la función).

Si esto es así, no me extraña eso que mencionaba PLIS-PLAS (si no recuerdo mal) de que con cierto juego, la consola se le apagaba sin que reaccionara el SYSCON o que el mod del potenciómetro ese, no sea tan eficaz, por que hablamos de picos que con 0x78 de velocidad (para que os hagáis una idea: no he visto al sistema meter mas de 0x4d todavía, con temperaturas de 75 grados...) se dan, pero que es que antiguamente estaba en 0x80 y saltaba la velocidad de 0xa0 que la tenía ajustada a esos 70º...

Lo peor es que al volver a la aplicación que tarda solo unos instantes, las temperaturas están mas normales y lo único que llama la atención es que la diferencia de temperatura entre CPU y RSX es menor de lo habitual, por lo que estaba con un mosqueo pensando que algo provocaba lecturas erróneas, pero parece que no es así, si no que son picos sostenidos en el tiempo cuando ciertos juegos le meten tralla a la consola (y hay ciertas condiciones ambientales) y que decaen rápidamente cuando deja de producirse eso y al menos es un poco raro que los picos sean altos (ahora mismo se requieren 70º para que parpadee el led en amarillo-verde), pero no lo suficientemente altos para activar la velocidad total (la que tengo fijada a 75º, no salta).

Con lo cual, parece que hay que rendirse a la evidencia: al menos en este juego, tengo esos picos de temperatura que trastocan un poco los mapas que tenía ajustado en un principio (mantener la temperatura de uso por debajo de los 64 grados y ajustar perfiles de velocidad que llevaran rápidamente a ese rango: si lo hago así, el ruido es infernal)

Con respecto a un comentario que leí por ahí, de mantener la CPU a 50º incluso por debajo... el problema es que un ventilador no es un congelador y depende también de la temperatura ambiental e incluso si el ventilador tiene la capacidad de bajar por debajo de 60º en ciertos casos, en otros es imposible y el nivel de ruido demasiado alto. El ventilador puede soplar (o aspirar), pero seguramente hay un límite de eficacia en el cual se baja poco la temperatura en relación al ruido (velocidad)

Así que estos son los problemas a los que me estoy enfrentando y los que me han retrasado.

Sobre el payload:

Lo he diseñado de forma que permitirá a una aplicación conectarlo, desconectarlo, que mande señales luminosas (verde cuando sale de un programa (XMB) y no regula, amarillo fijo en funcionamiento con temperatura por debajo de 70º, parpadeo amarillo-verde >= 70º), se pueden configurar las temperaturas de respuesta y las velocidades asociadas, etc. Pero habrá que ver como se presenta finalmente.

Saludos

Osea que de momento kizas el modo mas "factible" seria el modo 2 y poner una velocidad relativamente alta (0x80) para evitar los picos que puedan provocar algunos juegos y de paso para evitar que se nos apague la consola sin que el SYSCON la refrigere antes...aunque solamente sea en casos excepcionales

Sea como fuere,estoy seguro k con el tema del payload,daras con el kit de la cuestion tarde o temprano y tendremos un control "insitu" de temperaturas

Gracias fiera!!

Estwald escribió:

kikeadsl escribió:Estwald como va el tema de controlar velocidad y temperatura de nuestras negritas??

Bueno, por no ensuciar el hilo de Miralatijera y ahora que estoy en casa de mis padres y no currando , aprovecho para comentar como voy:

Veamos, tengo hecho un programa que permite conectar 4 modos:

- Modo 0, ventilador a toda leche (esto es bueno para expulsar mierda acumulada )

- Modo 1, que como comenté, es el que usa el SYSCON para regular la temperatura

- Modo 2, que nos permite ajustar la velocidad a mano (una fija, que no se puede variar de forma automática, por lo que debería ser razonablemente alta: si no es así, saltará la alarma del SYSCON y nos ajustará el ventilador a toda velocidad )

- Modo 3, que no es otra cosa más que un payload que captura algunas syscalls y de forma mas directa , en ulseep() para tratar de monitorizar las temperaturas.

Y aquí es donde estoy teniendo los problemas: el modo este, no interviene ni en el XMB (ahí lo que hago es dejar una velocidad razonablemente alta), ni por ejemplo, en el emulador de PS1 y supongo que en otras cosas, ocurrirá igual. O sea, la utilidad práctica sería en los juegos de PS3, pero aquí también he tenido problemillas:

En los juegos que he probado hasta el momento (que no son muchos), todo iba bien, excepto en uno que en principio, lo achacaba a algún tipo de problema, pero parece que no es así, si no que la temperatura de la CPU y/o RSX se disparan formando picos que luego decaen rápidamente. Hablo de mantener las revoluciones del ventilador bastante por encima de como la suele tener ajustada el sistema... y que es insuficiente para mantener por debajo de 70º en apariencia (de hecho, antes usaba en ese caso 0xa0 de velocidad (0xff es el máximo y suena como un aspirador ) y lo he tenido que cambiar por que son insoportables las aceleraciones/deceleraciones).

De hecho, me costaba tanto aceptarlo que le echaba la culpa a otras cosas y al final, me las he apañado para poder alojar 64KB para usos propios y el problema persiste igual, con lo que no parece que sea una lectura "defectuosa" (un error de caché que provoque que lea un valor erróneo, pero que no produzca error la función).

Si esto es así, no me extraña eso que mencionaba PLIS-PLAS (si no recuerdo mal) de que con cierto juego, la consola se le apagaba sin que reaccionara el SYSCON o que el mod del potenciómetro ese, no sea tan eficaz, por que hablamos de picos que con 0x78 de velocidad (para que os hagáis una idea: no he visto al sistema meter mas de 0x4d todavía, con temperaturas de 75 grados...) se dan, pero que es que antiguamente estaba en 0x80 y saltaba la velocidad de 0xa0 que la tenía ajustada a esos 70º...

Lo peor es que al volver a la aplicación que tarda solo unos instantes, las temperaturas están mas normales y lo único que llama la atención es que la diferencia de temperatura entre CPU y RSX es menor de lo habitual, por lo que estaba con un mosqueo pensando que algo provocaba lecturas erróneas, pero parece que no es así, si no que son picos sostenidos en el tiempo cuando ciertos juegos le meten tralla a la consola (y hay ciertas condiciones ambientales) y que decaen rápidamente cuando deja de producirse eso y al menos es un poco raro que los picos sean altos (ahora mismo se requieren 70º para que parpadee el led en amarillo-verde), pero no lo suficientemente altos para activar la velocidad total (la que tengo fijada a 75º, no salta).

Con lo cual, parece que hay que rendirse a la evidencia: al menos en este juego, tengo esos picos de temperatura que trastocan un poco los mapas que tenía ajustado en un principio (mantener la temperatura de uso por debajo de los 64 grados y ajustar perfiles de velocidad que llevaran rápidamente a ese rango: si lo hago así, el ruido es infernal)

Con respecto a un comentario que leí por ahí, de mantener la CPU a 50º incluso por debajo... el problema es que un ventilador no es un congelador y depende también de la temperatura ambiental e incluso si el ventilador tiene la capacidad de bajar por debajo de 60º en ciertos casos, en otros es imposible y el nivel de ruido demasiado alto. El ventilador puede soplar (o aspirar), pero seguramente hay un límite de eficacia en el cual se baja poco la temperatura en relación al ruido (velocidad)

Así que estos son los problemas a los que me estoy enfrentando y los que me han retrasado.

Sobre el payload:

Lo he diseñado de forma que permitirá a una aplicación conectarlo, desconectarlo, que mande señales luminosas (verde cuando sale de un programa (XMB) y no regula, amarillo fijo en funcionamiento con temperatura por debajo de 70º, parpadeo amarillo-verde >= 70º), se pueden configurar las temperaturas de respuesta y las velocidades asociadas, etc. Pero habrá que ver como se presenta finalmente.

Saludos

Mira que yo he testeado juegos y con ninguno he tenido problemas jamás con el potenciometro... de hecho esto yo lo hablé también con Plis-plas.

Mis temperaturas se mantienen la fat en 53 CPU y 47RSX (sin hacer demasiado ruido, a una tercera velocidad aproximadamente, casi cuarta) y la Slim en 55CPU y 51 RSX (Comprobado de hace dos días justo trás tenerlas testeando con el Far Cry 3 conectado durante una hora las dos.

Pd: a qué te refieres con los "picos" que pueden dar los juegos y a qué se deben? Por que a mí no me ha dado ninguno en ninguna de las dos consolas...

PS3 Slim 2504A 160 GB Datacode 0D
PS3 Fat CECHG04 40 GB

Te ha tocado la fibra sensible lo del potenciometro eh MrMento? jajajajaj

kikeadsl escribió:Te ha tocado la fibra sensible lo del potenciometro eh MrMento? jajajajaj

Una lagrima recorre mi cara... :'( jajajajajaja nah que va, me flipa la idea de un pkg que t regule el fan cooler, pero no entiendo lo de los picos porque mira que he hecho pruebas con nose cuantos modelos de consolaa hmpf!
Pd: Kike caraculo xDDDDD

MrMento escribió:Mira que yo he testeado juegos y con ninguno he tenido problemas jamás con el potenciometro... de hecho esto yo lo hablé también con Plis-plas.

Mis temperaturas se mantienen la fat en 53 CPU y 47RSX (sin hacer demasiado ruido, a una tercera velocidad aproximadamente, casi cuarta) y la Slim en 55CPU y 51 RSX (Comprobado de hace dos días justo trás tenerlas testeando con el Far Cry 3 conectado durante una hora las dos.

Pd: a qué te refieres con los "picos" que pueden dar los juegos y a qué se deben? Por que a mí no me ha dado ninguno en ninguna de las dos consolas...

PS3 Slim 2504A 160 GB Datacode 0D
PS3 Fat CECHG04 40 GB

Concuerdo contigo, la fat que tengo se mantiene en ese rango de temperatura, y la ambiente ronda por los 30grados.

Puede que también influya el mantenimiento a la consola, donde el polvo esta algo mas que ausente y con buena pasta y el método del palo, mantiene la consola con un nivel de ruido aceptable.

pd: Lo que me encantaría ver, es la temperatura en el XMB

MrMento escribió:Mira que yo he testeado juegos y con ninguno he tenido problemas jamás con el potenciometro... de hecho esto yo lo hablé también con Plis-plas.

Mis temperaturas se mantienen la fat en 53 CPU y 47RSX (sin hacer demasiado ruido, a una tercera velocidad aproximadamente, casi cuarta) y la Slim en 55CPU y 51 RSX (Comprobado de hace dos días justo trás tenerlas testeando con el Far Cry 3 conectado durante una hora las dos.

Pd: a qué te refieres con los "picos" que pueden dar los juegos y a qué se deben? Por que a mí no me ha dado ninguno en ninguna de las dos consolas...

PS3 Slim 2504A 160 GB Datacode 0D
PS3 Fat CECHG04 40 GB

Se refiere a picos de temperaturas que tu no puedes ver porque se producen dentro de un juego (a no ser que hayas instalado unos sensores con un display digital, o que lo hayas medido mientras jugabas)
Si estais midiendo las temperaturas desde iris o multiman, esas medidas no son reales, porque se tardan unos 10 segundos en salir del juego y entrar en el programa que lo mide
Ademas... en todo caso estarias midiendo la carga del programa que lo mide (es curioso comparar la diferencia de carga del multiman VS iris o de cualquier otro programa que mida la temperatura)
Otro factor que hace que esas temperaturas no sean reales es que cuando las comparamos en los foros no estamos tomando un punto de referencia comun (deberiamos usar todos el mismo programa, o hacerlo desde el XMB)... otro mas es que es dificil saber cuando la temperatura es estable en la placa base (eso de despues de una hora jugando a X juego no es muy preciso, seria mejor tomar la medida "pasados X minutos ejecutando X proceso"... por ejemplo en standby) y la mas importante es que cuando se habla de temperaturas en los foros siempre suele haber gente que escribe en estos hilos como si fuera una competicion de ver quien le ha bendecido dios con la temperatura mas baja, muchas veces incluso autoengañandose

Tambien es importantisimo tener en cuenta lo que ha dicho stewald del tiempo tan pequeño que se tarda en bajar de temperatura cuando el ventilador aumenta la velocidad (o cuando el proceso se termina)... es dificil hablar de numeros siendo preciso, pero para hcernos una idea podriamos decir que en unos 10 segundos la temperatura puede bajar un webal

En resumen... esos 47º del RSX en tu fat no son creibles (es que ni con refrigeracion liquida, y encima dices que no hace ruido)... fijate que a estwald le esta saltando el control automatico porque se pasa de 70º que es el limite que estuvo intentando no pasar en los tests


Bonus:
En tus mods estas cortando el cable gris del ventilador que es una señal PWM, con un rapido vistazo en la wikipedia (http://en.wikipedia.org/wiki/Pulse-width_modulation) te daras cuenta que no es simplemente un cable con un voltage, tu lo estas conectando a un cable de voltage de la fuente de alimentacion, con lo que ya no funciona con control PWM
No dudo que tu mod funcione, pero deberias de avisar que el ventilador no esta diseñado para trabajar asi

MrMento escribió:Mira que yo he testeado juegos y con ninguno he tenido problemas jamás con el potenciometro... de hecho esto yo lo hablé también con Plis-plas.

Mis temperaturas se mantienen la fat en 53 CPU y 47RSX (sin hacer demasiado ruido, a una tercera velocidad aproximadamente, casi cuarta) y la Slim en 55CPU y 51 RSX (Comprobado de hace dos días justo trás tenerlas testeando con el Far Cry 3 conectado durante una hora las dos.

Pd: a qué te refieres con los "picos" que pueden dar los juegos y a qué se deben? Por que a mí no me ha dado ninguno en ninguna de las dos consolas...

PS3 Slim 2504A 160 GB Datacode 0D
PS3 Fat CECHG04 40 GB

Los pico que menciono, no se ven cuando estas en Iris Manager, o en la utilidad Control Fan, ni en Multiman. O sea, no es cuestión de tener ahí la consola cómo un témpano, si no que en momentos puntuales del juego que menciono (Crysis 3), tienes picos de 70º o más grados sostenidos, según lo que reportan las syscalls en determinadas condiciones (ten en cuenta que es normal que estas mediciones sean más altas que si aplicaras un termómetro, dado que la medición se hace en el foco)

Evidentemente, tu no notas nada raro, salvo que la temperatura supere los 80º, pero llama la atención que el propio SYSCON utiliza unos valores relativamente altos de temperatura para cambiar de marcha, aceptando con ello que es un régimen "normal" de temperaturas.

El ventilador, por cierto, no funciona con "marchas" si no que es mucho más "analógico". Pero ya que hablas de marchas, esta es la progresión que yo he observado en Modo 1:

- Según lo conectas 0x33 que es el mínimo que permite el SYSCON (se puede poner por debajo de ese valor, pero rápidamente, lo rectifica)

- A los 74º, cambia a 0x40 y luego sucesivamente a 0x44, 0x4D ...

-0x4D es lo más alto que he observado que ponga él en automático en condiciones "normales". Claro, que también hay que mencionar que el medidor tampoco es muy exigente cómo para aumentar la temperatura a los niveles que estoy comentando. A todo esto, hay que mencionar que 0x4D es el nivel que fija el SYSCON si apagas la consola estando en Modo 2 (manual) (curiosamente, si reinicias, vuelve al Modo 1 (automático), pero en apagado se mantiene el Modo 2).

Pues bien, he probado a dejar la medición de temperatura, pero sin darle la posibilidad de modificar el modo. Esto es, dejarlo en Modo 1, lanzar ese juego en un pasaje que se que dispara la temperatura y dejar solo el lLED para monitorizar. Y en efecto, ahora no lo estoy controlando yo y se ve que el ventilador genera bastante ruido...

Así que salida directa hacia mi utilidad desde el juego, y atrapo unos bonitos 71 grados en el RSX y una velocidad del ventilador 0x5A, fijada por el SYSCON: no estoy soñando, ni mi aplicación hace cosas raras: ahí hay claramente una subida de temperatura y una exigencia al ventilador de parte de una fuente externa, el SYSCON a salvo de posibles interferencias que yo pudiera tener...

Estas son las velocidades que fijo yo ahora mismo:

XMB -> 0x5F (importante: debe ser un valor distinto a los otros empleados, pues en un momento dado, se usa para comparar)

Temp < 62º -> 0x4D

Temp >= 62º subiendo hasta 68º -> 0x54

Temp >= 62 bajando desde 68º -> 0x60

Temp >= 68º -> 0x68

Temp >= 70º -> 0x70

Temp >= 72º -> 0x78

Temp >= 75º -> 0xA0

Pues bien, tenemos que el sistema pone 0x4D cómo cuarta velocidad (que por lo general, es mas que suficiente) y en este juego concreto, con 25º en ambiente en mi habitación, se queda un rato considerable con el led parpadeando en ciertos momentos (es decir: según el medidor >=70, lo cual tiene velocidades de 0x70 o 0x78 dentro de mi modo, mientras que el SYSCON en ese momento, solo fija 0x5A)

Aquí hay que remarcar que lo que yo pensaba al principi,o que era algún otro tipo de problema, pero el SYSCON demuestra que no es así, que los picos existen y que el RSX se pone a una temperatura alta, igualando la de la CPU cuando es hasta "normal" estar de 8 a 10 grados por abajo.

Así que la siguiente prueba ha sido someter el ventilador a una velocidad fija y ruidosa, como es 0x70 y lanzar el puñetero juego a ver que pasa: aunque no se puede regular la velocidad, el led nos indicará si se superan los 70º en algún punto y partimos de 25º en el ambiente, 58 en la CPU y 51 en el RSX antes de lanzar Iris Manager (y bajando desde los 70º en CPU que tenía al principio).

Pues bien, tarda bastante más, pues evidentemente, la velocidad del ventilador es muy alta y el ruido sería muy molesto para mucha gente, pero el LED acaba parpadeando y los 0x70 de velocidad se muestran insuficientes para apagarlo (para mantener a temperatura por debajo de 70º).

Asi que salgo directamente sobre mi aplicación ¿y que lectura tengo? 61º CPU y 62º GPU , que rápidamente descienden a 58º y 53º respectivamente. Ahora entenderás por que pensaba que había algún error y eso me ha llevado a hacer un montón de modificaciones ¿como puede ser que me estén indicando 70º o mas y que en pocos segundos se pase a a una temperaturas mas normales?.

Pues bien, es lo que ocurre y la prueba la tenemos de que en el mismo punto, el SYSCON acelera el ventilador a 0x5A, que ya es ruidoso y cuando volví a la aplicación reflejó en CPU 72º y en GPU 71º (piensa que 0x60, es suficiente en condiciones normales para enfriar la CPU por debajo de 60º. Con 0x70 para que te hagas una idea, después de algunos minutos de haber vuelto del juego, tengo la CPU a 56º y el RSX a 49º y en esas condiciones, pasando a 0x60 en Modo 2 (que tiene un nivel de ruido aceptable), después de unos minutos de funcionamiento, tengo 58º y 51º. Todo ello con una temperatura ambiente de unos 25º y la consola ya calentita, teniendo en cuenta que no se que tipo de ventilador tienes esta y no se le ha cambiado ni la pasta térmica ni nada)

Así que sacando conclusiones, nos queda:

1) La medida de temperatura es directamente en el foco, pues tiene picos altos y decae rápidamente en pocos segundos cuando se deja de generar calor, por que la ventilación es realmente, muy alta ya. Cuando hablo de picos sostenidos me refiero a temperatura relativamente alta, que decae rápidamente en cuanto las condiciones cambian: no tiene ningún sentido que la syscall me arroje esos resultados y estén mal, sin producirse error, pero menos que el propio SYSCON se esté equivocando y ponga a trabajar el ventilador en el mismo sitio, por que detecta una temperatura excesiva

2) La ventilación tiene sus límites: puedes acelerar el ventilador, pero eso no evitará que ni la CPU o el RSX alcancen ciertas temperaturas en pico sostenido, cuando están trabajando intensamente. En términos de ruido, la diferencia entre 0x60 y 0x70 es bastante apreciable, pero sin embargo, la diferencia térmica es de sólo un par de grados en condiciones relativamente normales y en condiciones especiales, puede que retrase un tiempo mayor que el conjunto supere la barrera de los 70º, pero la acaba alcanzando

Por lo tanto, un mod que deje fija la velocidad no garantiza que en ciertas condiciones, no se superen los 70º, salvo que quizá, el ruido sea infernal: las aplicaciones te pueden mostrar un valor engañoso, pero lo que cuenta, es lo que se mida DENTRO del juego, y macho, eso es lo que me dice al menos, para ese juego en concreto y el SYSCON tambien lo ve (otros juegos se mueven en la horquilla normal que he fijado).

He hecho una, tabla fijando la velocidad a mano en estas condiciones (consola ya caliente y ambiente a 25º), después de unos minutos:

A 0x60: CPU 58º, RSX 51º (ruido moderadamente aceptable)
A 0x70: CPU 56º, RSX 49º (ruido poco aceptable)
A 0x80: CPU 54º, RSX 47º (ruido molesto)
A 0x90: CPU 53º, RSX 46º (ruido bastante molesto)
A 0xA0: CPU 52º, RSX 45º (apaga el puto secador de pelo! )

Se aprecia que a partir de 0x90, la caída de temperatura es muy pequeña y el ruido es espectacular. Además, hay que tener en cuenta que todas las medidas se han hecho en un momento en que no se está incrementando la temperatura y después de varios minutos de espera.

Entre 0x60 y 0x80, el ruido cambia drásticamente para conseguir unos 4º de diferencia, pero en mi opinión 0x60 debería ser lo máximo en funcionamiento normal y la horquilla debería ir hasta 0x70 con momentos puntuales a 0x80 como mucho. Todo lo que sea exceder esto, puede ser bueno para bajar la temperatura, pero quizá cuando se necesite, la diferencia sea de solo 1 o 2º sólo y compense menos y lo que es peor: no conseguiremos que la temperatura esté por debajo de un límite.

A todo esto, decir que no todos los juegos son iguales: con el mod podemos ganar un poco más de ruido y sin embargo, tener temperaturas que pueden ser 10º menores que si le dejamos hacer al SYSCON.

En juegos de PS3 ésto puede ser factible, pero en otras áreas del sistema, obviamente no, si incluyen la destrucción de payload (emulador de PS2, a menos, el de las consolas Retrocompatibles) o por ejemplo, con el tema de PS1 que lo esquiva e incluso si lo activa, lo hace para peor (tengo que mirar de al menos, hacer que se active una velocidad fija). En Minis de PSP, parece que si funciona.

En fin, que todavía queda currele para terminar esto, pero lo que me molesta es que debido a ese juego donde he detectado estos problemas, he tenido que variar algunos perfiles y no atacar tan drásticamente la subida de temperaturas: todas las velocidades que fijo son bastante mayores a las que fija el SYSCON (si el ve como "alta" 0x4D, yo la veo como mínima), pero tengo que aceptar que la temperatura pueda subir en casos concretos, aunque pueda pelear para tener unas temperaturas mucho mas aceptables y un régimen del ventilador mas alto que lo que fijaría el SYSCON (lo que no puedo hacer es decir: si pasas de X temperatura, te ataco con toda la tralla, por que al final, estará todo el rato dando trallazos y no evito que pase de esa X temperatura. O eso, o jugamos con un aspirador )

Saludos

Lo de usar el led para medir la temperatura es una idea muy buena para los tests
Se me ocurre otra forma de mostrar temperaturas con el led... podrias hacer que parpadease (siempre del mismo color, por ejemplo rojo) pero a diferentes velocidades (a mas temperatura = mas deprisa)... y en las temperaturas que sean multiplos de 10º que diera las "campanadas" (como un reloj en las horas en punto, por ejemplo a 60º que parpadease 6 veces en lento, o en otro color... o podrias usar el altavoz de la placa base)
No se si esto es factible, quizas haria el codigo demasiado grande pero bueno ahi queda la idea

La verdad es qe dejando aparte esos picos de temperatura (que es un problema bastante gordo, aunque al fin y al cabo en condiciones normales tambien pasan)... lo tienes bastante controlado, muy buena investigacion

Edit:
Ahh, por cierto, creo que eres el primero en medir temperaturas dentro de un juego usando software x2

Edit2:

Estwald escribió:lo que no puedo hacer es decir: si pasas de X temperatura, te ataco con toda la tralla, por que al final, estará todo el rato dando trallazos y no evito que pase de esa X temperatura. O eso, o jugamos con un aspirador

Pero en tu payload tu tienes digamos... una "tabla" de valores de temperaturas fijados que corresponden a velocidades del ventilador, dependiendo de la temperatura medida en los sensores se usan unos valores u otros de la tabla, no ?
Entonces si que puedes atacar "con toda la tralla" si pasa de X valor... en realidad sony ha tenido que pelear con el mismo problema, nunca lo habia pensado, pero ahora que lo comentas supongo que el syscon hace una media de temperaturas entre diferentes temperaturas medidas en un espacio de tiempo (digamos que coge 1 sola medida de los sensores cada minuto o hace un calculo entre varias)
Es la unica forma que se me ocurre ahora mismo que ha usado sony para evitar que el ventilador se vuelva loco cuando se produzca uno de esos picos, tu podrias hacer lo mismo aunque aumentaria el tamaño del codigo si vas a hacr calculos con varias medidas

SOLO PARA ACLARAR UN PUNTO SOBRE LA TEMPERATURA:

FAT 90 NM CELL
Esas son las que acusan los picos.

MODELOS:
CECH A
CECH B
CECH C
CECH E

LOS MODELOS G EN ADELANTE TIENEN CELL DE 65 NM Y ES POSIBLE QUE NO ACUSEN EL PICO AUNQUE LO SUFRAN, PUES GENERAN MENOS CALOR, HACIENDOLOS MAS MANIOBRABLES PARA ENFRIARLOS NATURALMENTE.

Todo esto es mejor testearlo despues de un cambio de pasta y limpieza de disipadores, como hice yo.
Ademas los modelos de 90nm traen ventilador de 15 aspas, que son muy ruidosos y generan contracorrientes que hacen que el diseño de enfriamiento sea al menos "NO IDÓNEO"
Luego de cambiar el ventilador a uno de 19 aspas se logran unos grados menos y la mitad de ruido, asi que si tienes la oportunidad haz ese cambio.
Tambien existen los ventiladores de 17 aspas que estan a medio camino pero mejor no usarlos en 90nm.

Todos estos sistemas que menciono tienen 3 cables desde el ventilador a la placa y el viejo truco de cortar el cable gris y darle voltaje funciona, pero con un mod es mejor que conectarlo directo.


Hice este dibujo para los ansiosos:

Lo cuadrado es el conector de la placa.

Bueno, no ensucio mas el hilo.

Estwald escribió:

MrMento escribió:Mira que yo he testeado juegos y con ninguno he tenido problemas jamás con el potenciometro... de hecho esto yo lo hablé también con Plis-plas.

Mis temperaturas se mantienen la fat en 53 CPU y 47RSX (sin hacer demasiado ruido, a una tercera velocidad aproximadamente, casi cuarta) y la Slim en 55CPU y 51 RSX (Comprobado de hace dos días justo trás tenerlas testeando con el Far Cry 3 conectado durante una hora las dos.

Pd: a qué te refieres con los "picos" que pueden dar los juegos y a qué se deben? Por que a mí no me ha dado ninguno en ninguna de las dos consolas...

PS3 Slim 2504A 160 GB Datacode 0D
PS3 Fat CECHG04 40 GB

Los pico que menciono, no se ven cuando estas en Iris Manager, o en la utilidad Control Fan, ni en Multiman. O sea, no es cuestión de tener ahí la consola cómo un témpano, si no que en momentos puntuales del juego que menciono (Crysis 3), tienes picos de 70º o más grados sostenidos, según lo que reportan las syscalls en determinadas condiciones (ten en cuenta que es normal que estas mediciones sean más altas que si aplicaras un termómetro, dado que la medición se hace en el foco)

Evidentemente, tu no notas nada raro, salvo que la temperatura supere los 80º, pero llama la atención que el propio SYSCON utiliza unos valores relativamente altos de temperatura para cambiar de marcha, aceptando con ello que es un régimen "normal" de temperaturas.

El ventilador, por cierto, no funciona con "marchas" si no que es mucho más "analógico". Pero ya que hablas de marchas, esta es la progresión que yo he observado en Modo 1:

- Según lo conectas 0x33 que es el mínimo que permite el SYSCON (se puede poner por debajo de ese valor, pero rápidamente, lo rectifica)

- A los 74º, cambia a 0x40 y luego sucesivamente a 0x44, 0x4D ...

-0x4D es lo más alto que he observado que ponga él en automático en condiciones "normales". Claro, que también hay que mencionar que el medidor tampoco es muy exigente cómo para aumentar la temperatura a los niveles que estoy comentando. A todo esto, hay que mencionar que 0x4D es el nivel que fija el SYSCON si apagas la consola estando en Modo 2 (manual) (curiosamente, si reinicias, vuelve al Modo 1 (automático), pero en apagado se mantiene el Modo 2).

Pues bien, he probado a dejar la medición de temperatura, pero sin darle la posibilidad de modificar el modo. Esto es, dejarlo en Modo 1, lanzar ese juego en un pasaje que se que dispara la temperatura y dejar solo el lLED para monitorizar. Y en efecto, ahora no lo estoy controlando yo y se ve que el ventilador genera bastante ruido...

Así que salida directa hacia mi utilidad desde el juego, y atrapo unos bonitos 71 grados en el RSX y una velocidad del ventilador 0x5A, fijada por el SYSCON: no estoy soñando, ni mi aplicación hace cosas raras: ahí hay claramente una subida de temperatura y una exigencia al ventilador de parte de una fuente externa, el SYSCON a salvo de posibles interferencias que yo pudiera tener...

Estas son las velocidades que fijo yo ahora mismo:

XMB -> 0x5F (importante: debe ser un valor distinto a los otros empleados, pues en un momento dado, se usa para comparar)

Temp < 62º -> 0x4D

Temp >= 62º subiendo hasta 68º -> 0x54

Temp >= 62 bajando desde 68º -> 0x60

Temp >= 68º -> 0x68

Temp >= 70º -> 0x70

Temp >= 72º -> 0x78

Temp >= 75º -> 0xA0

Pues bien, tenemos que el sistema pone 0x4D cómo cuarta velocidad (que por lo general, es mas que suficiente) y en este juego concreto, con 25º en ambiente en mi habitación, se queda un rato considerable con el led parpadeando en ciertos momentos (es decir: según el medidor >=70, lo cual tiene velocidades de 0x70 o 0x78 dentro de mi modo, mientras que el SYSCON en ese momento, solo fija 0x5A)

Aquí hay que remarcar que lo que yo pensaba al principi,o que era algún otro tipo de problema, pero el SYSCON demuestra que no es así, que los picos existen y que el RSX se pone a una temperatura alta, igualando la de la CPU cuando es hasta "normal" estar de 8 a 10 grados por abajo.

Así que la siguiente prueba ha sido someter el ventilador a una velocidad fija y ruidosa, como es 0x70 y lanzar el puñetero juego a ver que pasa: aunque no se puede regular la velocidad, el led nos indicará si se superan los 70º en algún punto y partimos de 25º en el ambiente, 58 en la CPU y 51 en el RSX antes de lanzar Iris Manager (y bajando desde los 70º en CPU que tenía al principio).

Pues bien, tarda bastante más, pues evidentemente, la velocidad del ventilador es muy alta y el ruido sería muy molesto para mucha gente, pero el LED acaba parpadeando y los 0x70 de velocidad se muestran insuficientes para apagarlo (para mantener a temperatura por debajo de 70º).

Asi que salgo directamente sobre mi aplicación ¿y que lectura tengo? 61º CPU y 62º GPU , que rápidamente descienden a 58º y 53º respectivamente. Ahora entenderás por que pensaba que había algún error y eso me ha llevado a hacer un montón de modificaciones ¿como puede ser que me estén indicando 70º o mas y que en pocos segundos se pase a a una temperaturas mas normales?.

Pues bien, es lo que ocurre y la prueba la tenemos de que en el mismo punto, el SYSCON acelera el ventilador a 0x5A, que ya es ruidoso y cuando volví a la aplicación reflejó en CPU 72º y en GPU 71º (piensa que 0x60, es suficiente en condiciones normales para enfriar la CPU por debajo de 60º. Con 0x70 para que te hagas una idea, después de algunos minutos de haber vuelto del juego, tengo la CPU a 56º y el RSX a 49º y en esas condiciones, pasando a 0x60 en Modo 2 (que tiene un nivel de ruido aceptable), después de unos minutos de funcionamiento, tengo 58º y 51º. Todo ello con una temperatura ambiente de unos 25º y la consola ya calentita, teniendo en cuenta que no se que tipo de ventilador tienes esta y no se le ha cambiado ni la pasta térmica ni nada)

Así que sacando conclusiones, nos queda:

1) La medida de temperatura es directamente en el foco, pues tiene picos altos y decae rápidamente en pocos segundos cuando se deja de generar calor, por que la ventilación es realmente, muy alta ya. Cuando hablo de picos sostenidos me refiero a temperatura relativamente alta, que decae rápidamente en cuanto las condiciones cambian: no tiene ningún sentido que la syscall me arroje esos resultados y estén mal, sin producirse error, pero menos que el propio SYSCON se esté equivocando y ponga a trabajar el ventilador en el mismo sitio, por que detecta una temperatura excesiva

2) La ventilación tiene sus límites: puedes acelerar el ventilador, pero eso no evitará que ni la CPU o el RSX alcancen ciertas temperaturas en pico sostenido, cuando están trabajando intensamente. En términos de ruido, la diferencia entre 0x60 y 0x70 es bastante apreciable, pero sin embargo, la diferencia térmica es de sólo un par de grados en condiciones relativamente normales y en condiciones especiales, puede que retrase un tiempo mayor que el conjunto supere la barrera de los 70º, pero la acaba alcanzando

Por lo tanto, un mod que deje fija la velocidad no garantiza que en ciertas condiciones, no se superen los 70º, salvo que quizá, el ruido sea infernal: las aplicaciones te pueden mostrar un valor engañoso, pero lo que cuenta, es lo que se mida DENTRO del juego, y macho, eso es lo que me dice al menos, para ese juego en concreto y el SYSCON tambien lo ve (otros juegos se mueven en la horquilla normal que he fijado).

He hecho una, tabla fijando la velocidad a mano en estas condiciones (consola ya caliente y ambiente a 25º), después de unos minutos:

A 0x60: CPU 58º, RSX 51º (ruido moderadamente aceptable)
A 0x70: CPU 56º, RSX 49º (ruido poco aceptable)
A 0x80: CPU 54º, RSX 47º (ruido molesto)
A 0x90: CPU 53º, RSX 46º (ruido bastante molesto)
A 0xA0: CPU 52º, RSX 45º (apaga el puto secador de pelo! )

Se aprecia que a partir de 0x90, la caída de temperatura es muy pequeña y el ruido es espectacular. Además, hay que tener en cuenta que todas las medidas se han hecho en un momento en que no se está incrementando la temperatura y después de varios minutos de espera.

Entre 0x60 y 0x80, el ruido cambia drásticamente para conseguir unos 4º de diferencia, pero en mi opinión 0x60 debería ser lo máximo en funcionamiento normal y la horquilla debería ir hasta 0x70 con momentos puntuales a 0x80 como mucho. Todo lo que sea exceder esto, puede ser bueno para bajar la temperatura, pero quizá cuando se necesite, la diferencia sea de solo 1 o 2º sólo y compense menos y lo que es peor: no conseguiremos que la temperatura esté por debajo de un límite.

A todo esto, decir que no todos los juegos son iguales: con el mod podemos ganar un poco más de ruido y sin embargo, tener temperaturas que pueden ser 10º menores que si le dejamos hacer al SYSCON.

En juegos de PS3 ésto puede ser factible, pero en otras áreas del sistema, obviamente no, si incluyen la destrucción de payload (emulador de PS2, a menos, el de las consolas Retrocompatibles) o por ejemplo, con el tema de PS1 que lo esquiva e incluso si lo activa, lo hace para peor (tengo que mirar de al menos, hacer que se active una velocidad fija). En Minis de PSP, parece que si funciona.

En fin, que todavía queda currele para terminar esto, pero lo que me molesta es que debido a ese juego donde he detectado estos problemas, he tenido que variar algunos perfiles y no atacar tan drásticamente la subida de temperaturas: todas las velocidades que fijo son bastante mayores a las que fija el SYSCON (si el ve como "alta" 0x4D, yo la veo como mínima), pero tengo que aceptar que la temperatura pueda subir en casos concretos, aunque pueda pelear para tener unas temperaturas mucho mas aceptables y un régimen del ventilador mas alto que lo que fijaría el SYSCON (lo que no puedo hacer es decir: si pasas de X temperatura, te ataco con toda la tralla, por que al final, estará todo el rato dando trallazos y no evito que pase de esa X temperatura. O eso, o jugamos con un aspirador )

Saludos

Gracce mille, es muy lógica (y me creo al 100%) tu explicación, quizá me ha fallado el no testar las temperaturas con un sensor, no dispongo de ninguno, pero ya pillo lo de los picos.

Por otra parte, cuando digo que mi PS3 no molesta, es porque también la tengo a tomar por saco de mi y de mi TV, está en un armario y si te acercas obvio, parece un aspirador (aunque no esté al máximo PERO si a una velocidad bastante alta (la FAT al menos)).

De todas maneras, todo esto haré una síntesis y lo pondré en mis hilos, considero que es muy importante, y mantendré los MODS SOLO para la gente que NO tenga un CFW (ya que prefiero usar un ventilador acelerado vía payload/syscall como has explicado tu a tener que estar con el potenciómetro de las pelotas )

Más cosas: el ventilador con el MOD, es obvio, más efectivo en fat que en slim, las slim de hecho NO hace falta hacer el mod, son bastante frescas, pero hay algunas (como la mía) que no sé por qué narices llegaba a una temperatura muy elevada estando simplemente en IRIS, en su día, me llegaba a 77ºRSX 79CPU (inexplicable), por lo que hice el MOD y teniéndola encendida en IRIS sin tocar nada, me bajó a las temperaturas que cito (también teniéndola a una velocidad bastante ruidosa, pero que a mí desde luego ni me molesta porque mis PS3 están en disposiciones bastante alejadas de mí entre otras cosas).

Por último, Estwald, me llega mañana un colega con una PS3 FAT Retro que alcanza (en multiman) sin tocar nada 82ºRSX y 80º en CPU, te lo digo porque esa PS3 me ha dicho que la tiene para pruebas y demás, si necesitases cualquier ayuda con la tool o testeos y demás, cuenta conmigo (ya que la refrigeración me interesa y demás, cuenta con mi ayuda).


Gracias tío, por todas tus explicaciones, bastante claro todo

Hola,

ya tengo el emulador de PSX dentro: al final, el problema era que usaba un contador para descartar usleep y en cuanto lo he cambiado por muestreos del RTC (el reloj, mediante la llamada a LV1), no solo he conseguido una medida más regular por tiempo, si no que también funciona en el emu de PSX

Ahora tomamos una muestra de temperatura cada 3 segundos, por que se ha dividido el proceso en 3 pasos de un segundo aproximadamente.

El primer paso, toma la temperatura, el segundo fija el ventilador si es necesario, en base a esa temperatura y el tercer paso, fija los leds.

En éste último paso he metido una pequeña innovación que consiste en que una vez cada 30 segundos, aproximadamente, el led amarillo, se apaga: digamos que eso sirve como test de que realmente, tenemos lo de la temperatura funcionando

Estoy comentando el código, luego lo probaré, meteré un testigo especial para cuando la temperatura supere 75º, haré un par de ñapas y a ver si es posible publicarlo ya (no en Iris Manager, de momento, si no como PKG independiente, en fase de pruebas)

Sobre algunas cosas que habéis comentado:

- Los LEDs no se pueden manejar de cualquier manera: no puedo decirle que parpadee 5 veces de forma seguida, por que en el fondo, no se ni cuando responderá el sistema, ni cómo: depende de los usleeps que se encuentre y el tiempo mínimo de respuesta es de 1 segundo al menos y aparte hay otros problemas (como que no todo el mundo tiene los leds de colores, por ejemplo )

- Sobre como opera el SYSCON las temperaturas, parece que tiene un rango por encima y otro por debajo y que en realidad, le da un tiempo cuando fija la velocidad del ventilador, antes de volver a cambiar de velocidad: si en 74º cambia de velocidad, tendrá que ver si pasado un tiempo, la evolución sigue hacia arriba o no. Y lo que si es cierto, es que una vez que sube de velocidad, ya no la baja por que la temperatura haya bajado a un límite donde antes, con una velocidad menor, estaba bien: la mantiene no se si hasta que pasa una temperatura de corte hacia abajo o eso mas que haya pasado un determinado tiempo sin subir, o algo parecido.

No creo que funcione haciendo medias de temperatura, simplemente.

- Por otro lado, cada consola es un mundo, obviamente: si hay una consola que tiene unos niveles de temperatura completamente anormales, lógicamente, la solución no es simplemente, poner a tope el ventilador: algún problema habrá subyacente.

La idea es que dentro de lo posible, evitemos que por ser demasiados conservadores con el ruido que genere el ventilador, permitamos unos grados de más que pueden dar problema con el tiempo: si alguien ha cambiado el ventilador por uno más eficiente, la pasta térmica, etc, pues lógicamente, el payload funcionará con las menores relaciones de velocidad/ruido y bien para el. Ni idea de como irá en las Slim y supongo que mi consola, es de las FAT veteranas que están en buen estado, pues su temperaturas no son excesivas (nunca la he visto por encima de 75º) sin haberle hecho nada de nada.

Pero tampoco es lógico ajustar el payload para alguien que tiene un problema evidente de refrigeración por que ya de por si se le pone por las nubes: eso no lo va a solucionar la aplicación, ni fijar la velocidad muy alta a mano, ni poner un potenciómetro, ni dejar el ventilador al máximo (eso es como si tengo la pierna rota y pretendo curarla tomando medicación para soportar el dolor).

La idea cómo digo, es tener un control que sea más agresivo que el SYSCON, pero si un juego me pone la CPU o el RSX a 70º, no es lo mismo que si en condiciones normales ya está a 74-75º por que al SYSCON le parece bien o tener unos grados de más por que el ventilador va poco revolucionado, etc

Eres un genio Estwald. Una consulta, yo vivo en Argentina y a veces en este verano que no quiere terminar, se me puso a veces la temperatura a 80º pero luego se autoregula y baja a 70 - 75 º. Piensas que con tu aplicación se va a mantener a 70 mas o menos?

Edito: Es una fat de 40 gb y nunca le cambie la pasta ni nada, nunca fue abierta.

Saludos

Estwald escribió:Hola,

ya tengo el emulador de PSX dentro: al final, el problema era que usaba un contador para descartar usleep y en cuanto lo he cambiado por muestreos del RTC (el reloj, mediante la llamada a LV1), no solo he conseguido una medida más regular por tiempo, si no que también funciona en el emu de PSX

Ahora tomamos una muestra de temperatura cada 3 segundos, por que se ha dividido el proceso en 3 pasos de un segundo aproximadamente.

El primer paso, toma la temperatura, el segundo fija el ventilador si es necesario, en base a esa temperatura y el tercer paso, fija los leds.

En éste último paso he metido una pequeña innovación que consiste en que una vez cada 30 segundos, aproximadamente, el led amarillo, se apaga: digamos que eso sirve como test de que realmente, tenemos lo de la temperatura funcionando

Estoy comentando el código, luego lo probaré, meteré un testigo especial para cuando la temperatura supere 75º, haré un par de ñapas y a ver si es posible publicarlo ya (no en Iris Manager, de momento, si no como PKG independiente, en fase de pruebas)

Sobre algunas cosas que habéis comentado:

- Los LEDs no se pueden manejar de cualquier manera: no puedo decirle que parpadee 5 veces de forma seguida, por que en el fondo, no se ni cuando responderá el sistema, ni cómo: depende de los usleeps que se encuentre y el tiempo mínimo de respuesta es de 1 segundo al menos y aparte hay otros problemas (como que no todo el mundo tiene los leds de colores, por ejemplo )

- Sobre como opera el SYSCON las temperaturas, parece que tiene un rango por encima y otro por debajo y que en realidad, le da un tiempo cuando fija la velocidad del ventilador, antes de volver a cambiar de velocidad: si en 74º cambia de velocidad, tendrá que ver si pasado un tiempo, la evolución sigue hacia arriba o no. Y lo que si es cierto, es que una vez que sube de velocidad, ya no la baja por que la temperatura haya bajado a un límite donde antes, con una velocidad menor, estaba bien: la mantiene no se si hasta que pasa una temperatura de corte hacia abajo o eso mas que haya pasado un determinado tiempo sin subir, o algo parecido.

No creo que funcione haciendo medias de temperatura, simplemente.

- Por otro lado, cada consola es un mundo, obviamente: si hay una consola que tiene unos niveles de temperatura completamente anormales, lógicamente, la solución no es simplemente, poner a tope el ventilador: algún problema habrá subyacente.

La idea es que dentro de lo posible, evitemos que por ser demasiados conservadores con el ruido que genere el ventilador, permitamos unos grados de más que pueden dar problema con el tiempo: si alguien ha cambiado el ventilador por uno más eficiente, la pasta térmica, etc, pues lógicamente, el payload funcionará con las menores relaciones de velocidad/ruido y bien para el. Ni idea de como irá en las Slim y supongo que mi consola, es de las FAT veteranas que están en buen estado, pues su temperaturas no son excesivas (nunca la he visto por encima de 75º) sin haberle hecho nada de nada.

Pero tampoco es lógico ajustar el payload para alguien que tiene un problema evidente de refrigeración por que ya de por si se le pone por las nubes: eso no lo va a solucionar la aplicación, ni fijar la velocidad muy alta a mano, ni poner un potenciómetro, ni dejar el ventilador al máximo (eso es como si tengo la pierna rota y pretendo curarla tomando medicación para soportar el dolor).

La idea cómo digo, es tener un control que sea más agresivo que el SYSCON, pero si un juego me pone la CPU o el RSX a 70º, no es lo mismo que si en condiciones normales ya está a 74-75º por que al SYSCON le parece bien o tener unos grados de más por que el ventilador va poco revolucionado, etc

si te interesa podrías comunicarte con el syscon directamente usando lv1 peek / poke , y sin usar ni una sola syscall... si quieres te hecho un cable con ello solamente es saber como se le mandan unos paquetillos , aunque quizás no funcione si el service que usa hypervisor necesita auth1 y auth2 se volvería mas peliagudo.. aunque veo que te lo has apañado genial usando llamadas :-D ere un crá

por cierto , he encontrado un posible fix ( lo que es dificil por que es via hardware ) de arreglar el problema sin controladora en iris manager con el ps3_payload y el montaje de bd , ahora no pega panic y monta pero ay que hacer un mod por hardware y facil no es ya que lo que hice fue convertir la señal ide a S-ATA y conectar un lector de pc xD veo que la historia reside en lv1 y estoy intentando fixearlo via software ya que ahora mas que nunca sé que solo detecta la presencia de "algo" en el puerto del lector... vamos toda una genialidad por parte de los engineers de ps3... xD

saludos

MiralaTijera escribió:

Estwald escribió:Hola,

ya tengo el emulador de PSX dentro: al final, el problema era que usaba un contador para descartar usleep y en cuanto lo he cambiado por muestreos del RTC (el reloj, mediante la llamada a LV1), no solo he conseguido una medida más regular por tiempo, si no que también funciona en el emu de PSX

Ahora tomamos una muestra de temperatura cada 3 segundos, por que se ha dividido el proceso en 3 pasos de un segundo aproximadamente.

El primer paso, toma la temperatura, el segundo fija el ventilador si es necesario, en base a esa temperatura y el tercer paso, fija los leds.

En éste último paso he metido una pequeña innovación que consiste en que una vez cada 30 segundos, aproximadamente, el led amarillo, se apaga: digamos que eso sirve como test de que realmente, tenemos lo de la temperatura funcionando

Estoy comentando el código, luego lo probaré, meteré un testigo especial para cuando la temperatura supere 75º, haré un par de ñapas y a ver si es posible publicarlo ya (no en Iris Manager, de momento, si no como PKG independiente, en fase de pruebas)

Sobre algunas cosas que habéis comentado:

- Los LEDs no se pueden manejar de cualquier manera: no puedo decirle que parpadee 5 veces de forma seguida, por que en el fondo, no se ni cuando responderá el sistema, ni cómo: depende de los usleeps que se encuentre y el tiempo mínimo de respuesta es de 1 segundo al menos y aparte hay otros problemas (como que no todo el mundo tiene los leds de colores, por ejemplo )

- Sobre como opera el SYSCON las temperaturas, parece que tiene un rango por encima y otro por debajo y que en realidad, le da un tiempo cuando fija la velocidad del ventilador, antes de volver a cambiar de velocidad: si en 74º cambia de velocidad, tendrá que ver si pasado un tiempo, la evolución sigue hacia arriba o no. Y lo que si es cierto, es que una vez que sube de velocidad, ya no la baja por que la temperatura haya bajado a un límite donde antes, con una velocidad menor, estaba bien: la mantiene no se si hasta que pasa una temperatura de corte hacia abajo o eso mas que haya pasado un determinado tiempo sin subir, o algo parecido.

No creo que funcione haciendo medias de temperatura, simplemente.

- Por otro lado, cada consola es un mundo, obviamente: si hay una consola que tiene unos niveles de temperatura completamente anormales, lógicamente, la solución no es simplemente, poner a tope el ventilador: algún problema habrá subyacente.

La idea es que dentro de lo posible, evitemos que por ser demasiados conservadores con el ruido que genere el ventilador, permitamos unos grados de más que pueden dar problema con el tiempo: si alguien ha cambiado el ventilador por uno más eficiente, la pasta térmica, etc, pues lógicamente, el payload funcionará con las menores relaciones de velocidad/ruido y bien para el. Ni idea de como irá en las Slim y supongo que mi consola, es de las FAT veteranas que están en buen estado, pues su temperaturas no son excesivas (nunca la he visto por encima de 75º) sin haberle hecho nada de nada.

Pero tampoco es lógico ajustar el payload para alguien que tiene un problema evidente de refrigeración por que ya de por si se le pone por las nubes: eso no lo va a solucionar la aplicación, ni fijar la velocidad muy alta a mano, ni poner un potenciómetro, ni dejar el ventilador al máximo (eso es como si tengo la pierna rota y pretendo curarla tomando medicación para soportar el dolor).

La idea cómo digo, es tener un control que sea más agresivo que el SYSCON, pero si un juego me pone la CPU o el RSX a 70º, no es lo mismo que si en condiciones normales ya está a 74-75º por que al SYSCON le parece bien o tener unos grados de más por que el ventilador va poco revolucionado, etc

si te interesa podrías comunicarte con el syscon directamente usando lv1 peek / poke , y sin usar ni una sola syscall... si quieres te hecho un cable con ello solamente es saber como se le mandan unos paquetillos , aunque quizás no funcione si el service que usa hypervisor necesita auth1 y auth2 se volvería mas peliagudo.. aunque veo que te lo has apañado genial usando llamadas :-D ere un crá

por cierto , he encontrado un posible fix ( lo que es dificil por que es via hardware ) de arreglar el problema sin controladora en iris manager con el ps3_payload y el montaje de bd , ahora no pega panic y monta pero ay que hacer un mod por hardware y facil no es ya que lo que hice fue convertir la señal ide a S-ATA y conectar un lector de pc xD veo que la historia reside en lv1 y estoy intentando fixearlo via software ya que ahora mas que nunca sé que solo detecta la presencia de "algo" en el puerto del lector... vamos toda una genialidad por parte de los engineers de ps3... xD

saludos

Si no consigues el fix via soft, lo podrias detallar mas a fondo via hardware, hay gente a la que le gusta entretenerse con estos injertos tipo frankstein ...

Saludos...

Pues el mod para la controladora de MLT me gusta, es solo hard o hay soft tambien.

Edito: ahora que repare el corto del ventilador en mi fat la tengo lista para probar de todo...

Habría que habilitar compatibilidad con 4.41 para Iris para quién quiera usarlo...

Estwald, si no es muy complejo, si quieres puedes explicarlo un poquejo y lo hacemos alguno de nosotros (quizá esté diciendo una gilipollez y si lo hago yo desencadene el apocalipsis en las consolas) pero si podemos ayudar... lo que sea!

EDITO: CFW 4.41.2 liberado de Rebug (solventa problemas que presentaba anteriormente) hilo_update-1-cfw-4-41-rebug-disponible-4-41-2_1893418

MrMento escribió:Habría que habilitar compatibilidad con 4.41 para Iris para quién quiera usarlo... hilo_cfw-4-41-rebug-disponible-4-41-1_1893418

Estwald, si no es muy complejo, si quieres puedes explicarlo un poquejo y lo hacemos alguno de nosotros (quizá esté diciendo una gilipollez y si lo hago yo desencadene el apocalipsis en las consolas) pero si podemos ayudar... lo que sea!

+1

please add support for cfw 4.41

Agrippa90 escribió:please add support for cfw 4.41

eL REBUG 4.41, no es funcional, no deja instalar pkg...

Saludos...

Mincho escribió:

Agrippa90 escribió:please add support for cfw 4.41

eL REBUG 4.41, no es funcional, no deja instalar pkg...

Saludos...

el problema se ha solucionado en Rebug 4.41.2

Saludos

Mincho escribió:

Agrippa90 escribió:please add support for cfw 4.41

eL REBUG 4.41, no es funcional, no deja instalar pkg...

Saludos...

Si que lo es, acaban de sacar una versión nueva que arregla el problema de los pkg.


Un saludo

PD: @LoboGuara jajaja los 2 a la vez, vaya vaya.

Sí, ya lo han solventado, he actualizado el hilo hilo_update-1-cfw-4-41-rebug-disponible-4-41-2_1893418 ya lo tenéis, CFW 4.41.2 funcional disponible de Rebug

Yeah the bug in rebug cfw 4.41.1 was only when it was installed on non qa'd ps3
So its not an issues for those that had qa flag

Anyways its fixed in 4.41.2

So hopefully there'll be an update for iris manager to support it

Thanks

Hola

Aviso a navegantes que yo estoy en 4.40 y no me pienso mover de ahí: lo que hagan los demás, es problema suyo


Por otro lado, Iris Manager es open source: si alguien ajusta los parches (por su cuenta) para 4.41 se añadirán sin problema, pero no debéis esperar que ese trabajo me toque siempre a mi, por que no.

Con la 4.40 ya pasó: Miralatijera lo adaptó, pero cometió dos fallos que me tocaron resolverlos a mí, provocando que subiera a 4.40 sin necesidad real y ahora, cuando apenas llevamos nada, ya está la gente con 4.41... pues por mi parte, eso no va a ser así, por que no me gusta cambiar de CFW cómo de calcetines y ya llevamos una racha... .

Por otro lado, el tema de la regulación del ventilador está siendo probado mientras juego (que ya me va tocando ), y de momento, parece que va bien: tuve algunos problemas debido al tiempo que consumen algunas funciones que generaban inestabilidad, pero parece que ya no da tanto problema el asunto.

Supongo que si no sufro contratiempos, mañana publicaré la herramienta en otro hilo, pero por el momento, no se va a incluir en Iris Manager. Los parches, por cierto, son para 4.31 y 4.40

Saludos

lol we have no backup manager for cfw 4.41

Agrippa90 escribió:lol we have no backup manager for cfw 4.41

Es lo que he dicho yo en el hilo, q en verdad no hace falta subir, de hecho yo en la slim sigo en 4.31 y en la Fat en 4.40...

Cualquiera puede hacerlo, de hecho yo si supiese lo haria... No se, paciencia, 4.41 realmente no aporta nada nuevo... Mismas keys public... Mismo todo...

I like CFW Rebug 4.41 ...... I do not want to have another cfw installed on my ps3 lol

always better to have an updated product

Disculpar pero tengo un problema al acceder al iris última versión con el hdd externo no me lee todos los juegos que hay dentro incluso cambio de dirección a Gamez y nada. Un saludo

gamez en mayusculas si no lo coje