Hola compañeros, un cordial saludo a todos y especialmente a mis amigos krampak, Cobito y todos los que me enseñaron mucho en su momento cuando no tenía ni idea de nada.
Paso el lío, desde hace tiempo ando liado con una aplicación o interfaz gráfica de código abierto GNU/ Xboard, con el objetivo de realizar retransmisiones en tiempo real. Básicamente la estructura era Xboard o Winboard ( windows) un cliente ( tlcs) tunel ( Wireguard) vps y node-tlcv que permitía mostrar en un visor web ( html) las partidas en tiempo real. Pero las limitaciones eran que no podía realizar torneos, sino sólo enfrentamientos entre dos motores. Esto sí que lo he conseguido, pero no es mi objetivo. Luego me he puesto a crear ( tenía el interfaz más moderno, pero lo perdí y los que lo usan no lo comparten) una aplicación más moderna con lo báisco para que se puedan realizar las retransmisiones en directo a tiempo real entre una lista de los 10 principales motores de ajedrez que están en las listas de rating más populares a nivel mundial. Pero desgraciadamente, no comparten el cómo hacerlo, y en algunos casos hay que pagar ( lo respeto, pero no lo comparto en este caso concreto que no es un software para comercializar y que antes era libre y lo sigue siendo en GNU, que se han aprovechado del sourcode de GNU para luego cerrar el código y realizar esos test). Bien pues como propuesta por todo lo que he aprendido aquí y que sigo aprendiendo, me gustaría inlcuir un Banner de Hardlitmit ( único, no pondré nada más) para que la gente que se conecte a ver los torneos puedan conocer nuestro foro.) Sin compromiso alguno y por mi agradecimiento y buenos recuerdos de este entrañable lugar y buena gente. https://github.com/jordiqui/IjccrlChessGui/tree/main ( aquí está el proyecto en la github, no está terminado, pero cuando lo esté y espero compilar hoy para probar, me gustaría añadir a hardlimit en un lugar relevante del visor web. Feliz fin de semana y feliz navidad a todos los miembros del foro, especialmente a mi amigo krampak ( vuelvo este año a la bici desde Guardamar del segura, Alicante para llegar a los 4 w/kg) y Cobito por su tremendo trabajo en este foro.

@manolo681 dijo en Ayuda servidorr hp prolian dl360 gen8:

Buenas tardes a ver si alguien me puede ayudar, tengo un servidor hp prolian dl360 gen8 tiene un raid 5 hace unos dias uno de los disco la luz se puso en ambar fijo , he cambiado ese ssd y la luz ahora esta en ambar fijo y otra luz verde rodeando la ambar ,haciendo circulos,asi lleva 11 dias , no tengo la ip del ilo para poder conectarme a el para ver el array , y no puedo reiniciarlo ni pararlo para ver la ip del ilo , SAbeis si hay alguna manera de averiguar la ip del ilo o accediendo directamente al servidor de ver la ip del ilo o ver el array para saber porque no acepta el ssd nuevo?

Sino me equivoco lo de la luz es porque uno de los drivers de la controladora de almacenamiento no es genuino de hp, porque así lo tengo yo y entiendo que es por ese motivo. Respecto a la Ip de la ilo, como es necesario tener licencia para trabajar con dicho software, lo mejor es preguntar en soporte de hpe con tu cuenta de usuario.

"El servidor está preconfigurado con una dirección IP estática predeterminada para acceder a iLO (192.168.0.120). El nombre de usuario y contraseña predeterminados de iLO se encuentran en la lengüeta en a la parte posterior del chasis. El nombre de usuario es Administrator y la contraseña es una cadena alfanumérica de ocho caracteres."
Desde HPE

Bueno ya tenemos el segundo hp proliant en casa. El mismo vendedor, los procesadores siguen siendo ivy Bridge y el resto cuando lo configure le pasamos unos test a esta nueva configuracion.

