Libertonia
Portada · Todo · Software Libre · Desarrolladores · Comunidad · Internet · Tecnología · Meta · Diarios
¿En donde usas tu Linux?

Tecnología
Por JulHer
departamento Linux_en_mi_calculadora , Sección Software Libre
Puesto a las Fri Aug 23rd, 2002 at 12:40:05 PM CET
Uno de mis ordenadores en activo, es un 486 a 33 Mhz con 16 MB de Ram y un disco duro de 250 MB. Tiene dentro Debian Woody y hace un montón de cosas en mi red. Hasta tiene X. Es algo por lo que no dejo de sorprenderme, esa habilidad de poder ejecutar Linux en máquinas que iban a ir a la basura. Mi última recuperación (en un mes me la dan, también iba a la chatarra) va a ser una placa biprocesador con un par de 486, y tengo ganas de ver hasta donde puede llegar. Por cierto, que tiene un par de discos en raid, a ver si me entero de como funciona.

En esa línea de poder tener una máquina muy funcional y consumiendo pocos recursos, va este artículo de la revista Linux Journal del mes de septiembre. Nos cuentan como tener una máquina a la "última" con Icewm, Dillo, AbiWord... y por cierto... yo pregunto a los afortunados poseedores de pentiums IV y Athlones XP con toneladas de Ram... ¿vuelan?

 


< Conversor de configuración de Apache (0 comments) | De Libertonia y otros pecados (léase weblogs ;) (2 comments) >
Enlaces Relacionados
· artículo
· Linux Journal
· More on Tecnología
· Also by JulHer

Menu
· crear cuenta
· FAQ
· búsqueda
· Fuentes de Noticias

Login
Nueva cuenta
Usuario:
Contraseña:

