lunes, 26 de enero de 2015

Mejor un viaje que muchos

Optimizar el modo en que transferimos datos

Cuando niño, pese a la insistencia de mi madre en denominarme “niño fuerte”, la realidad es que estaba más redondo que Naranjito. Era un “gastamuelas” de cuidado y eso se podía comprobar en mi forma de actuar. Por ejemplo, los quicos (maíz tostado para los puristas) me encantaban y yo aplicaba mi propio mecanismo de consumo. Eso de abrir la bolsita, coger unos pocos, llevarlos a la boca y repetir el proceso no era para mí. Era ineficiente a todas luces. Mejor abrir bien el envase y volcar en mi boca todo el contenido posible de una vez (limitado principalmente por la elasticidad de mis mofletes). Cualquiera hubiese dicho que daba el perfil de programador. 

Stopppp… programadores enfurecidos. No me refiero a que el perfil de programador sea el de un ansioso zampabollos, quiero decir que tenía una tendencia a la optimización. Pues bueno, programador no fui (al menos profesionalmente), pero ciertamente alguna correlación podremos encontrar entre aquello y algo muy común en la programación de autómatas, el intercambio de datos entre dispositivos. Veremos que es mejor intercambiar muchos datos de golpe que poquito a poco. 

Si repasamos por ejemplo la construcción de una trama Modbus en ASCII nos encontraremos que está compuesta por lo siguiente. 

- Inicio de trama: 2 caracteres ASCII ( que representan 1 byte ) codificando el caracter “:” (0x3A) 

- NºEsclavo: 2 caracteres ASCII codificando la dirección del esclavo destino ( u origen ) de la trama 

- Código Operación: 2 caracteres ASCII con el código de operación 

- Dirección, datos y subfunciones (los parámetros necesarios para realizar la operación). 

- CRC(16): H L, 2 caracteres ASCII 

- Final de trama: 4 caracteres ASCII con los caracteres CR (0x0D) - LF (0x0A) 

La mayor parte de la trama es de longitud fija, pero el segmento destinado al intercambio efectivo de datos puede ser variable. Esa variación es debida a que en una única petición podemos solicitar leer o escribir datos de una única variable o un conjunto de las mismas. Veamos un ejemplo con el intercambio de mensajes al solicitar una lectura de 3 registros.

PETICION de 3 datos:
Nombre del campo
Caracteres ASCII
Cabecera
:
Dirección esclavo
“06”
Función
“03”
Direccion inicio Hi
“00”
Direccion inicio Lo
“6B”
Num de Registros Hi  
“00”
Num de Registros Lo  
“03”
Error Check
LRC ( 2 caracteres )
Fin de trama
CR LF
Total:
17 bytes

RESPUESTA con los 3 datos:
Nombre del campo
Caracteres ASCII
Cabecera
:
Dirección esclavo
“06”
Función
“03”
Numero de bytes de datos 
“06”
Dato 0 Hi
“02”
Dato 0 Lo
“2B”
Dato 1 Hi
“00”
Dato 1 Lo
“00”
Dato 2 Hi
“00”
Dato 2 Lo
“63”
Error Check
LRC (2 caracteres )  
Fin de trama
CR LF
Total:
23 bytes


Si observamos la respuesta vemos que en una única trama hemos recibido el contenido de las 3 variables. Esto es sumamente interesante desde el punto de vista de optimización dado que la trama “triple” de respuesta es mucho más corta que la suma de 3 tramas de respuesta única. No solo “economizamos” en la respuesta ya que también lo hemos hecho en la petición. Si necesitamos 3 registros y los recuperamos de 1 en 1 hubiésemos tenido que realizar 3 peticiones enviando así el triple de caracteres ASCII. Veamos la comparación. 

Petición en 3 tramas de 1 registro: 17 bytes x 3 (petición) + 15 bytes x 3 (respuesta) = 96 bytes 

Petición en 1 trama de 3 registros: 17 bytes (petición) + 23 bytes (respuesta) = 40 bytes 

Como veis tenemos un “ahorro” en bytes de aproximadamente el 60%. Además es un ahorro incremental, cuantos más registros necesitemos, más optimizamos si empaquetamos en una sola trama. 

Pero claro hay un evidente requerimiento, los registros sobre los que queremos trabajar han de ser consecutivos. Y es ahora cuando viene la moraleja de la entrada de hoy: 

Cuando tengamos que realizar un proyecto en el que se intercambien variables es importante tener en cuenta la conveniencia de ubicar de manera consecutiva los registros a intercambiar. 

El ejemplo lo he descrito en base al protocolo Modbus, pero el concepto es perfectamente válido para muchos otros protocolos. Una de las ventajas evidentes de tener esta particularidad en cuenta será que nuestras comunicaciones serán más rápidas y eso repercutirá en un polling más fluido entre estaciones en caso de existir. Otra ventaja será económica en el caso que la transmisión de datos conlleve un cargo (como por ejemplo en algunas aplicaciones GPRS M2M). 

Y tranquilos vuestros autómatas no se hincharán por tragarse de golpe todos esos bytes. Eso quedó para mí y mis quicos, que mi trabajo me costó luego quitármelos de encima. De todos modos y para evitar trifulcas, si coincidís conmigo y estáis degustando unos sabrosos frutos secos, mejor no me ofrezcáis. 

Hasta pronto.

No hay comentarios:

Publicar un comentario

cookieassistant.com