PD: Luego instalar windows server, cluster, etc Ah, no habia forma de poner la grafica que creo se medio vera en este chassis, no se porque el adaptador pci no me dejaba por el disipador de la tarjeta, instalarla, luego la pondre en el otro y tratare de averiguar porque se aceleran los ventiladores con la tarjeta y porque no sin ella instalada. Un abrazote.

Hola compañeros, tendremos otro equipo para añadir al banco de pruebas de Hardlimit y para tener uno dedicado al ajedrez. En rendimiento es inferior al 2680, pero viene equipado con lo siguiente:
Servidor proliant dl360p gen8 con la siguiente configuración:

-chasis 1U
-placa base con controladora raid
hp smart array p420 integrada.
-chasis de 8 discos sff, admite ssd, hdd y sas de 2,5.
-memoria caché 1gb fbwc.
-bateria de respaldo.
-8 ventiladores hot plug.
-1 psu 460w (2ª psu +30€)
-2 disipadores cpu
2 xeon e5-2660 v2, 20 cores, 2,2ghz.
módulo 8gb 1600mhz X8 64 Gb ram
El disco duro ssd y la grafica gt antigua de nvidia que compre se la pondre a este a ver sino hace tanto ruido, porque en el que tenemos ahora con la grafica puesta, a parte de no poder cerrar del todo el chasis, encima los ventiladores se quedan en modo high perfomance cuando esta configurado en la bios en optimal que sube con la carga del procesador y baja en idle. Bueno espero que sume al equipo de hardlimit en hwot.org que me he viciado con el portatil. Disculpad la ausencia de acentos, pero no hay forma humana de volver a configurar el idioma y mira que esta en español españa, etc. Un abrazo compañeros.

Felices fiestas a todos los compañeros del foro. Feliz vida!

Hola compañeros. He pasado el banco de pruebas con un Ryzen 7 8745HS y es la leche que en un formato como el que he escogido porque no hay para más, un mini pc, sea tan rápido comparado con mis trastos. Pero como necesitaba compilar en instrucciones modernas, motores de ajedrez, por petición de los usuarios, pues he cogido esta opción, por precio. Pero me sorprende como avanza el asunto. 4 nm y vuela, lógicamente no es para 24/7, pero me ha salvado el tema de los binarios. En fin, como siempre es un placer y ya tenéis otro procesador más en el historial, porque he visto que no había datos de uno igual. Un saludo.

@defaultuser En este caso concreto el archivo de texelcl.exe esta creado para que los motores de ajedez UCI usen el cluster, vamos todos los nodos o cpu. Pero quitando texel, puedes configurar un servidor de red, fallo pues al fallar el primero, seguirian con las tareas el segundo, etc. No me he querido meter mas, porque es todo un mundo. Pero os lo he reducido lo maximo posible. Un abrazote.

Hola amigos, hace tiempo que no escribo nada que sea por decirlo de alguna manera, tecnico. La cuestion es que tenia en la cabeza crear un cluster ( hay de diversos tipos y para diversas funciones) para aprovechar el hardware de ambos servidores que como el titulo indica, son practicamente iguales. Conditio sine qua non para que el cluster funcione. Os lo voy a resumir muy brevemente, pues asi me lo explicaron ( quien me ayudo, le costo un año montar con sus Epyc, lo que he creado con los HP) y como el conocimiento no es de nadie sino de todos paso a la explicacion lo mas resumida posible.
En primer lugar, disponer de dos servidores con hardware similar o igual. Disponer de alguna version certificada de windows server ( se puede hacer con linux) en este caso el server datacenter 2022 y también windows 10 pro a ser posible para workstation. Instalacion limpia en ambos servidores del sistema operativo.
Configuracion del servidor:
https://docs.microsoft.com/es-es/windows-server/failover-clustering/whats-new-in-failover-clustering
( indispensable seguir estos pasos que indica microsoft)