Ver: Modo: Orden:
¿En donde usas tu Linux? | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
Idea interesante... (4.00 / 1) (#6)
por NoP a las Fri Aug 23rd, 2002 at 06:45:42 PM CET
(Información Usuario)

Lo del entorno gráfico para consola me ha parecido sumamente interesante... Screen sirve en cierta parte para paliar las relativamente pocas consolas. SVGATextMode y los modos de texto del LILO te dan "amplitud" a la pantalla.

¿Habéis probado twin? Se supone que es un entorno de ventanas en modo texto, pero no hay muchos programas que lo aprovechen.

Aparte de eso, ¿qué se supone que hace el port de gtk a framebuffer, correr aplicaciones GTK, o hay que recompilarlas?

¿No se podría hacer un XFree minimo, orientado a localhost:0.0 (sin red, displays y demas)? ¿Y Berlin?

En caso de diseñar algo para correr aplicaciones graficas en consola, ¿habria que buscar alguna compatibilidad con las aplicaciones graficas existentes, o hacer algo nuevo para lo cual hubiera que crear aplicaciones nuevas?

Si lo pensais bien es una gran idea y sería salvar gran cantidad de ordenadores que hoy en dia no tienen uso. Por ejemplo para el 3er mundo.





 
No vuelan, no :( (none / 0) (#1)
por davinci (davinci at ecol org) a las Fri Aug 23rd, 2002 at 01:50:01 PM CET
(Información Usuario)

Y eso es lo malo. Estamos hablando de auténticas maquinazas, pero sal de la consola y sus aplicaciones y verás como languidecen y a la mínima empiezan a tirar de swap, aunque tengas tus buenos 128 Mb de RAM.

Para y dar una idea de a qué me refiero, considero rápido el links gráfico funcionando en framebuffer, por ejemplo. Nada que ver en comparación con Galeon, Mozilla, Konqueror y compañía. Y estoy hablando de ejecutar el browser sin sistemas de escritorio por debajo. Si le añades Gnome o Kde... muérete lentamente :(

Quizá un sistema de ventanitas para framebuffer daría nueva vida a nuestras máquinas. Habrá que ver qué ocurre con el port de Gtk para framebuffer 8)

Saludos.


¡Es la guerrrrrrra!


Athlon XP 1600 con 512 Mb RAM y... (none / 0) (#3)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Fri Aug 23rd, 2002 at 04:39:17 PM CET
(Información Usuario)

... no corre tanto, ni siquiera con mi Gentoo 2.0 (la del GCC 3.2), aparte de chorrocientos bugs que tienes que ir corrigiendo; la verdad es que tiene una velocidad aceptable, con KDE 3.0.3 y XFree 4.2, y los temas estos transparentes y "líquidos", pero desde luego que si en un PII a 200 tarda X segundos a hacer algo, en un PIII a 1000 no tarda 5 veces menos ni de lejos...

Y explico por qué. En un sistema digital en el que hay tráfico de información (o sea, información que va de un lado a otro), la velocidad tope es la del componente más lento. En mi caso, los discos duros en cuanto a almacenamiento y el bus de datos (a 133 MHz) en cuanto al trabajo del microprocesador.

Por tanto, si mi bus es de 133, y el de otro equipo es de 100, la relación de velocidad máxima (ojo, máxima, no sostenida) será de un 33% mayor. Con los discos duros pasa otro tanto, en mi caso tengo un ATA 100 y un ATA 66. ¿Cuál irá más rápido? Pues el de 66 porque gira a 7200 rpm y su tasa, bajo mi linux, es de 7,7 Mb/s, mientras que el otro es de sólo 6 y pico.

Y quien diga lo contrario miente como un bellaco, o no sabe de lo que habla (me refiero a las empresas cuando te dicen que tal disco duro tiene una tasa de X megas, etc).

[ Padre ]


Sobre cifras de velocidad de discos duros... (5.00 / 1) (#4)
por iarenaza a las Fri Aug 23rd, 2002 at 06:10:17 PM CET
(Información Usuario) http://www.escomposlinux.org/

Pues el de 66 porque gira a 7200 rpm y su tasa, bajo mi linux, es de 7,7 Mb/s, mientras que el otro es de sólo 6 y pico.
Humm, pues tienes tu sistema configurado por debajo de sus posibilidades. Lo normal en un sistema con discos como los que comentas es que los ratios de transferencia esten entre los 15-30 MB/s. ¿Tines soporte para UDMA de tu chipset compilado en el kernel? ¿Tiene UDMA activado en los discos (man hdparm)? ¿Tienes el modo de transferencia de 32 bits activo? ¿Y el irq umasking? ¿Y los otros cuatro o cinco parametros mas que hdparm permite ajustar para obtener hasta el ultimo bit de transferencia adicional?

De jugar con todo esto a no tener ni siquiera el UDMA activo puede haber un mundo. El disco que tengo en este portatil, sin ser ninguna maravilla (5400 rpms, UDAM100) me está dando ahora mismo unos 23.7 MB/s. Por supuesto la velocidad del micro y del bus PCI (por el Bus Mastering DMA) influye tambien en esa cifra (IDE es algo todavia demasiado influido por el rendimiento del micro). Si desactivo el UDMA la tasa baja hasta 4.2 MB/s. Como ves, todo un mundo.
Y quien diga lo contrario miente como un bellaco, o no sabe de lo que habla (me refiero a las empresas cuando te dicen que tal disco duro tiene una tasa de X megas, etc).
Una cosa es la velocidad a la que la electronica del disco es capaz de sacar datos de las pletinas donde estan guardados los datos (que son esos cientos de MB/s que suelen dar los fabricantes) y otra la cantidad de datos que son capaces de mover a traves de los buses internos del disco, los del sistema (PCI, etc) y hasta la memoria del sistema. En este segundo caso influye mucho el chipset IDE, la calidad del controlador PCI (y especialmente el arbitrio del bus y el bus mastering) y lo rapido que la CPU es capaz de pedir mas datos (sin contar el propio ancho de banda de la memoria principal del sistema y la propia sobrecarga de los protocolos de cada uno de esos buses).

Como ves, demasiadas cosas donde se va perdiendo tiempo, lo que hace que lleguemos a esos 15-30 MB/s (a veces incluso mas), que estan lejos de los cientos de MB/s que marcan los fabricantes. Pero es que son datos diferentes, y el fabricante solo puede darte con fiabilidad el primero (puesto que solo el puede medir las velocidades internas del disco, desde fuera no se puede) ya que el segundo depende del resto del sistema y eso el no puede controlarlo. Aun asi, los fabricantes serios suelen dar estimaciones para configuraciones concretas.

Saludos. Iñaki.

[ Padre ]


Datos adicionales sobre la velocidad de los discos (5.00 / 1) (#8)
por dardhal a las Sat Aug 24th, 2002 at 12:01:54 AM CET
(Información Usuario)

Datos confirmando lo que advierte iarenaza, en este caso en un PC de escritorio (no portátil) con disco IDE UDMA100 de 7200 rpm. Velocidad sostenida de escritura a disco superior a los 25 MB/s. Velocidad sostenida de lectura desde disco superior a los 40 MB/s. Otra cosa son los tiempos de acceso a disco, o lo que tarda de media la unidad en posicionar la cabeza en el punto exacto donde se encuentran los datos, que es un valor tanto o más importante que la velocidad de lectura/escritura.

Al respecto de las velocidades, y como bien apuntaba iarenaza, existen muchas velocidades diferentes en las especificaciones de los discos duros. Tenemos la velocidad del interfaz de discos, que en el caso de UDMA100 alcanza ráfagas de 100 MB/s (no sostenido). Luego está la velocidad a la que se puede leer datos desde los platos del disco, limitada por la velocidad de giro del mismo, la densidad de pistas, etc. Tenemos la velocidad de acceso a la caché del disco, que si bien pequeña en tamaño (un par de megas) puede dar grandes mejoras si los datos accedidos habitualmente son siempre los mismos.

Y tenemos la velocidad del bus PCI, que es por donde van los datos desde/hacia los discos (al menos antes era así, no sé si ha cambiado con los chipsets más recientes, habitualmente de 125 MB/s (bus de 32 bits a 33 MHz). Y por último está la velocidad de lectura desde la "buffer cache" de Linux (lo que sale al usar "hdparm -T /dev/hda").

En resumen, que juegues (con cuidado) con hdparm y conseguirás mejores prestaciones de tu disco. Lamentablemente la lentitud de ciertas aplicaciones es inherente a las mismas, y no hay mucho que como usuarios podamos hacer. ¿ Alguien se anima a trabajarse una noticia acerca de las técnicas de "prelinking" que supuestamente ya están dando ganancias de velocidad en determinadas aplicaciones :-) ?

[ Padre ]


Pues no mejora mucho (none / 0) (#9)
por Zephryn Xirdal (zephrynxirdal(ARROBAR_A)telefonica.net) a las Sat Aug 24th, 2002 at 03:14:34 PM CET
(Información Usuario)

Mis opciones para el hdparm son "-c1 -d1 -Xudma5 -m1 -u1 -w1", y la verdad, en pico llega a los 25 Mb/s pero va bajando hasta quedarse en los 6 sostenida (copiando con el MC un fichero de 600Mb de /root a / que estan en el mismo disco duro.

En el kernel tengo activado "Ide ATA-2", "Generic PCI", "Sharing PCI IDE", "Generic PCI busmaster DMA", "Use PCI dma by default" y "VIA 82Cxxx", que es el soporte de mi chipset.

¿Se me olvida/escapa algo?

Desde luego, "UDMA Suppor" o parecido no lo encuentro por ningun lado. Kernel 2.4.19 (gentoo-sources)

[ Padre ]


 
Sobre discos y buses (none / 0) (#10)
por Anónimo a las Sun Aug 25th, 2002 at 05:13:33 PM CET

Aqui me gustaria hacer un par de apreciaciones. Una, si bien es verdad que jugando con el hdparm, se pueden conseguir algunas mejoras, el kernel de linux suele establecer correctamente estos parametros (hablo por experiencia propia), si bien he visto algunas cosas "raras". En cuanto a la velocidad del bus de los discos, es relativamente poco importante, ya que el que limita es la velocidad del bus del chipset; por ejemplo, si nuestro chipset soporta una velocidad de 100 MB/s, significa que el caudal máximo de datos que conseguiremos con los dispositivos conectados a el sera de 100 MB/s (que me corrijan si me equivoco).
Después comentar que estoy leyendo cifras muy bajas, en mi caso os pongo las mias:
/dev/hda:
Timing buffer-cache reads: 128 MB in 0.51 seconds =250.98 MB/sec
Timing buffered disk reads: 64 MB in 1.61 seconds = 39.75 MB/sec
Los discos son unos Seagate de 40 GB a 7200 rpm y con 2 MB de cache conectados en una controladora Promise.
Estos datos los he contrastado copiando archivos de gran tamaño que no estubiesen en cache, y concuerdan con los resultados de hdparm.
Como conclusión y en lo que estoy muy de acuerdo, en que el mejor gasto que le puedes hacer a un ordenador es en discos duros rápidos (ya que ahí está el cuello de botella) y bastante RAM, en vez de "megaprocesadores".
Un saludo.

Darkblood

[ Padre ]


 
Totalment ede acuerdo (none / 0) (#2)
por timeo (cepheidas@gmail.com) a las Fri Aug 23rd, 2002 at 04:28:52 PM CET
(Información Usuario) http://www.cefeidas.homelinux.org

Pues eso: que comparto plenamente la opinión vertida más arriba.

En modo gráfico Linux consume muchos recursos. Con 128 Mb de RAM y una tarjeta Trident BladeD3 de 8 Mb, Mozilla y StarOffice sobre WindowMaker corren como tortugas, y las pantallas se repintan leeentamente.

Esta es la salida de un <free -t>:
total used free shared buffers cached
Mem: 128364 122588 5776
57584 2620 47764
-/+ buffers/cache: 72204 56160
Swap: 248968 32428 216540
Total: 377332 155016 222316

Espero con ansiedad el frame buffer con gtk. Aunque esto no constituye más que un parche al problema de fondo: X Window.


Saludos.
-- timeo


X ligeras (none / 0) (#5)
por NoP a las Fri Aug 23rd, 2002 at 06:35:52 PM CET
(Información Usuario)

Espero con ansiedad el frame buffer con gtk. Aunque esto no constituye más que un parche al problema de fondo: X Window.

Has dado en el clavo. Hace falta unas X capadas (a lo mejor sin soporte de usarlas por Red) y más rápidas y ligeras...

¿Que ha sido del Berlin?



saludos!



[ Padre ]


Re: X ligeras (none / 0) (#7)
por timeo (cepheidas@gmail.com) a las Fri Aug 23rd, 2002 at 07:10:54 PM CET
(Información Usuario) http://www.cefeidas.homelinux.org

El Proyecto Berlín continúa desarrollándose, pero no sé cuánto le falta para estar maduro.

Por otra parte, esto plantea una cuestión que ha generado threads kilométricos en otros foros: ¿hasta qué punto conviene dispersar esfuerzos? ¿No es más conveniente trabajar sobre las X en vez de hacerlo en un proyecto nuevo?

Yo me inclino por la idea de modificar las X, en vez de andar reinventando la rueda.

Saludos.
-- timeo
[ Padre ]


Y la solucion? (none / 0) (#11)
por NoP a las Mon Aug 26th, 2002 at 09:44:57 AM CET
(Información Usuario)

Lo que realmente me fastidia es que pase como en muchas discusiones en barrapunto. Si, nos "quejamos" pero al final no se hace nada ni se llega a ninguna conclusion. No es posible hacer un clon ligero de las X y que sea compatible con los programas existentes (y mucho menos con los que acceden a bajo nivel), asi que la unica opcion seria tirar hacia algun desarrollo de ventanas/grafico ligero para consola/framebuffer/svgalib y adaptar un par de aplicaciones a ella: sylpheed para correo y news, abiword para escritorio, etc (como veis me baso en GTK, que creo que se adaptaria mejor a estos equipos).

¿Alguna otra opcion?



[ Padre ]


 
Pués yo no lo tengo tan claro (none / 0) (#12)
por Draco a las Mon Aug 26th, 2002 at 08:33:00 PM CET
(Información Usuario)

Para mi las X no son un problema, sino una bendición. Con el 486 de JulHer haciendo de X-terminal se puede conseguir que uno de los maquinones que se venden ahora no quede desaprovechado. Conozco gente(que usa Windows), que tiene un 486 o un Pentium-I en el armario mientras se pelean por el AMD-1700+ con 256 de RAM para leer el correo o hacer un trabajillo. Usando eso racionalmente, dos personas podrían emplear a la vez la misma máquina que tiene una carga de 0.1 la mayoría del tiempo.

Las aplicaciones que has nombrado van lentas porque son grandes. StarOffice va lento donde lo pruebes. Yo lo he abierto en un UltraSPARC-IIi 360MHz con 320 Mb RAM con Solaris(para mi solito en ese momento), y le costaba un verano. Ídem en Windows98, un poco más rápido que en Linux tal vez, pero poco más. Con mozilla pasa algo parecido....

Sé que me diréis, ¿y que pasa si no estás en red?. Pero joder, Linux o FreeBSD para bien o para mal siguen siendo UNIX. Y precisamente UNIX nació como un sistema operativo para desarrolladores, diseñado para estar en red y dar servicio a mucha gente. No le pidamos peras al olmo. El problema no son las X en sí, el problema es que usamos como escritorio algo que no se diseño para serlo...

Bueno, eso es lo que yo pienso...
There are two major products to come out of Berkeley: LSD & BSD Unix. I don't believe this to be a coincidence.
[ Padre ]


 
PPC (none / 0) (#13)
por pj (postmaster@localhost) a las Mon Aug 26th, 2002 at 10:35:10 PM CET
(Información Usuario) http://blog.mobiplayer.com

Ahora uso Linux en un PowerPC y la verdad es que me ha sorprendido que vuele, tanto Debian como Gentoo.
La verdad es que el OSX es muy bonito y tal pero Aqua se arrastra más que las X. Estas en OSX también vuelan, aunque tengas Aqua por debajo... Una gozada :)
Con una máquina de estas y algun P100 haciendo de terminal gráfico tienes ordenador para toda la familia jeje

P.D.: Es un G4 800Mhz



 
fiuuuuu ! (none / 0) (#14)
por runlevel0 (exterATvullferPUNTes) a las Mon Aug 26th, 2002 at 10:39:45 PM CET
(Información Usuario) http://perso.wanadoo.es/exter

> yo pregunto a los afortunados poseedores de
> pentiums IV y Athlones XP con toneladas de
> Ram... ¿vuelan?

Sipe, vuelan.
Athlon 1GHz+320 de Ram y vuelaaaaaaaa!!!!
Y los renders con pov-ray a 800x600 con radiosity, antialias 0.1, profundidad de trazado 16... 20-30 minutos, uno normal a profundidad 3 y antialias 0.2 ni 10 minutos.
Para hacerte una idea; en mi viejo Pentium 166 overclockeado a 180 con 64M de Ram tardaría de 17-48 horas ! (17 es mi record en un render).

Y con optimizaciones en las X ¡la velocidad de la luz! (recompilando sencillamente de src.rpm con "--target athlon" y se activan las extensiones 3D_NOW).

Ah, y sigo teniendo el P166 con la Potato y un P120 (creo que tenía potato tb, ahce ya que no lo uso).


-- S41002


 
MicroWindows (none / 0) (#15)
por NoP a las Wed Aug 28th, 2002 at 11:08:40 AM CET
(Información Usuario)

Acabo de ver esto:

http://www.microwindows.org/

¿que opinais?





 
¿En donde usas tu Linux? | 15 comentarios (15 temáticos, editoriales, 0 ocultos)
Ver: Modo: Orden:

ecol Logo Powered by Scoop
Todas las Marcas Registradas y copyrights de esta página son propiedad de sus respectivos dueños.
Los comentarios son propiedad del que los escribe.
Los iconos de las noticias y el logotipo son propiedad de Javier Malonda.
El Resto © 2002 Escomposlinux.org y aledaños.

Puedes sindicar los contenidos de libertonia en formato RSS 1.0 y RDF 0.9. También se puede sindicar la cola de envíos pendientes de moderación.

El proyecto escomposlinux.org está dedicado a la memoria de tas

crear cuenta | faq | búsqueda