Ir al contenido

Buscar en La Comunidad

Mostrando resultados por etiquetas 'rendimiento'.

  • Buscar Por Etiquetas

    Añade etiquetas separadas por comas.
  • Buscar Por Autor

Tipo de Contenido


Foros

  • Contacto con el staff
    • Novedades / Anuncios del foro
    • Sugerencias
    • Problemas relacionados con el foro
  • Zona general de charla
    • Presentaciones
    • Charla
    • Zona de Humor, Curiosidades y Otros
    • Mascotas Vagos
    • Noticias del Mundo
    • Tecnología
    • Ayuda y consultas de carácter general
  • Zona GNU/Linux
    • Ayuda, consultas y soporte GNU/Linux
    • Distribuciones GNU/Linux
    • Repositorios. Software GNU/Linux
    • Personalización
    • Raspberry Pi
    • Arduino
    • Manuales / Tutoriales / Guías GNU/Linux
    • Programación
    • Noticias GNU/Linux
    • Hablando de GNU/Linux
  • Zona Gaming
    • Juegos GNU/Linux
    • Noticias Gamer
    • Charla Gamer
  • Zona Móvil
    • Ayuda y soporte para dispositivos móviles
    • Apps Móviles
    • Manuales / Tutoriales / Guías Móviles
    • Roms para dispositivos Móviles
    • Noticias sobre dispositivos Móviles
    • Hablando sobre dispositivos Móviles
  • Zona Mozilla
    • Ayuda, consultas y soporte Mozilla
    • Aplicaciones Mozilla
    • Roms Firefox OS
    • Manuales / Tutoriales / Guías Mozilla
    • Noticias Mozilla
    • Hablando de Mozilla
  • Microsoft
    • Papelera del Foro

Encontrar resultados en...

Encontrar resutados que...


Fecha de Creación

  • Start

    Fin


Última Actualización

  • Start

    Fin


Filtrar por numero de...

Joined

  • Start

    Fin


Grupo


Página Web


Diaspora


Pump


GNU Social


Google +


Twitter


Facebook


Xmpp


Skype


Steam


Desura


MediaGoblin


Youtube


Vimeo


Picasa


Flickr


Email


Lugar


Intereses