1. El nodo maestro será, por ejemplo HOST1, y el resto de nodos host2,3,4,5 etc.
2. En todos los nodos, la cuenta y la contraseña debe ser la misma.
3. Para windows, instalar MPI
4. Asegurarnos de que en todos los nodos se ejecuta el proceso smpd.
5. Asegurarnos de que en las reglas del firewall nuestras aplicaciones, mpi, rpc, etc tienen acceso ( tanto de entrada como de salida).
6. Intentar abrir los puertos tcp udp necesarios para un cluster. ( esto para microsoft aquí.
   con esto podemos si se ha configurado todo bien usar aplicaciones que admitan cluster en procesamiento en paralelo. Luego el siguiente clúster es para buscar la redundancia, si falla uno que siga el otro. ( a medida que me enseñen más os lo añado aquí, aunque sé que muchos de vosotros esto lo tenéis más que conocido)
   Aplicación trabajando con 88 procesos:
   

Crear un clúster de conmutación por error en ambos equipos ( esto se hace desde la consola del servidor)
Implementación de un servidor de archivos en clúster de dos nodos.
Configuración de cuentas de clúster en Active Directory )
Esencial lo es todo. Pero os lo describo tal como lo he creado y como funciona para que reconozca los dos nodos, es decir, 20x2 cores+ 40x2 threads.
Validar la configuracion del cluster.

Configurar y administrar el cuórum
instalar Microsoft MPI y añadir permiso tanto de esto ultimo como de snmp en el firewall.
una vez hecho todo esto. tenemos que hacer los siguiente:
descargar texel del github, la ultima version e instarlarla en el directorio c, por ejemplo.

https://github.com/B4dT0bi/texel/releases

y haced lo siguiente con la consola de windows en modo administrador:
ejecutar en ambos servidores el siguiente comando:
smpd -d 0

Abrid otra consola como administrador y ejecutar el siguiente comando para buscar el directorio donde se ha instalado texel:
cd ‪C:\texel107\texel64cl.exe
y luego el siguiente comando:
piexec -hosts 2 host1 host2 texel64cl.exe

como resultado deberia aparecer lo que veis en la siguiente captura de pantalla:

os dejo en ingles si esto ultimo lo haceis con linux:
The pre-compiled windows executable texel64cl.exe is compiled and linked
against MS-MPI version 8.1. It requires the MS-MPI redistributable package
to be installed and configured on all computers in the cluster.

Running on a cluster is an advanced functionality and probably requires
some knowledge of cluster systems to set up.

Texel uses a so called hybrid MPI design. This means that it uses a single
MPI process per computer. On each computer it uses threads and shared
memory, and optionally NUMA awareness.

After texel has been started, use the "Threads" UCI option to control the
total number of search threads to use. Texel automatically decides how
many threads to use for each computer, and can also handle the case where
different computers have different number of CPUs and cores.

• Example using MPICH and linux:

If there are 4 linux computers called host1, host2, host3, host4 and MPICH
is installed on all computers, start Texel like this:

mpiexec -hosts host1,host2,host3,host4 /path/to/texel

Note that /path/to/texel must be valid for all computers in the cluster,
so either install texel on all computers or install it on a network disk
that is mounted on all computers.

Note that it must be possible to ssh from host1 to the other hosts without
specifying a password. Use for example ssh-agent and ssh-add to achieve
this.

Despues de todo esto, las posibilidades son realmente diversas, pues puedes usar un equipo como apoyo por si falla el primario, etc.

OJo, esto lo he montado para usar programas de ajedrez adaptados a cluster. Las aplicaciones, como todas, al igual que el hardware, no siempre funcionan con estas configuraciones. La cuestion es que lo hemos logrado en tiempo record, con ayuda. Y por eso os lo dejo por aqui, ya que he visto que buscando cluster, aparecia en el apartado de software.
Un abrazo compañeros.

IjccrlChessGui es un marco abierto y moderno para torneos de motores + canal de retransmisión en directo inspirado en el concepto histórico «ChessGUI»:
ejecutar partidas de motores localmente y retransmitirlas en tiempo real a un sitio web.

El objetivo final es ofrecer una alternativa práctica, reproducible y de código abierto a las pilas de retransmisión cerradas «estilo ChessGUI» que utilizan las principales ligas de motores, pero adaptada al ecosistema IJCCRL (pruebas, listas de clasificación y eventos en directo).

