Volver a la portada de Duiops
Volver al Web de Duiops
 
   
Google
 
En Internet En duiops.net
Menú
Secciones destacadas
Artículos y FAQs
Trucos de Windows
Versiones de Windows
y suites de software
Windows Vista
Windows Media Center
Windows XP
Windows 2000
Windows Millenium
Windows 98/98 SE
Windows 95 OSR-2
Internet Explorer
Office
Otros
Tutorial muy básico
   
Portada

 

Apúntate a la lista de correo del Web de Duiops

Portada - Artículos y FAQs - Discos IDE - El misterio de la UDMA (parte II)
 
Discos IDE - El misterio de la UDMA (parte II)

 

Por Jose Manuel Tella Llop, extraído de microsoft.public.es.windows98

BUSMASTER DMA
-------------

Otra forma del Direct Memory Access es el Busmaster DMA, pero este no tiene nada que ver con el chip de DMA, integrado en la placa madre, y del acual hemos hablado anteriormente.

En este tipo de acceso, la controladora del dsco duro, desconecta a la CPU del BUS y transfiere los datos con ayuda de un controlador Busmaster DMA con control propio.

De esta manera se pueden conseguir tasas de transferencia de has 8 mb/seg. Busmaster DMA solo se empleaba en el caso de controladoras SCSI.

UDMA
----

No lo he mencionado al principio del articulo, debido a que no es nada mas que una variante del Busmaster DMA, implementada en controladoras IDE y aumentada su velocidad de transferencia a 16 MB/s. Posteriormente surgió la UDMA 2 (o UDMA 33) hasta 33 megas/s. Y actualmente ya se estan vendiendo placas madre con controladoras incorporadas a 66 MB/seg.

NO LLEVARSE A ENGAÑO
--------------------

No hay que llevarse a engaño con todo lo anterior. En las controladoras / discos actuales, ambas cosas forman un TODO. Es decir, no solo el chip de la placa madre debe soportar esa velocidad, sino que tambien el propio dispositivo (la electronica del propio disco duro), debe soportarla. Es decir un disco UDMA actual (UDMA 2) por mucho que lo pongamos en una placa madre con controladora UDMA 66, no dará mas rendimiento que el que daba en una UDMA 33.

GOODBYE AL MODO PROTEGIDO
--------------------------

Como colofón de esto, voy a hacer unos pequeños comentarios de diseño del propio núcleo del sistema operativo, en relacion con los metodos de acceso anterior.

Recordad que existen dos modos de funcionamiento del procesador. El modo "real" que es el modo en MSDOS puro y duro, con el limite de 640 Ks en memoria contigua y el limite de 1 mega + 64 Kb para todas las direcciones reales. Y el modo "protegido", en donde se tiene acceso a toda la memoria de la maquina, y es el modo en que funciona Windows,linux, OS2, etc...

Las formas vistas antes de transferencia DMA, solo se pueden utilizar en el mundo del modo Real (Real-Mode), y llevan al procesador a un "cuelgue" si no se toman las medidas adecuadas.

El problema es la gestion de memoria virtua, que se representa los la Memory-Management-Unit (MMU) de la CPU. Es el encargado de formal las direcciones virtuales para los programas que trabajan en modo protegido y proyectarlas sobre las direcciones verdaderas (fisicas) en la memoria.

Pero de esto, los programas no se enteran, ya que nunca entran en contacto con las direcciones fisicas, y el controlador de DMA no es una excepción: tampoco se entera, ya que no tiene acceso a la MMU de la CPU.

Esta problematico, no solo suerge en Windows y otros sistemas en modo protegido. Tambien afecta al MSDOS cuando este está trabajando o conmuta a modo Virtual-86 (el tercer modo de funcionamiento del procesador). Por ejemplo en cuanto instalamos el EMM386.EXE en el config.sys que sirve para la emulacion de la memoria expandida y que depende de la gestion de la memoria virtual del procesador.

Solo hay un modo de evitarlo, y es la vigilancia de la controladora DMA. Esto es posible en modo protegido mediante el control de los ports I/O (virtualizacion del hardware). Así por ejemplo, Windows instalar un Control-Monitor virtual en el fondo (en la capa mas baja), que vigila la programacion del controlador DMA, mediante la BIOS o un programa, y que convierte las direcciones virtuales indicadas en direcciones fisicas verdaderas antes de que se escriban los registros del controlador DMA (antes que se programe una lectura/escritura)

***********************

Y como introducción curiosa para un posible siguiente articulo.... ¿alguien ha pensado como se escriben los datos en un disco duro?

La problematica es la siguiente, las informaciones se guardan en la superficie de un disco duro, bien, en principio hemos de olvidar que se guardan en representacion binaria.

No se pueden guardar unos y ceros con ayuda de particulas "magnetizables", ya que en ese caso, se habrían de reflejar los dos estados "magnetizado" y "no magnetizado" para los valores 0 y 1. Pero precisamente esto no es posible, tal y como introducimos a continuacion.

Si se siguiera la prpouesta anterior, la secuencia de ceros y unos apareceria como secuencia de particulas magnetizadas y no magnetizadas. Pero con ello el cabezal de lectura del disco no podría distinguir las difernetes particulas magnetizadas de esta secuencia. Así no se sabría si estamos tratando con 6 o con 9 ceros, por ejemplo.

En esta situación, solo nos serviría de ayuda si el cabezal de lectura supiese la "longitud" de una particula magnetica, pudiendo poner entonces el tiempo transcurrido entre una particula y otra en funcion de la cantidad de particulas magneticas y con ello la relacion de los bits. Así, se necesita una especie de "pulso" de reloj que con cada impulso indique que ha llegado el tiempo de un nuevo bit.

Pero el tiempo constante, que se necesita para la creación de un pulso, no se puede determinar con exactitud a causa de diferentes factores. La culpa la tiene por ejemplo la velocidad de rotacion de un disco duro, que dentro de ciertos limites, siempre varía, así como el echo de que nunca se puede magnetizar una unica particula magnetica, sino siempre todo un grupo cuyo numero no siempre es constante.

Bonito problema ¿no?. ¿como podemos hacer entonces, o como se las arregla el disco duro para guardar y ser capaz de recuperar?

**********

Pues para el siguiente articulo.....


Volver a Artículos y FAQs

 

     
 

Volver arriba Volver arriba

© 1997-2008 Duiops (http://www.duiops.net)
Prohibida la reproducción parcial o total de los textos o las imágenes

Para comentarios, usa las direcciones e-mail de contacto.