Encontramos 15 resultados

  1. Apt-build nos brinda la oportunidad de compilar los paquetes de los repositorios para ajustarlos a las especificaciones de nuestro sistema y, de esa manera, aumentar el rendimiento. Permite compilar cada paquete manteniendo las reglas y dependencias del sistema. Al hacerlo no vamos a perder la habilidad de administrar el programa a través de apt, ya que el propio apt-build se encarga de crear el paquete .deb para luego instalarlo como si se tratara de un paquete descargado directamente desde repositorios. La desventaja es que hay que perder tiempo compilando y seguramente instalar multitud de dependencias para poder llevarlo a cabo dicho proceso. Por no hablar de tener que repetir todo cada vez que sea actualizado el paquete. Lo primero que debemos hacer es asegurarnos de que tenemos los repositorios "source" (deb-src) En el caso de Debian podemos consultarlos en Debian Source list generator En ambos casos es tan simple como añadir deb-src delante de la dirección del repositorio en lugar del típico deb (El repositorio debe contener las fuentes, de lo contrario no funcionará aunque añadamos la línea deb-src) Ambas direcciones son idénticas, sólo cambia la cabecera de la línea Instalar y configurar apt-build: aptitude install apt-build[Mientras se instala nos preguntará qué nivel de optimización nos interesa: El nivel agresivo no es muy recomendado porque puede dar algunos problemas. El nivel escaso, personalmente no lo aconsejo ¿Que gracia tiene hacer toda esta locura para obtener un rendimiento "escaso"? Esto deja como nivel recomendado, el nivel medio Lo siguiente que pregunta es el modelo de procesador que tenemos en el equipo, de esto depende el resultado de la optimización. En caso de duda, podemos ver toda la información de nuestra cpu con el comando: lscpu Proceso de compilado [Apt-build tiene un funcionamiento muy similar a apt-get o aptitude Lo primero es actualizar la lista de sources: apt-build updatePara compilar e instalar un paquete Para compilar e instalar un paquete que ya está instalado Para eliminar un paquete Limpiar después de compilar/instalar apt-build clean-sources; apt-build clean-buildEl resto de opciones pueden consultarse con el habitual apt-build --help Compilar código fuente ajeno a los repositorios Para paquetes que provengan de repositorios, para compilar el código fuente de algún programa que descarguemos y vayamos a compilar también nos puede servir de ayuda. Suele ocurrir que aparece una nueva versión de determinado programa, y no hay ningún paquete .deb y los repositorios sólo ofrecen versiones antiguas de ese programa, por lo que no tenemos más remedio que descargar el código fuente y compilarlo por nuestra cuenta. A la hora de compilar siempre nos encontramos con que son necesarias multitud de dependencias previas y es algo que molesta, y mucho. Eso se puede solucionar con un: De esta manera se descargarán e instalarán todas las dependencias necesarias para poder compilar ese programa/paquete en concreto. Una vez instaladas ya podremos proceder a compilarlo manualmente teniendo instalado todo lo necesario para que se complete el proceso. (No es necesario el apt-build para hacer esto último) (Tampoco es necesario aptitude build-dep para paquetes que compilemos con apt-build) Apt-build world Llega la parte peliaguda. El apt-build con el parámetro "world" lo que hace es compilar absolutamente todo lo que hay en el sistema. Este proceso es sólo para los más osados, porque no ofrece garantías de que todo funcione correctamente una vez termine y, encima, tardará una barbaridad en compilar todo el sistema. Si termina y todo sale bien, mejorará el rendimiento notablemente y con el apt-build podremos administrar las actualizaciones y paquetes que vayan surgiendo sin tener que volver a empezar, pero si no sale, habremos perdido unas cuantas horas compilando y las que nos quedarán para arreglarlo Vale, ahora que ya los he asustado, empecemos con el proceso Antes de ejecutar el apt-build world hay que tener en cuenta una cosa, y es que no se deben compilar los mismos paquetes que se utilizan para compilar (suena redundante pero es así), por lo que debemos excluirlos para que no haya problemas. Creamos una lista de los paquetes que tenemos instalados para que la lea apt-build dpkg --get-selections | awk '{if ($2 == "install") print $1}' > /etc/apt/apt-build.listUna vez termine debemos acceder al archivo y eliminar los paquetes que no queremos que se compilen: nano /etc/apt/apt-build.listLos paquetes que tenemos que eliminar de la lista son los siguientes: Cuando nos hayamos asegurado de que hemos excluido esos paquetes del proceso, ejecutamos el comando: apt-build worldAunque algunos no lo tengan en cuenta, lo siguiente es muy importante, y es que si no le pones unas velitas a San Ignucio, y le rezas a San Torvalds, tienes muchas menos posibilidades que que el proceso se complete satisfactoriamente Después de varias Horas/Días compilando verás como te tomas la última recomendación mucho más en serio
  2. Por casualidad, visitando rm-rf me he topado con Netdata, un demonio de monitorización del sistema, pensado principalmente para la administración de servidores, muy interesante, tanto para su propósito original como para hacer uso de él en equipos más "hogareños". Se trata de un demonio ligero, muy optimizado, que nos permite controlar en tiempo real la carga de la CPU, interrupciones, uso de Ram, swap, lectura y escritura en disco, procesos, dispositivos de red... y en definitiva todos los aspectos de nuestro sistema de manera muy visual y detallada. La información la podemos leer directamente desde cualquier navegador web, con lo que las dependencias necesarias para utilizar Netdata son prácticamente inexistentes, bastan un par de segundos para instalarlo y listo. Sin configuraciones tediosas ni nada más allá de lo que ya tenemos de serie en nuestro sistema. Arch Linux El paquete está en repositorios oficiales, así que bastará un poco de pacman pacman -Syu netdata Debian Ya dije que en lo referente a dependencias no necesitamos nada, pero como nos valdremos del script de instalación oficial, nos harán falta las herramientas típicas para poder compilarlo aptitude install build-essential zlib1g-dev gcc make git autoconf autogen automake pkg-config CentOS/Fedora/Red Hat Ya dije que en lo referente a dependencias no necesitamos nada, pero como nos valdremos del script de instalación oficial, nos harán falta las herramientas típicas para poder compilarlo yum install zlib-devel gcc make git autoconf autogen automake pkgconfig psmisc Instalación Nos bastará con descargar el código fuente desde su repositorio en github y ejecutar el script de instalación: git clone https://github.com/firehol/netdata.git cd netdata chmod +x netdata-installer.sh ./netdata-installer.sh El proceso no llevará más que unos pocos segundos y tendremos el demonio instalado USO Al terminar, el instalador nos dirá que netdata estará escuchando en el puerto 19999 y nos bastará con acceder desde cualquier navegador a la dirección http://localhost:19999/ para empezar a utilizar la aplicación de monitorización. En caso de querer iniciar el demonio manualmente, el ejecutable se encontrará por defecto en /usr/sbin/netdata Ahora sólo nos queda ir navegando entre los distintos apartados, desplazando y ampliando secciones de las gráficas para poder apreciarlas mejor y recopilando toda la información de nuestro sistema y su rendimiento con sólo un par de clicks http://netdata.firehol.org/
  3. Hace tiempo hice algo parecido, pero no tan exhaustivo, ya que por aquel entonces el panorama no se acercaba ni remotamente a lo que tenemos ahora e lo que se refiere a rendimiento gráfico y videojuegos. El propio Martin Gräßlin ya propuso un sistema para mover las aplicaciones que demandan un alto rendimiento gráfico fuera del servidor gráfico donde se encuentra corriendo el entorno de escritorio para evitar la sobrecarga y el consumo extra de recursos que supone tener corriendo un escritorio debajo de la aplicación que estamos ejecutando. Especialmente si se trata de un videojuego a pantalla completa. Interactuando directamente con libuniput y el servidor gráfico, sin compositores u otros intermediarios del entorno de escritorio, mejoraríamos, en teoría, el rendimiento y evitaríamos una serie de problemas típicos de los compositores y gestores de ventanas. Nvidia, por su parte, ha ido aún más allá y ya tienen un sistema que permite, gracias a EGL, renderizar contenido gráfico OpenGL (y suponemos que Vulkan también) no sólo sin entorno, sino prescindiendo también del entorno gráfico. Esto abre un mundo de posibilidades y podría ser la clave para la futura migración de X11 a Wayland, además de suponer un antes y un después para grandes servidores y granjas de equipos que se utilizan para renderizar gran cantidad de datos 3D. Aunque en nuestro caso no vamos tan lejos, sí que resulta un tema muy interesante de cara al día a día. Es lógico que el entorno gráfico tenga cierto impacto en el rendimiento, no es ninguna novedad, especialmente ahora que muchos exigen sí o sí contar con aceleración gráfica únicamente para mostrar las ventanas. Las preguntas que nos haríamos en este punto serían ¿Cuánto?¿Qué diferencia existe entre los diferentes entornos disponibles? Pero sobre todo ¿Prescindir de entorno gráfico es realmente una opción que realmente compensa a la hora de jugar a cualquier videojuego? Me encantaría contar con más medios y hardware para poner a prueba la teoría, pero tendremos que conformarnos con mi actual equipo, que ya tiene unos cuantos años a sus espaldas, pero que aún le queda guerra que dar Por supuesto las pruebas se harán sobre Debian ¿Dónde si no? Y si no me muero en el intento, habrán 7 contendientes: Enlightenment 0.20.3, Cinnamon 2.2.16, Mate 1.8.1, Xfce 4.12.1, Gnome 3.14, KDE 5.4.3 y el séptimo adversario a batir será nuestro veterano servidor X11 corriendo a pelo Las pruebas a superar, como no podía ser de otra manera, son puramente gamer y bastante exigentes, especialmente para mi GTX 560 Ti que ya empieza a mirarme mal He intentado que fueran lo más variadas posibles, aunque dadas las limitaciones y ciertos problemas que han aparecido durante el proceso, no puedo jactarme de ofrecer una fiabilidad mínimamente aceptable, aunque sí una buena muestra que nos pueda poner al tanto de un par de cosas Equipo de pruebas Tests GPU Test Creo que con el nombre de este Test basta para saber de qué se trata. GPUTest se compone de un gran número de tests OpenGL que cubren un amplio espectro en lo que se refiere a probar las capacidades de nuestra GPU GiMark Plot3D FurMark TessMark Triangle Pixmark Piano Pixmark Volplosion Resumen El resumen no deja lugar a dudas, sin entorno gráfico gozamos de cierta ventaja a la hora de renderizar contenido. Cinnamon por su parte, no ha salido muy bien parado de este GPUTest, siendo el entorno que ha quedado último en 6 de las 7 pruebas. Para el resto de entornos los resultados son más variados y sin mucho que destacar. Unigine Valley El motor gráfico Unigine Engine es un clásico entre las pruebas de rendimiento gráfico y, a la espera de la inminente llegada de los nuevos Benchmarks Unigine 2.0, tendremos que conformarnos con dar unas cuentas vueltas por el Valle virtual creado por los rusos. Se repite la misma situación que en el caso anterior, con Cinnamon en la cola, aunque esta vez KDE también se nos ha desinflado un poco. Por supuesto, al correr el Benchmark sin entorno gráfico tenemos un extra aunque esta vez es mínimo. Hay que tener en cuenta que la capacidad del hardware de prueba es limitado, los valores que arroja son relativamente bajos y, probablemente, con un equipo que pudiera correr el test de manera más holgada obtendríamos mayores diferencias Metro Last Light Redux En un primer momento quería incluir un mayor número de juegos reales y recientes, pero finalmente me he decantado por el último título de 4A Games, principalmente por la facilidad que ofrece a la hora de realizar pruebas con él. Este test ha puesto las cosas del revés. Xfce ha arrebatado a Cinnamon el título del más lento, aunque no por mucho, y observamos un desplome importante en la prueba realizada sin entorno gráfico. Podríamos estar ante la excepción que confirma la regla, pero la explicación es algo más sencilla. Nos encontramos ante el primer problema a la hora de realizar los test. En este caso, para poder realizar la prueba de Metro Last Light Redux, era necesaria la intervención del Cliente de Steam, que corría en segundo plano cuando se ejecutaba desde un entorno gráfico, pero que al lanzarlo directamente sobre las Xs, el la ventana de Steam se ha interpuesto, colocándose delante de las imágenes de prueba y saboteando así el resultado final. Unreal Engine 4 Matinee No podía faltar la mayor creación de Epic Games. Los demos de UE4 son de sobra conocidos y en este caso me he decantado por la espectacular escena de lucha Matinee para poner en apuros a mi tarjeta gráfica Este test es, sin lugar a dudas, el más extraño de todos, poniendo todo patas arriba y, en esta ocasión, sin ninguna excusa por mi parte. Es muy curioso ver a Gnome y KDE disputándose los puestos de cabeza con Mate, mientras que Enlightenment, que hasta ahora había estado siempre arriba, pierde algo de fuelle. Una vez más, Xfce nos deja un sabor amargo quedando otra vez por detrás de Cinnamon. Por último, de las siete pruebas, la que se ha realizado sin entorno gráfico ha quedado justo a la mitad, dejándome sin saber qué pensar. Aunque si observamos de cerca la línea de tiempo vemos que los resultados han sido muy irregulares con picos y valles muy acusados (o inverosímiles como en el caso de Cinnamon), con mínimas y máximas exageradas. Lo único que podría sacar en claro de este test es que, dada su "inestabilidad", se trata de una prueba que no nos permite sacar ninguna conclusión clara acerca del rendimiento. Pejiguero que es uno, cuando ya casi había hecho limpieza de toda la basura que he tenido que meter para hacer los test, he tenido una idea feliz Me he puesto a probar de nuevo con UE4 y he descubierto algo que también es muy interesante. El perfil de phoronix test suite para los demos de Unreal Engine no incluye ninguna opción adicional, sólo la ejecución básica. Eso significa que cuando he realizado los test, matinee se estuvo ejecutando de la manera más "conservadora" posible, que viene a ser el modo GLSL 150, OpenGL del año de maricastaña. Esta vez sólo he comparado E20 con la ejecución sin entorno gráfico y no pienso hacer ninguno más, de momento . La línea de tiempo y los valores de pico muestran de nuevo mucha inestabilidad, pero en contra del sentido común, al subir las opciones al máximo forzando la ejecución con GLSL 4XX (OpenGL 4.x), el rendimiento ha aumentado entre un 15% y un 20% "Conclusiones" Como no me he cansado de repetir, las limitaciones nos impiden ir más allá de algo más bien anecdótico para poner en apuros a mi equipo, pero al menos hemos podido comprobar que, efectivamente, el entorno gráfico tiene cierto peso en lo que a rendimiento gráfico se refiere. Establecer un ranking de entornos con tan pocos datos sería aventurarse demasiado. Sin embargo, parece que los pesos pesados del escritorio Linuxero, Gnome y KDE se mantienen más o menos en la media de la tabla, mientras que Cinnamon tiene que trabajar más en lo que se refiere a rendimiento gráfico. La gran sorpresa ha sido Xfce, pues el sentido común nos podría hacer pensar que un escritorio de este tipo debería rendir mejor que sus compañeros mucho más grandes y pesados y, sin embargo, lo hemos visto aparecer a menudo en los puestos de cola, siendo varias veces el último de todos. Insisto una vez más en que lo que he mostrado aquí ha sido mi muy limitada experiencia con un hardware muy concreto y tan sólo unas pocas pruebas, pero de vez en cuando no está de más comprobar las cosas por uno mismo
  4. GLXOSD es un software de análisis de rendimiento gráfico, que nos permite cuantificar y monitorizar el rendimiento de cualquier aplicación que ponga a trabajar nuestra tarjeta gráfica. Además de la tasa de fotogramas por segundo, demora entre frames y otros datos habituales en benchmarking, también podemos monitorizar carga y temperatura tanto de la GPU como de la CPU durante la ejecución de la aplicación. Es importante tener en cuenta que para poder llevar a cabo la medición de temperatura debemos contar con controladores gráficos que lo permitan y, como en otros casos, no es así en el caso de los Catalyst ni tampoco de algunos de los controladores libres, como los Nouveau. Para los controladores privativos de Nvidia no debería haber ninguna traba. Capturas Descarga Arch (Aur) yaourt -S glxosd PPA apt-add-repository -y ppa:nickguletskii200/glxosd apt-get update i386 apt-get install -y glxosd glxosd-libs-libsensors-support-i3 Amd64 apt-get install -y glxosd glxosd-libs-libsensors-support-amd64 glxosd-libs-libsensors-support-i386 En caso de tener una tarjeta gráfica Nvidia instalaremos también el paquete apt-get install glxosd-libs-nvidia-support-i386 Compilar a partir del código fuente Como dependencias necesitamos mesa-common-dev libgl1-mesa-dev libglu1-mesa-dev libfontconfig1-dev libfreetype6-dev libsensors4-dev libboost-dev git clone https://github.com/nickguletskii/GLXOSD cd GLXOSD cmake -G "Unix Makefiles" make all make install Uso Basta con anteponer el comando glxosd al software que queremos medir glxosd aplicación Web http://glxosd.nickguletskii.com
  5. Abróchense los cinturones y mantengan el culo bien pegado al asiento porque ya tenemos en nuestras manos un gran número de demos técnicas impulsadas por el motor gráfico de Epic Games, Unreal Engine 4. De manera nativa y puramente para 64 bits, estas muestras que ha compartido Epic con nosotros pondrán a prueba nuestras equipos, exprimiendo al máximo las capacidades de nuestro hardware, al mismo tiempo que nos dejan con la boca abierta. Sólo recomiendo dos cosas, equipos antiguos o modestos mejor abstenerse y a los demás... tengan preparado un cubo, una fregona y un buen babero :lol: Elemental http://ue4linux.raxxy.com/elemental_demo.tar.bz2 Effects Cave http://ue4linux.raxxy.com/effects_cave_demo.tar.bz2 Realistic Rendering http://ue4linux.raxxy.com/realistic_rendering_demo.tar.bz2 Reflections Subway http://ue4linux.raxxy.com/reflections_subway_demo.tar.bz2 Sci-Fi Hallway http://ue4linux.raxxy.com/sci-fi_hallway_demo.tar.bz2 Sun Temple http://ue4linux.raxxy.com/sun_temple_demo.tar.bz2 Stylized http://ue4linux.raxxy.com/stylized_demo.tar.bz2 Blueprint Office http://ue4linux.raxxy.com/blueprint_office_demo.tar.bz2 Landscape Mountains http://ue4linux.raxxy.com/landscape_mountains.tar.bz2 Matinee http://ue4linux.raxxy.com/matinee_demo.tar.bz2 Shooter Game http://ue4linux.raxxy.com/shooter_game.tar.bz2 Strategy Game http://ue4linux.raxxy.com/strategy_game.tar.bz2 Vehicle Game http://ue4linux.raxxy.com/vehicle_game.tar.bz2 Platformer Game http://ue4linux.raxxy.com/platformer_game.tar.bz2 Atlantis Substance http://ue4linux.raxxy.com/atlantis_demo.tar.bz2 Couch Knights http://ue4linux.raxxy.com/couch_knights.tar.bz2 Light Room Interior http://ue4linux.raxxy.com/lightroom_interior_day.tar.bz2 Por supuesto, a través de la wiki oficial de Epic Games podremos acceder a toda la información y material disponibles sobre Unreal Engine 4 https://wiki.unrealengine.com/Linux_Support
  6. Oscar ha tenido la gentileza de compilar el demo de Unreal Engine 4 "Cave" de Epic Games para GNU/Linux. No se trata de un Benchmark y tampoco muestra datos minuciosos pero nos permite poner a prueba nuestro equipo y al mismo tiempo deleitarnos con las bondades de este novedoso motor gráfico multiplataforma. De entrada tendremos una secuencia donde iremos desplazándonos por la caverna, como cualquier benchmark de este estilo y al finalizar ésta, tendremos la oportunidad de desplazarnos libremente por el lugar. Por defecto el demo inicia en modo OpenGL 3.2, pero si queremos exprimirlo de verdad también podemos irnos a OpenGL 4.3 con la opción -opengl4 Del mismo modo, para ejecutarlo en pantalla completa podemos usar FULLSCREEN y para variar la resolución indicamos el ancho con: -ResX= y el alto con: -ResY= Por poner un ejemplo, una prueba a pantalla completa a 1920x1080 con OpenGL 4 shiba@Shiba87:~/cave$ Linux/engine/binaries/linux/effects FULLSCREEN -ResX=1920 -ResY=1080 -opengl4 Descarga https://mega.co.nz/#!t1MEUKgK!gkIy2X7IKYsK9rx1h3FAVGY81yVx8UAzNpwnyo6fzTs
  7. Vuelvo a poner mi pregunta, ya que se borró debido a unos problemas en el foro y necesito por lo menos las respuestas que me habían dado. No me acuerdo los usuarios, pero la segunda respuesta me había recomendado actualizar el kernel y seguir las instrucciones de esta página. A eso ya lo hice y no solucionó el problema, pero recuerdo que en esa respuesta habían algunos métodos más ¿Me los podrían poner de nuevo o darme más consejos? Acá está la pregunta original: No se como puedo solucionar el problema
  8. Hola gente, como les va, buenos dias. Hace 1 mes instalé OpenSUSE 13.1 x64, y me encanta esta distro. Pero estoy teniendo mal desempeño en lo que refiere a gráficos. Tengo delays (atrasos) y bajos fps. Por ejemplo, si tengo un cubo generado por computación gráfica, puedo picar en alguna parte del mismo y hacerlo que rote sobre si mismo manteniendo el clic apretado y moviendo el mouse. Aclaro, tengo dual boot, y esto en Windows 8.1 Pro funciona como debe ser, perfecto. Lo que sucede es que cuando mantengo el clic apretado y comienzo a moverlo, el movimiento se atrasa, en el sentido que si mantengo apretado y lo muevo por 4 segundos y luego suelto el clic, el cubo sigue moviéndose alrededor de 2 o 3 segundos más. Es decir, no sigue su movimiento rotatorio solidario al mouse, sino que se atrasa. Otros errores mas también se me presentan, pero ese fue un ejemplo de los mismos. Quisiera saber que me proponan para solucionar esto, ya que uso mucho la GPU por cuestiones universitarias, y esto no me permite seguir trabajando como debe ser en computación gráfica. Mi GPU es una integrada, pues tengo una notebook lenovo G580 y viene con gráficos Intel HD 4000 incorporados. Quisiera saber que puedo hacer para dar una solución a esto, estoy seguro que es un problema de drivers, pero no sé por donde arrancar. Cabe aclarar que tengo la ultima version del kernel de linux, la 3.14.1-1.geafcebd-desktop Desde ya agradecería sus aportes, saludos a todos!
  9. /tmp es un directorio volátil donde se almacenan los datos temporales utilizados por las aplicaciones y usuarios y cuyo contenido es borrado al terminar la sesión o reiniciar el sistema. Este directorio está montado por defecto en una de las particiones del disco duro (HDD o SSD), comunmente en la partición raíz. En situaciones en las que se haga un uso intensivo de este directorio, como a la hora de compilar el código fuente de algún software o servidores que vean mermado su rendimiento por escribir gran cantidad de datos en temporales, podría no ser conveniente tenerlos de esta manera. Por esto, montar el directorio /tmp directamente en la ram puede suponer un gran aumento del rendimiento, pues la tasa de lectura/escritura de la memoria Ram es muy superior a la de cualquier Disco duro convencional o SSD. No obstante, también debemos tener en cuenta que el espacio que ocupen los temporales en RAM no podrá ser utilizado para otras tareas. La clave para realizar este proceso es TMPFS, el cual nos permitirá montar los temporales en ram como si fuera otra partición más del disco duro, pero con un sistema de archivos diferente. Montaje Manual mediante el comando MOUNT Para un montaje no permanente que nos permita realizar una tarea concreta y luego poder devolver el sistema a la normalidad, podemos utilizar directamente mount especificando que lo que queremos es montar los temporales en ram con tmpfs. Además de eso, podemos utilizar y combinar las opciones propias de mount para que el montaje se realice según sea conveniente. Una manera simple de hacerlo sería la siguiente: En este caso hemos puesto los permisos del directorio /tmp a 1777 para que las aplicaciones/usuarios no tengan problemas a la hora de utilizar los nuevos temporales. Sin embargo podríamos querer ir más allá en lo que opciones se refiere y, por ejemplo, permitir a un único usuario utilizar estos nuevos temporales: De esta forma, el nuevo directorio /tmp, tendrá como usuario y grupo (uid/gid) el que nosotros designemos. Además de cambiar los permisos a 750 para que esta medida sea efectiva. Al tratarse de un cambio temporal, en cuanto reiniciemos el equipo todo volverá a la normalidad. También podríamos desmontar dicha partición mediante el uso de umount, siempre y cuando no esté en uso. Haciendo el cambio permanente gracias a FSTAB Editando el archivo de configuración /etc/fstab, podremos hacer este cambio permanente, consiguiente que los temporales se monten siempre en la memoria RAM, aunque en este caso conviene tener algunas consideraciones extra a la hora de elegir las opciones de montaje Una de esas opciones es size, que nos permitirá limitar el tamaño del directorio /tmp, para evitar que ocupe una cantidad de ram mayor de la esperada y nos veamos en problemas. Por ejemplo, para unos temporales de 2GB, añadiríamos lo siguiente: Para cualquier otro valor sólo hay que modificar la cantidad especificada en esa opción. Podríamos utilizar cualquier otra opción , como noexec, para no permitir ejecutar nada desde esa partición, nodev, nosuid, etc Una vez guardados los cambios, tendremos que montar manualmente la partición o reiniciar el equipo (sólo la primera vez, a partir de ahí el montaje se tmpfs realizará de manera automática)
  10. Buenas, dada esta temporada tan centrada en los videojuegos, las liberaciones de codigos de las compañias y demas aportes y transiciones a GNU/Linux, me ha dado por hacer esta encuesta preguntando basicamente, por que entorno grafico os parece el mas adecuado para gaming, y en general, cual seria el mejor para el uso general o cotidiano ( que vendria basicamente a ser multimedia y ofimatica ) Salunix
  11. Unigine Heaven es un Benchmarking multiplataforma muy conocido que utiliza el motor gráfico Unigine y un recorrido por unas extrañas islas flotantes para comprobar el rendimiento gráfico que es capaz de ofrecer nuestro equipo y así poder medir y comparar las capacidades reales de nuestra tarjeta gráfica y la configuración de nuestro equipo. Mejoras incluidas en la versión 4.0: - Soporte para mostrar la temperatura y frecuencia de la GPU durante el testeo - Mejora drástica de la calidad visula de la SSDO (Scene Space Directional Occlusion). - Renderizado de estrellas durante la noche. - Destellos de lente (Lens Flare) mejorados - Mejorada la detección de configuraciones Multi-Gpu - Varias correcciones de bugs. - Nueva versión del Unigine Engine - Disponible en tres versiones, Free, Advanced y Pro Capturas Vídeo Descarga Torrent http://www.unigine.com/download/torrents/Unigine_Heaven-4.0.run.torrent Descarga directa http://www.techpowerup.com/downloads/2204/Unigine_Heaven_Benchmark_4.0_for_Linux.html Web http://unigine.com/
  12. Mucho se ha hablado últimamente de este tema, más que nada por la llegada de Steam GNU/Linux y algunos de los juegos que lo acompañan, pero ¿Qué hay de cierto en todo lo que se está diciendo?¿Cuánto influye el entorno gráfico utilizado a la hora de jugar en GNU/Linux? Lamentablemente no cuento con todo lo necesario para poder probar a fondo esta cuestión y les puedo adelantar desde ya, que al menos en mi caso, las pruebas no ha arrojado mucha luz al asunto. Para poner a prueba el mito he utilizado la plataforma de benchmarks Phoronix-test-suite, concretamente he hecho uso de dos de sus test, el de Unigine Heaven y el de Xonotic. Me hubiera gustado probar más test, más entornos y más configuraciones, pero cada prueba supone varias pasadas de cada test, cada pasada son unos 5 minutos, hay que repetirlo en cada entorno, con configuraciones diferentes.... en definitiva, muchas horas y muchos recursos. Los entornos que he utilizado han sido principalmente Gnome3 (3.4) y Kde (4.8), sin modificaciones, tal cual se instalan desde los repositorios de Debian Testing y también E17, que es el que siempre tengo instalado. Por último y aprovechando que tenía pendiente instalar de nuevo Debian he aprovechado para hacer una prueba de control sin entorno gráfico instalado. Las primeras pruebas fueron un fracaso, las incluyo para que vean lo que puede llegar a alterar el resultado un pequeño error a la hora de realizar las pruebas. En estas primeras pruebas fallidas, KDE queda por detrás del resto con algo de diferencia, no mucha pero se ve a simple vista. Sin embargo, después de llevar a cabo las pruebas me di cuenta de que ciertos paquetes de KDE parecían no estar bien instalados y el entorno no estaba funcionando bien, así que las repetí después de haber corregido el problema. Como ven, ahora ha quedado todo mucho más parejo y vemos que efectivamente hay diferencia entre utilizar Gnome 3 con Gnome-Shell y hacerlo en modo Fallback (Classic), modo que, por cierto, han eliminado en la última versión de Gnome 3 Aún habiendo confirmado eso, no podemos dar un veredicto claro en cuanto a lo que supone utilizar uno u otro entorno, ya que aunque parece que el modo Fallback de Gnome 3 es el que rendiría mejor, la diferencia entre los valores obtenidos es mínima, sobre 1FPS en el peor de los casos y bastante menos en el resto. La prueba de control sin entorno gráfico también demuestra que aunque no es algo muy acusado, los entornos gráficos sí que influyen negativamente en el rendimiento, salvo por la segunda ronda de pruebas con Xonotic donde me ha fallado todo y no he podido averiguar aún por qué, pero doy por sentado que algo hice mal, el resultado debería ser similar al que vemos en el caso de Unigine Heaven. Como dije al principio, nos encontramos ante un conjunto de test cuyos valores son muy cercanos entre sí, que no incluyen un número suficiente de pruebas como para poder afirmar algo concreto y tampoco se ha podido contar con distintas configuraciones de hardware para ver cómo se comportaría en cada una. Lo único que puedo decir después de todo esto es que si van a jugar, eviten hacerlo en Gnome-Shell u otros shells para Gnome 3 (Especialmente Unity). No es una diferencia como para echarse las manos a la cabeza, pero que, aunque leve, está ahí. El resto de entornos no representan ninguna ventaja ni tampoco ninguna desventaja, el rendimiento obtenido es muy similar. Lo único que se me ocurre pensar y esto es ya algo que digo sin pruebas en base a lo que creo podría estar ocurriendo, es que aquí, para estos tests he utilizado versiones de KDE y Gnome muy testeadas y estables, que ya llevan tiempo siendo utilizadas y no las últimas que han sido lanzadas, con lo cual se podría pensar que las diferencias de rendimiento de las que hemos oído hablar tanto últimamente se dan en versiones posteriores, bien por un aumento de rendimiento de KDE, una regresión de Gnome 3 o ambas cosas, no lo sé. Vuelvo a recordar que en la última versión de Gnome 3 el modo Fallback ya no existe, por lo que seguramente no pueda igualar los resultados conseguidos por la versión 3.4 en las pruebas que yo he realizado, quedando por debajo del resto de entornos. Conclusiones Se nos presentaban dos incógnitas, la primera era si Gnome Shell (y otros Shells para Gnome 3) suponen un lastre a la hora de jugar en GNU/Linux y la respuesta es SÍ. No es una diferencia demasiado notable en cuanto a rendimiento pero los juegos (y otras aplicaciones OpenGL) sí rendirán menos al ejecutarse en Gnome Shell. La segunda cuestión que viene oyéndose desde hace algún tiempo en los medios Linuxeros es si KDE es realmente la mejor opción a la hora de jugar. En este caso y en vista de los resultados obtenidos en las pruebas mi respuesta es NO. Todos los entornos han obtenido una puntuación similar, no es posible decir cuál es el que mejor rendimiento nos va a ofrecer, aunque en todo caso no sería KDE, sino el extinto modo Fallback de Gnome 3 el que ha quedado en primer lugar.
  13. Acaba de aparecer el 2º de la serie “mágica” de Nvidia, los controladores 310.19 como estables en la página de Nvidia Los nuevos cambios para estos controladores incluyen: Mejorado el soporte para OpenGL 4.3. Añadido una nueva opción de configuración "UseHotPlugEventes" para permitir la supresións de los eventos RandR cuando añadimos o eliminamos pantallas del puerto Non-Display. Soporte para configuración stero en nvidia-settings cuando éste está habilitado en el xorg.conf. Soporte para configuración del ViewPortIn y ViewPortOut desde nvidia-settings. Corregido el metamodo bookkeeping cuando se modifica la configuración en página "X Server Display Configuration" del nvidia-settings. Añadido soporte para configurar la rotación y la reflexión Implementados varios workarounds para flash, aplicados a las librerías libvdpau incluídas en los controladores Corregido el problema que hacía disminuir el rendimineto al mover ventanas ejecutando aplicaciones Vdpau en algunos compositores Añadido soporte para el protocolo GLX, y para la extensión OpenGL GL_ARB_pixel_buffer_object. Añadido soporte para HDMI 3D Stereo para las Quadro Kepler y posteriores GPUs (Ver documantación "stereo") Añadido soporte para Optimizaciones de hilos de ejecución experimentales de OpenGL disponibles a través de las variable de entorno __GL_THREADED_OPTIMIZATIONS environment variable Variable Settings" of the README. Mejorado el rendimiento y respuesta de las aplicaciones OpenGL en Unity Descarga i386 http://download.nvid...-x86-310.19.run amd64 http://download.nvid...6_64-310.19.run
  14. El Valve linux Team lo ha hecho, han portado satisfactoriamente Left 4 Dead 2 a GNU/Linux y ahora desmuestran su éxito optimizando el Source Engine para que funcionane en GNU/Linux con OpenGL, pero es que no sólo han demostrado que es posible que el juego rinda bien en GNU/Linux, sino que han hecho que supere a la versión Directx corriendo en Windows 7 Como se dijo hace un par de días, Valve presentará el juego durante el SIGGRAPH LA 2012 en una conferencia titulada: "Left 4 Dead 2 Linux: From 6 to 300 FPS in OpenGL" donde hablarán precisamente de este increíble rendimiento. El equipo utilizado para las pruebas de rendimiento ha sido un "modesto": Hardware Intel Core i7 3930k NVIDIA GeForce GTX 680 32 GB RAM Software Windows 7 Service Pack 1 64-bit Left 4 Dead 2 Ubuntu 12.04 32-bit ¿Tendrían miedo de quedarse cortos de ram ? Y los resultados han sido cuanto menos sorprendentes. Según sus propias palabras, cuando comenzaron el desarrollo, el juego no superaba los 6 FPS, un rendimiento horrible, dicho en pocas palabras, pero algo normal cuando inicias un desarrollo en una plataforma hasta ahora "desconocida". Esta mejora se ha conseguido tras una serie de modificaciones como pueden ser: Modificaciones para mejor integración con el kernel Modificaciones para mejorar el rendimiento OpenGL Optimizar los controladores gráficos de Linux Por citar algunos ejemplos de lo que hen hecho en cada caso, como mejoras respecto al kernel se han centrado en que el juego hiciera un mejor uso de la memoria del sistema. En cuanto a OpenGL han reducido el número de llamadas a OpenGL y añadido algunas nuevas extensiones del motor de renderizado con nuevas interfaces para un mejor encapsulado. La optimización de los controladores se ha llevado a cabo mediante el trabajo directo con los respectivos fabricantes. Finalmente, las pruebas han demostrado que han conseguido pasar de los 6 FPS iniciales a nada menos que 315 FPS, mientras que en Windows el juego no ha superado los 270,6 FPS. Pero eso no es todo, la versión OpenGL del juego funcionando en Windows, donde OpenGL es el gran olvidado y apenas está optimizado, también rinde bastante mejor que la versión DirectX alcanzado los 303,4 FPS. Según los análisis que han hecho, parece ser que la diferencia de rendimiento no se debe al multitasking como pensaban en un principio sino que se reduce a unos pocos microsegundos adicionales que necesita DirectX en cada llamada. También afirman que habiendo demostrado OpenGL que el hardware se puede exprimir aún más, intentarán mitigar este efecto en la versión DirectX. http://blogs.valvesoftware.com/linux/faster-zombies/
  15. Una vez más, tras un largo parón, ponemos a prueba los navegadores más populares de la actualidad para ir viendo cómo se comportan y cómo van evolucionando con el tiempo. En esta ocasión, he reducido el número de navegadores a prueba y cambiado un poco "las reglas de juego", hay test que solía utilizar que ya no son válidos y otros que han sido modificados para adaptarse a los nuevos tiempos, así que hay que tenerlo en cuenta en caso de querer comparar con resultados obtenidos anteriormente. Navegadores puestos a prueba: Firefox 13.0.1 Iceweasel 14 Beta11 Google Chrome 20.1132.47 Chromium 20.1132.43 Opera 12.00-1467 Pruebas realizadas Pruebas de consumo: Consumo de ram inicial Consumo de ram con 5 pestañas abiertas Consumo de ram con 10 pestañas abiertas Pruebas de rendimiento javascript : Sunspider V8 benchmark Kraken benchmark Pruebas de rendimiento gráfico y WebGL: Webvizbench Asteroids Benchmark Khronos WebGL Test Otros Tests: PeaceKeeper Html5test Browser Security Test Tiempo de carga de distintas webs: Google Facebook Debian.org Phoronix.com Equipo de pruebas Procesador: Intel I5-2400 3.1GHz Placa base: Gigabyte H67MA-UD2H-B3 Memoria: 8GB G.Skill ddr3 1600 Mhz Tarjeta gráfica: Nvidia GTX 560 Ti Disco duro: WD Caviar black sata3 500GB Distribución: GNU/Linux Debian Testing/Sid Kernel: Linux 3.4.4 Pruebas de consumo Consumo inicial de Ram La mayoría de las veces escuchamos, "tal navegador es más ligero", "tal otro consume mucho", "la memoria ram esto", "la memoria ram lo otro". Lo cierto es que casi todas las cosas que se dicen por ahí son falsas, o se tergiversan según conviene. La realidad es que Chrome/Chromium es el navegador que más consume, con diferencia. Esto se debe a que este navegador separa todo en procesos independientes. Cada pestaña abierta es como si abriéramos un nuevo navegador. Este sistema, tiene como ventaja que si en un momento dado el navegador sufre un problema, el único proceso que se verá afectado será el que corresponde a la pestaña problemática. La desventaja es la que ya hemos dicho, un consumo mucho más elevado por parte del navegador. EL resto de navegadores agrupan todo en un número concreto de procesos, por lo que su consumo es mucho menor. La desventaja es que en caso de fallo, una pestaña problemática puede afectar al resto. Consumo de Ram con 5 Pestañas abiertas Cuantas más pestañas abrimos más evidente se hace la diferencia y mientras Opera y los navegadores de Mozilla se mantienen con un consumo "moderado", el consumo de Chromium/chrome se dispara, aunque un poco menos en el caso de Chromium. Consumo de Ram con 10 Pestañas abiertas Ahora la diferencia entre Chromium y Chrome se hace aún más evidente y si continuáramos abriendo pestañas se alejarían cada vez más. En cuanto al resto de competidores, está claro que el más ligero es Firefox, seguido de Opera y en tercer lugar Iceweasel, moviéndose los 3 más o menos en la misma franja de valores. Se puede apreciar también una diferencia de consumo notable entre Iceweasel y Firefox, como la que ocurre entre Chromium y Chrome, pero recordemos que en este caso uno de ellos es la versión final y el otro la beta, así que que no podemos estar seguros de a qué es debido el aumento de consumo. Pruebas de rendimiento javascript Sunspider Chromium/Chrome recuperan el primer puesto que habían perdido anteriormente ante Firefox/Iceweasel y continúa el tira y afloja entre estos dos. Opera sigue a su ritmo y no entra en batalla, aunqe no hace un mal papel ni mucho menos. V8 benchmark Hay que tener en cuenta, que este test está diseñado por Google para el motor V8, con lo cual, quien "juega en casa" sale con ventaja. El ganador indiscutible de este benchmark sigue siendo Chromium/Chrome , pero parece que los de Mozilla se les van acercando, aunque aún están bastante lejos. Kraken Benchmark En anteriores pruebas, Chromium/Chrome pasó de ser el peor con diferencia en esta prueba a ocupar los puestos de cabeza, que aún conserva a día de hoy. Opera sigue sin ser rival para los otros dos en esta prueba y Mozilla mantiene un buen puesto aunque algo alejado del primero. Pruebas de rendimiento gráfico y WebGL Webvizbench Si en las pruebas de javascript, el rey era Chromium/chrome, en cuanto a rendimiento gráfico es Mozilla quien se lleva el gato al agua. La versión actual de Firefox es más capaz que Chromium/Chrome en cuestiones gráfica y según se puede apreciar en la beta de Iceweasel, en futuras versiones mejorará aún más. En cuestiones gráficas Opera sigue teniendo mucha tarea pendiente, aunque parece que va avanzando a buen ritmo. Asteroids Benchmark Contrariamente a lo sucedido con webvizbench, en este test tanto Firefox/iceweasel como Chrome/chromium se mantienen más o menos al mismo nivel. Opera sigue sin poder seguirles el ritmo a los otros. Khronos WebGL Test El resultado de este Benchmark es cuanto menos "curioso". Si bien a simple vista podríamos decir, que la diferencia entre Firefox/Iceweasel y Chromium es apenas un 1%, ni Chrome ni Opera han sido capaces de pasar esta prueba. En el caso de Opera, aunque recientemente han empezado a trabajar con WebGL aún no está lo suficientemente maduro y no ha podido ni empezar la prueba, tan sólo ha mostrado un error de compatibilidad. El caso de Chrome es más extraño, pues siendo el Fork de Chromium debería pasar la prueba con resultados idénticos o muy similares, pero en lugar de eso, el navegador acaba fallando y cerrando la pestaña del test. He realizado la prueba varias veces y de distintas maneras y todas ellas han acabado en desastre, en ningún caso Chrome ha podido terminar la prueba, por lo que está claro que hay "algo" que Google ha añadido/quitado/modificado en Chrome que no le ha sentado nada bien. Otros Tests PeaceKeeper Como siempre, Chromium/Chrome sigue intratable en este Test en el que Firefox/Iceweasel siguen sin destacar. Html5test Características HTML5, un test que hay que coger con pinzas. Este test es bastante simple, se listan las características html5 que debería soportar actualmente un navagador y en función de hasta que punto estén soportadas por el navegador que estemos probando, se obtiene una puntuación. El problema que surge con este test es que hay ciertas características Html5 que son privativas y/o de pago, por lo que no todos los navegadores están dispuestos a implementarlas o no son capaces de asumir el desembolso económico que eso supone. Aún con todo, está claro que Chrome/Chromium son los que mejor puntúan aquí y Opera soprende en esta ocasión, pasando de ser el peor con diferencia a estar en los puestos de cabeza, por encima de Firefox/Iceweasel. Sin embargo, se observa un "problema" al comparar Chrome y Chromium y es que su puntuación es idéntica. Sabemos que, al contrario que Chrome, Chromium no incluye plugins privativos o da soporte a estándares cerrados, por lo que tendría que puntuar menos que Chrome. Eso me lleva a pensar que o bien Chrome ha dejado de lado ciertas Tecnologías o que se han incluido cosas en Chromium no muy deseables. Tendré que comprobar de nuevo este test punto por punto a ver qué descubro. Actualización: Al pasar el html5test Chromium "da positivo" para todas esas cosas que no deberían estar ahí, h.264, Mp3, Acc.... Sólo he echado un vistazo por encima, no sé si se debe a un falso positivo o que realmente se han incluido, pero está claro que hay algo raro. Browser Security Test Este test comprueba si el navegador cuenta con ciertas características de seguridad, no la seguridad en sí, ojo con eso, y en función de si son soportadas o no se obtiene una puntuación, que va de 0 a 17 (son 17 características, la que está soportada suma un punto, la que no, no suma). No es un test que represente gran cosa, lo he puesto más que nada por petición popular. Tiempo de carga de distintas webs Bueno....creo que este test, que aunque no pueda realizarse de forma correcta, pues cada web es un mundo y imposible probar todas y cada una de las direcciones de internet para sacar la media, sí que suele resultar interesante, si no el más interesante a la hora de realizar pruebas con un navegador. No creo que haya mucho que decir. En esta ocasión, Debian.org, Facebook y Phoronix cargan más rápido (con diferencia) en los navegadores de Mozilla, mientras que Google, curiosamente, tarda más en cargar en Chrome que en el resto, siendo Opera el más rápido. CONCLUSIONES Se acabó la parte objetiva de las pruebas y ahora empieza la parte en la que yo me dejo llevar y empiezo a decir tonterías. Empezaré diciendo que todo esto son simplemente Tests, no obtendremos los mismos resultados en todos los equipos ni podremos comprobar todos y cada uno de los casos posibles que pueden darse, por lo que esto sólo sirve para hacerse una idea de cómo son las cosas, no pueden ser tomados, ni mucho menos, como "la verdad absoluta". Ahora quiero recalcar una cosa, que ya dijeron hace tiempo algunos desarrolladores y que tras 5 o 6 pruebas de este tipo he podido constatar. Alguien dijo una vez, que existen diferentes maneras de desarrollar un navegador y o bien puedes centrarte en que puntúe muy bien en test sintéticos y luego a la hora de la verdad pueda pasar cualquier cosa u olvidar los test sintéticos y mejorar el navegador de verdad. En las pruebas anteriores y en otras ocasiones, hemos visto como navegadores que obtienen unas altas puntuaciones en los tests, luego a la hora de la verdad no hacen gala de esa supuesta superioridad. En este caso vemos como Chrome y Opera sacan altísimas notas en cuanto a compatibilidad Html5, Peacemaker y demás y luego no han podido pasar las pruebas de WebGL y en las pruebas de rendimiento gráfico no han estado por encima de navegadores que han puntuado mucho menos en las pruebas sintéticas. De la misma forma se ve que Opera, a pesar de ser el que peor puntúa en los test de Javascrit, es más rápido que Chrome/chromium a la hora de cargar distintas webs, aunque se supone que los anteriores son "los más rápidos". Personalmente, por lo visto aquí y por otros motivos, desaconsejo totalmente el uso de Google Chrome como navegador. Si bien cuenta con una serie de "extras" que Chromium no lleva, estos no han demostrado ser una ventaja a la hora de navegar, sino todo lo contrario. Entre los restantes, Firefox es el "todoterreno", el más versatil, el que se adapta a todo, pero sin dejar de ser rápido. Chromium, muy rápido, pero poco versátil, está pensado para una navegación "simple y veloz", no para hacer de todo. El caso de Opera es, sin duda, el más "especial", pues es un navegador que siempre ha ido a su aire. A día de hoy tiene pendiente ponerse al día en muchos aspectos en los que se ha quedado atrás, pero no por ello deja de ser un navegador rápido y con una serie de características propias que no han sido igualadas por nadie. No obstante, su carácter privativo y sus idas y venidas con los estándares me llevan a no incluirlo entre los aconsejados. En resumen, versátil y todoterreno, Firefox (y derivados), simple y rápido, Chromium(Y derivados LIBRES).
×
×
  • Crear Nuevo...