( Breve descripción del proyecto de código abierto. Dejo el Hilo como centro de operaciones de la aplicación: https://github.com/jordiqui/IjccrlChessGui )

Hola compañeros,
al final y viendo los precios que hay hoy en día, he desistido de comprar un pc y hemos añadido otro nodo más a los dos anteriores con la siguiente configuración final, pues no caben más en el armario.

• Hp proliant dl360p gen 8 2x e5 2697v2 24C 48T

• Hp proliant dl360p gen 8 2x e5 2603v2 24C 48T

• Hp proliant dl360p gen 8 2X e5 2680v2 20C 40T

Luego en aplicaciones que usen el mpi de microsoft nos encontramos con un total de 68 Cores físicos disponiblkes 136 Threads.
PD: aprovecho para comentar a @cobito la posiblidad de añadir código a la app del banco de pruebas que admita la interfaz de paso de microsoft.

Un abrazo compañeros

@krampak said:

@jordiqui Es raro porque esos servidores enracables son estándard (sólo varia si ocupan 1U o 2U) y siempre van montados en los racks de 19 pulgadas de ancho, lo que sí puede variar es la profundidad y guías, en función de si son LFF o SFF. No se exáctamente qué te vendieron.

Y así es, @krampak me reconocieron el error, pero en aquel momento me empeñé en intentar hacer que funcionara y claro, ya no podía devolverlo. Pero sí, me enviarón el correo con el armario correspondiente compatible, porque como bien dices son 1u o 2u. Pero es pasado, y me lo ha recordado esta imagen el otro día. Ahora, me quité de encima dos y me he quedado con el en mejor condiciones estaba. Un abrazo mi querido amigo.

@cobito said:

@jordiqui Veo que le das mucha importancia a la RAM pero el Ryzen 9 9950X3D tiene 128MB de caché de nivel 3 y 1MB de nivel 2. No sé cuanto consume SuperPi 32M, pero si se sale de los 128MB no será por demasiado. ¿De verdad afecta tanto la RAM? Y si afecta, al ser por cantidades pequeñas y un proceso intensivo de CPU, ¿no sería conveniente apretar las latencias más que la frecuencia? Es más, ¿no sería interesante probar a hacer underclocking a la memora con tal de mejorar las latencias?

Te lo comento porque yo estoy en el extremo contrario con los LLM con consumos enormes de RAM donde el ancho de banda es el cuello de botella predominante y donde tener mucha caché ayuda en cierta medida. Si por mi fuera, sacrificaría las latencias por ancho de banda porque sé que el aumento de rendimiento va a ser prácticamente lineal con cada MT/s que raspe.

Coincido contigo con el ancho de banda, estuve indagando con esta configuración diferentes test, luego viendo el conjunto le pregunté a gpt una recreación de este escenario.

Controlled Super Pi Overclocking Plan

AMD Ryzen 9 9950X3D / ASUS ROG Crosshair X870E Extreme / DDR5 96 GB 5600 CL40
0. Platform Characterisation

The tested system is a high-end AM5 platform built around:

• CPU: AMD Ryzen 9 9950X3D
• Motherboard: ASUS ROG Crosshair X870E Extreme
• Memory: Corsair Vengeance DDR5 5600 MT/s 96 GB, 2 x 48 GB, CL40
• GPU: ASUS TUF Gaming GeForce RTX 5090 OC 32 GB
• PSU: Corsair HX1500i ATX 3.1 / PCIe 5.1, 1500 W, 80 Plus Platinum
• Storage: WD Black SN8100 4 TB PCIe 5.0 NVMe
• Case: HYTE Y70 Touch Infinite
• Cooling: custom hard-tube liquid cooling
• OS: Windows 11 Pro

The Ryzen 9 9950X3D is a 16-core / 32-thread processor with a 4.3 GHz base clock, up to 5.7 GHz boost clock, 128 MB L3 cache, 170 W default TDP, unlocked overclocking support, AMD EXPO support, Precision Boost Overdrive support and Curve Optimizer support. These points are important because Super Pi optimisation should not start with a fixed all-core manual overclock; it should start by preserving and improving effective single-thread boost behaviour.

The ASUS ROG Crosshair X870E Extreme is an appropriate motherboard for this kind of controlled work. ASUS lists it as a flagship AM5 board for Ryzen 9000 processors, with DDR5 support, PCIe 5.0 support, USB4, extensive cooling control, EXPO/AEMP memory tuning support and a high-end VRM design with 20+2+2 power stages.

Super Pi is a Windows benchmark that calculates pi up to 32 million digits and has historically been used in the overclocking community as a benchmark and stability indicator. It is not GPU-bound; therefore, the RTX 5090 should be left at stock for this test path.

1. Benchmark Objective

The target is not general gaming performance. The target is the best reproducible Super Pi result.

Super Pi performance is mainly controlled by:

• 1. Effective single-thread CPU frequency
• 2. Memory latency
• 3. Cache and interconnect behaviour
• 4. Windows scheduling noise
• 5. Thermal stability
• 6. Run-to-run consistency

For this platform, the RTX 5090 is not a performance variable for Super Pi. It can only become a negative variable if GPU heat is dumped into the same liquid loop and increases coolant temperature.

2. Important Limitation: The Installed RAM Kit

The installed memory is:

• DDR5 5600 MT/s
• 96 GB total
• 2 x 48 GB
• CL40

This is a capacity-oriented workstation/gaming kit, not a naturally aggressive Super Pi kit.

Theoretical first-word CAS latency:

DDR5-5600 effective clock = 2800 MHz
CL40 latency = 40 / 2800 MHz = 14.29 ns

That does not mean the kit is bad. It means that for Super Pi 32M, the memory subsystem will probably be the limiting area after CPU boost is optimised.

The correct approach is not to invent DDR5-6400 or DDR5-6600 targets. The correct approach is:

• Step 1: Validate stock 5600 CL40.
• Step 2: Try tighter timings at 5600.
• Step 3: Try moderate frequency increases only if the IMC remains stable.
• Step 4: Compare Super Pi 32M loop consistency, not only boot stability.
• 3. Safety Principle

This should be treated as a controlled benchmark configuration, not a daily-use blind overclock.

Rules:

• Do not change CPU, memory, SoC voltage and timings simultaneously.
• Do not start with manual all-core overclocking.
• Do not use aggressive BCLK changes at the beginning.
• Do not overclock the RTX 5090 for Super Pi.
• Do not judge stability from Super Pi 1M only.
• Do not keep a setting if the score improves once but becomes inconsistent.

The Ryzen 9 9950X3D already has high boost behaviour. A fixed all-core clock can easily reduce the best single-thread boost path. For Super Pi, effective peak core behaviour is usually more important than a visually impressive all-core number.

• Stage A — Evidence Baseline
• Step A1 — BIOS Reset and Documentation

Start from BIOS optimised defaults.

Record:

BIOS version:
AGESA version:
CPU temperature at idle:
Coolant temperature, if sensor exists:
Room temperature:
RAM profile:
VDD:
VDDQ:
SoC voltage:
FCLK:
UCLK:
MCLK:
Windows build:
AMD chipset driver version:
Why

Without this baseline, later improvement cannot be attributed to any specific change.

Step A2 — Stock Super Pi Baseline

Run:

• Super Pi 1M: 5 runs
• Super Pi 32M: 3 runs

Record:

Best time:
Median time:
Worst time:
Loop consistency:
Effective CPU clock:
Peak temperature:
Background processes:
Why

Super Pi is sensitive to scheduler noise. The best run alone is not enough. The median run matters because it shows whether the platform is actually stable and repeatable.

Stage B — Operating System Isolation
Step B1 — Windows Benchmark Profile

Create a clean Windows benchmark profile:

Disable unnecessary startup applications.
Disconnect non-essential background software.
Pause Windows Update.
Close RGB control suites during the run if they poll sensors heavily.
Disable overlays.
Disable browser, launchers and cloud sync.
Use a fixed power plan.
Keep the benchmark on local NVMe storage.
Why

Super Pi is a light single-thread workload. Background polling can affect the final result disproportionately.

Step B2 — Core Affinity Testing

Do not assume the best core. Test it.

Procedure:

1. Use CPU-Z / HWiNFO / Ryzen Master to identify preferred cores.
2. Run Super Pi 1M pinned to each candidate preferred core.
3. Repeat each candidate core at least three times.
4. Select the core with the best repeatable median, not only the best one-off run.
   Why

The 9950X3D is a dual-chiplet CPU. Super Pi may prefer the highest effective frequency path rather than the largest cache path. This must be measured, not assumed.

Stage C — CPU Boost Optimisation
Step C1 — Preserve Automatic Boost First

Initial CPU strategy:

• Manual all-core overclock: OFF
• PBO: enabled/advanced only after baseline
• Boost override: initially 0
• Scalar: conservative / Auto
• Thermal limit: documented, not guessed
• Curve Optimizer: disabled for first baseline
  Why

The 9950X3D supports Precision Boost Overdrive and Curve Optimizer. The goal is to improve the existing boost algorithm, not immediately replace it with a fixed manual clock.

Step C2 — Curve Optimizer Method

Use Curve Optimizer incrementally.

Recommended forensic sequence:

• Run 1: Stock / Auto
• Run 2: PBO enabled, no CO
• Run 3: CO negative, very mild all-core offset
• Run 4: CO per-core only after identifying preferred Super Pi core
• Run 5: Tune only the selected benchmark core more aggressively

Do not publish a fixed universal value such as “CO -30” as if it were guaranteed. It is silicon-dependent.

Why

Negative Curve Optimizer can reduce voltage demand and allow higher effective boost, but too much negative offset creates calculation errors, WHEA errors or silent instability. Super Pi 32M is useful here because it exposes marginal instability better than a single short 1M run.

Step C3 — Boost Override

Only after Curve Optimizer is stable:

• Increase boost override in small steps.
• Run Super Pi 1M after each step.
• Run Super Pi 32M after any promising step.
• Monitor effective clock, not only configured clock.
  Why

A configured boost increase is meaningless if effective clock does not rise or if thermal/power limits reduce sustained behaviour.

• Stage D — Memory Optimisation
• Step D1 — Validate DDR5-5600 CL40 First

Before tuning, validate the stock memory profile.

Minimum validation:

• Super Pi 32M: clean pass
• Memory test: clean pass
• No WHEA errors
• No retraining failures
• No cold-boot instability
  Why

The installed kit is 2 x 48 GB. High-capacity DDR5 can be more demanding on the memory controller than smaller benchmark-oriented kits.

Step D2 — Tighten Timings Before Chasing Frequency

First tuning direction:

• Keep DDR5-5600.
• Reduce primary timings carefully.
• Validate each change.
• Record Super Pi 32M loop times.

Suggested tuning order:

• 1. Command rate / memory context behaviour
• 2. CAS latency
• 3. tRCD / tRP
• 4. tRAS
• 5. tRFC
• 6. Secondary timings
• 7. Tertiary timings
     Why

For Super Pi 32M, latency can matter more than raw bandwidth. A lower-frequency profile with tighter timings may outperform a higher-frequency profile with loose timings.

Step D3 — Frequency Scaling

Only after timing work at 5600:

Try the next memory ratio.
Keep timings loose enough to boot.
Validate.
Then tighten again.

Possible test matrix:

• Profile 1: 5600 CL40 stock
• Profile 2: 5600 tightened
• Profile 3: moderate higher-frequency loose
• Profile 4: moderate higher-frequency tightened
  Why

This avoids the common mistake of comparing two variables at once. If frequency and timings both change, the result cannot be interpreted cleanly.

Stage E — FCLK / UCLK / MCLK Control

For each memory profile, record:

• MCLK
• UCLK
• FCLK
• UCLK:MCLK ratio
• Memory training result
• Boot reliability
• Super Pi 32M loop variance
  Why

On AM5, memory performance is not only DDR5 frequency. The relationship between memory clock, memory controller clock and fabric behaviour can change real latency. Super Pi 32M is sensitive to that relationship.

• Stage F — Thermal Control
• Step F1 — Liquid Loop Stabilisation

Before each serious run:

• Allow coolant temperature to stabilise.
• Record room temperature.
• Record coolant temperature if available.
• Run the same warm-up procedure.
• Start Super Pi from the same thermal condition.
  Why

A custom hard-tube loop gives strong thermal capacity, but if the GPU and CPU are in the same loop, residual GPU heat can pollute CPU benchmark results. For Super Pi, the GPU should be idle.

Step F2 — Fan and Pump Policy

Use fixed fan and pump settings during benchmark runs.

Pump: fixed high-performance setting
Radiator fans: fixed RPM or fixed curve
Case fans: fixed profile
GPU: stock / idle
Why

Changing fan curves during a run can change coolant temperature and introduce run-to-run variation.

Stage G — Final Benchmark Profiles

Use three final profiles.

• Profile 1 — Reference Stock
• BIOS defaults
• EXPO/XMP as delivered
• No PBO tuning
• No CO tuning
• No manual memory tuning

Purpose:

• Official baseline.
• Profile 2 — Safe Daily Optimised
• PBO tuned conservatively
• Curve Optimizer validated
• Memory stable and modestly tightened
• No aggressive voltage
• No BCLK tuning
• No GPU overclock

Purpose:

• Best practical configuration without sacrificing reliability.
• Profile 3 — Benchmark-Only Super Pi Profile
• Pinned best core
• Clean Windows session
• Aggressive but validated Curve Optimizer
• Best validated memory timing profile
• Fixed cooling behaviour
• Documented ambient/coolant temperature

Purpose:

Best Super Pi result under controlled conditions.
Required Evidence for Forum Publication

Final result should include:

• CPU-Z CPU tab
• CPU-Z Mainboard tab
• CPU-Z Memory tab
• ZenTimings screenshot
• HWiNFO effective clock screenshot
• Super Pi final screenshot
• Ambient temperature
• Coolant temperature if available
• BIOS version
• Windows build
• AMD chipset driver version
• Exact BIOS settings changed
• Number of runs
• Best / median / worst time
• Engineering Interpretation

This platform is extremely strong, but for Super Pi the limiting factors are not the same as for gaming.

The strengths are:

• High single-thread boost potential
• Excellent motherboard for AM5 tuning
• Strong PSU headroom
• Strong cooling potential
• Fast NVMe storage

The main limitation for Super Pi is likely:

DDR5 5600 CL40 96 GB memory latency

That RAM configuration is excellent for heavy multitasking, content creation and workstation usage, but it is not an obvious Super Pi 32M-optimised memory profile. Therefore, the highest-impact controlled work after CPU boost tuning will probably be memory timing optimisation.

Final Rule

No result should be considered valid unless it is:

• Repeatable
• Screenshot-documented
• Thermally documented
• Free of WHEA errors
• Stable in Super Pi 32M
• Compared against a clean stock baseline

I'm looking at this now after doing my research—and I wouldn't have bought it without doing so—and I'm furious at what a well-known online store did. Even though I provided all the details—model, rack size, etc.—they sent me something that was only good for placing those two servers on top of, not for mounting them in a rack... etc...

Hola compañeros, tengo ya un plan muy definido para crear un programa de ajedrez original híbrido ( estilo stockfish) que combina una evaluación clásica y el uso de redes neuronales. Uno de los principales problemas es poder generar una nnue moderna para el motor de ajedrez, puesto que requiere de gpu profesionales. El Proyecto hacía tiempo que lo tenía aparcado en la github, https://github.com/jordiqui/SirioC.
Mi propuesta, si os parece bien, os invito a todos los usuarios que conozco desde hace ya décadas a sumarse como autores, colaboradores, y lanzar el motor en los torneos oficiales. Os adjunto el plan de trabajo que tengoAuditoría forense y hoja de ruta para adaptar SirioC hacia una fuerza tipo Reckless sin comprometer (1).pdf que junto a la github se puede descargar el sourcode. Desde mi lado, que tengo tiempo, voy avanzando, pero lo que no tengo es una gpu para entrenar y o generar las redes. Imprescindible para que el motor sea eficiente y obtenga un buen rendimiento. De momento, la licencia es MIT. Si podéis ojear y alguien le apetece entrar en el proyecto, será más que bien recibido. Como siempre, espero vuestras sugerencias y lo dicho, prefiero tener el centro de operaciones aquí con vosotros, pues como ya dije con la app broadcast, todo lo que he aprendido ha sido aquí. Ya me irés diciendo, y de paso añado cuando me deis permiso enlace al foro desde la github, etc.

@cobito said:

Buenas @jordiqui. Lo más sencillo sería ponerlo sobre un fondo de color plano, que en este caso sería el fondo negro del chat. Como lo tienes ahora no queda del todo mal, pero los colores corporativos no dejan mucho contraste con fondos oscuros.

Aquí te dejo una propuesta de logo adaptado a fondos oscuros (esquema similar al programa del banco de pruebas) en que el he aumentado un poco el tamaño dentro del chat:

@cobito HECHO!. ya lo tenemos en los dos torneos visible. !. https://elite.ijccrl.com/ 2. https://ijccrl-live.ijccrl.com/

Hola @cobito, sobre esto: ¿lo quieres poner sobre el fondo negro del chat o justo sobre el chat, cuyo fondo podría ser una textura o un color sólido dependiendo del tamaño de la ventana? la primera opción. Desde el movil lo he visto mejor, pero como dices no encaja bien, luego la cuestion es que por jerarquía visual quede homogéneo y visible para los usuarios. En cuanto lo tengas me lo pasas y yo lo añado a la carpeta Asset y lo vinculo en el código html. Así puedo añadirlo a las otras dos url que tengo activas, este mes tengo un vps para ir posicionando poco a poco con el seo las retransmisiones. Un saludo.

@cobito said:

Buenas @jordiqui. No, con ese fondo no va a encajar.

Un par de cosillas: veo que el fondo cambia en función del tamaño de la ventana: unas veces es una imagen (ventana grande) y otras un color plano (ventana pequeña) donde además desaparece parte del tablero de la izquierda:

La versión móvil veo que no funciona bien: pasan cosas raras con los tamaño de los tableros.

Y si la ventana es muy grande (en mi caso ventana maximizada a 4K con escalado del 150%), los dos tableros de la derecha, se superponen y se cortan:

Desde el punto vista del logo, importa el fondo: ¿lo quieres poner sobre el fondo negro del chat o justo sobre el chat, cuyo fondo podría ser una textura o un color sólido dependiendo del tamaño de la ventana?

Esta captura de pantalla es porque había varias autoridades y fósiles en el código. Se hizo saneamiento, y ya no carga un paint con otro color, Y he vuelto a mirar ahora desde el movil ( android, no he podido verificar safari de apple) y se adapta bien, aunque hay que hacer mucho scrolling porque no es una versión específica para móvil, sino que hacemos que se adapte el index.html. He puesto el logo, pero tengo que mejorar la visibilidad de la imagen porque es muy oscuro y el chat es negro el fondo.

Hola, creo que ahora debería funcionar bien la versión móvil. Revisé el código y se fijo una sola autoridad para mobile y desde el chrome de Android se ve bien. Respecto al logo, tenemos las dos url fijas y viendo el tráfico actual tras varias semanas con cinco reglas aplicadas en cloudfare, no hay ruido y estamos en un promedio de 1,2k diarios. Creo que es hora de buscar poner y que se vea bien el logo del hardlimit. 1. https://ijccrl-live.ijccrl.com/ 2. https://elite.ijccrl.com/ porque merece la pena y no pienso nada más que en hardlimit. Lo que no tengo claro es de ponerlo en la cabecera del chat, o como un widget lateral en la parte irzquierda. Pero lo del widget no me convence porque habría que retocar la geometría actual 2x2+1 y empezaría a pelearme con el gpt, porque no tengo herramientas de edición visual de html a mi alcance.