Junto con ello la solicitud consideraría que el video emitido consumiera la menor cantidad de recursos de CPU en el usuario final.

La Solución:

Para este requerimiento nuestro equipo realizó la correspondiente migración desde la antigua y venerable tecnología soportada (Windows Media) instalando los programas, encoders y plugins necesarios para transmitir con codificación H.264 y audio de alta eficiencia HE-AAC mediante estéreo real (no paramétrico) y con escalamiento en módulo 16 para sacar máximo partido de el resize en el cliente.

Para ello Grupo Z trabajó estrecha y diligentemente con el equipo técnico, de redes y el personal encargado de gestionar la nueva web de MEGA en la integración del video para que el mismo se reprodujera mediante un player previamente adquirido.

El Resultado:
El logro técnico considera un modelo de utilidad propietario para una señal de pixeles rectangulares con un aspecto visualmente atractivo de 3:2 sobre una señal 4:3 que consume un 25% menos de ancho de banda que la de canales competidores y que sin embargo tiene una densidad en bits*pixel/frame idéntica o superior.

Esto significa que bajo nuestro esquema, es posible atender con igual cantidad de recursos a una mayor cantidad de usuarios sin sacrificar en lo absoluto la calidad de video (que de hecho es visualmente superior a la de otros medios) y en suma, ofrecer al usuario una imagen levemente anamórfica calculada para ello.

Adicionalmente entregamos una nueva plataforma de estadísticas avanzadas que muestra información porcentual de cambios en sintonía, transferencia, usuarios conectados y gráficas dinámicas consultables junto con una sistema dedicado de almacenamiento NAS en RAID-10 para todo el material de video “on demand” del canal y un grupo de servidores de nuestra red de distribución de contenidos que fueron preparados para alojar la nueva web en transito de desarrollo (actualmente online en el siguiente enlace) CLICK AQUÍ

La solución:
Monitorización y separación de ancho de banda dedicado para el evento, preparación de sistema de estadísticas consolidadas para control y habilitación de red Origin/Edge en la R.D.C de Grupo Z.

El resultado:
Todos los eventos deportivos correctamente servidos, balanceo de carga Grupo Z – CHV y más de 6.000 usuarios de video simultáneos online.

Normalmente en nuestro país se ha establecido la condición “de facto estándar” que asigna a los sistemas RAID-5 el estatus de “mejor alternativa de almacenamiento” por sus características de redundancia y performance en lectura respecto de otros modelos de RAID, lo cual históricamente se ha hecho tomando como consideración fundamental el bajo costo por Gigabyte inherente a este modelo versus el almacenamiento ligado a los esquemas con redundancia completa y directa como el RAID-10.

Pero antes de comenzar la batalla hagamos una descripción general de estos esquemas y qué ofrece cada uno de ellos.

Los contendores muestran sus dones!

1.- Capacidad (CA):

Dentro de los esquemas redundantes el RAID-5 es una de las mejores alternativas en términos de uso del espacio de almacenamiento entregando una capacidad útil (CU) igual a la capacidad del la suma nominal de la capacidad de todos los discos (S) multiplicado por la cantidad de discos (CD) menos uno, todo dividido por la cantidad de discos.

CU = S*(CD-1)/CD

Por su lado el RAID-10 es simplemente un doble espejo de RAID-1 (también llamado RAID1+0 pues hace un “stripe” de dos espejos RAID-1) lo cual implica que el almacenamiento efectivo de un arreglo cualquiera es la suma de todas las capacidades de los discos divididas por dos.

CA = (Cd1+Cd2+Cd3+Cd4)/2

Donde Cdx es la capacidad de un disco cualquiera en este ejemplo de un arreglo de cuatro discos

En general tenemos que el espacio aprovechable para un arreglo clásico de 4 discos (por ejemplo con unidades de 600 GBytes) es, en el RAID-5 hasta un máximo de 1.800 Gbytes y en el RAID-10 solo de 1.200 Gbytes.

2.- Redundancia:

La forma en que un RAID-5 maneja las paridades ha resultado históricamente compleja de entender para la mayoría de los administradores de redes. Una forma simple de explicar el modo en el que se distribuye la información, es entendiendo el algoritmo “round robin” que almacena los datos de manera alterna y ordenada con una paridad saltando consecutivamente de un disco al siguiente cuando se suman datos al registro.

Se entiende entonces que el RAID-5 puede presentar fallas sin perder integridad – en uno y solo uno de sus discos – en tanto que el RAID-10 puede tolerar hasta dos fallos, siempre que ellos no estén en el mismo sub-espejo del sistema (o span físico).

3.- Velocidad secuencial (MB/s o MBps):

Suponiendo que se ha elegido un adecuado “strip size” para el formato de los discos tenemos que el RAID-10 puede ser hasta un 50% mas lento que el RAID-10. En tanto que en la escritura el RAID-5 sufre de un importante perjuicio, debido al cálculo de paridad que se realiza por la unidad reguladora de disco antes de localizar la redundancia en el arreglo.

4.- Velocidad random (IOPS):

Siguiendo la misma premisa de tamaño de bloques y política de lectura de datos ambos esquemas proveen de un desempeño similar (en general un 10% mas bajo para el RAID-10) y en el caso de la escritura el RAID-5 sufre de pérdida de velocidad por los mismos efectos que se heredan del modelo de paridad distribuida descritos en el punto anterior.

5.- Uso de recursos:

Usualmente encontraremos que los servidores, NAS, DAS y sistemas de almacenamiento para propósito VOD de alto nivel siempre descansarán el cálculo de paridad y control de unidades lógicas sobre una o dos controladoras de discos. Serán ellas quienes asumirán la mayor parte de la carga transaccional dejando el procesador del servidor (en caso que se esté usando uno) libre para operaciones de proceso general.

Esto, de todas formas no quita que los esquemas de RAID-5 sean reconocidos por su uso intensivo de recursos de cálculo de paridades, elemento que es completamente ajeno al RAID-10 pues en él se escriben los datos de manera directa sin cálculos en tiempo real.

En general, el concepto de aplicación de un sistema crítico para Grupo Z se basa en el siguiente precepto: “Los sistemas de almacenamiento no solo se evalúan por cómo se comportan cuando funcionan sino también cuando fallan pues algún día podrían hacerlo…”

DATOS A CONSIDERAR:

En general un RAID-5 resulta ser entre un 8% a un 10% más veloz que un RAID-10 en lectura tanto secuencial como aleatoria para archivos de video. Esto sin embargo no significa que el RAID-10 sea siempre mas lento que el RAID-5 ya que para todos los otros tipos de aplicaciones tales como son el webserving, las bases de datos, los servidores de correos e incluso el live streaming el RAID-10 supera al RAID-5 por un margen que oscila entre un 5% a un 90%

Por la naturaleza compleja del RAID-5 e independientemente de los algoritmos de corrección de errores, la tecnología involucrada en la confección y manufactura de los discos de clase empresarial y sus indemnizaciones (entre las cuales se encuentran los algoritmos TLER, los sistemas de aislamiento para vibraciones en configuraciones de múltiples discos e incluso las garantías extendidas de hasta 5 años) siempre existe la posibilidad de que la controladora o uno de los discos “comience” a fallar de manera sutil y esporádica devolviendo datos corruptos.

Este error es conocido en la industria como “falla parcial de medios” y en algunos casos puede no reportarse de manera adecuada al sistema operativo, lo que deja espacio para datos catastróficamente perdidos, fallas no recuperables e interminables dolores de cabeza (que con suerte no nos despertarán a mitad de la noche).

La posibilidad de falla natural y mínima de un RAID-10 es por concepto 50% menor al del RAID-5 pues se necesita que dos discos fallen simultáneamente en el arreglo y ellos estén en un mismo espejo (lo que disminuye aún más la probabilidad).

En estado degradado un RAID-5 pierde hasta un 70% de performance tanto en lectura como en escritura en tanto que un RAID-10 pierde menos de un 8%.

Dada la baja de performance en estado degradado, el RAID-5 debe forzar sus recursos para poder atender la misma concurrencia VOD, por tanto, los discos restantes pueden fallar en línea mientras el RAID está en este estado. Particularmente el punto más delicado ocurre con la sobredemanda de IOPS si el equipo de almacenamiento es productivo y se solicita la reconstrucción del arreglo  en un momento de alto tráfico.

En comparación un RAID-10 no sufre estrés más allá del producido por la copia de un disco a su correspondiente espejo, a diferencia del RAID-5 que debe reconstruir la información acudiendo a todos y cada uno de los discos sobrevivientes.

Los RAID-10 tienen ventajas administrativas que permiten dividir el arreglo, declarar un disco como inactivo (supongamos un mantenimiento programado) para hacer un backup del disco y luego pedir el regenerado del disco.

Adendum:

Es importante entender que los estudios de prestancia de los fabricantes de discos sobre sus sobre unidades de almacenamiento se hacen,  - para todos los efectos – siguiendo criterios que usan inferencia estadística, cosa que muchas empresas dedicadas al almacenamiento han malinterpretado erróneamente en las especificaciones MTBF y AFR como elementos “de ciencia cierta” que garantizan el comportamiento de la unidad.

Para el caso particular son conocidas las especificaciones de discos que aseguran 1.2 millones de horas de operación sin fallas ó MTBF (mean time between faliure) pero ellas solo indican que sobre una gran muestra de discos se sumaron todos los tiempos de operación y al momento de fallo se cronometró un tal o cual error.

Teniendo esto claro será más eficaz y real tomar nota de variables como son la AFR (Anualized Fail Rate) que indica el inverso MTBF o bien, dice en buen castellano que “de un grupo de cien unidades de discos se puede esperar un cierto porcentaje de fallas a lo largo de un año de uso estándar”.

El AFR es una variable que por lo general se mueve entre 0,4 y 1 lo que significa que si tenemos cien discos nos preparemos para que al menos 0,4 presenten un problema el primer año calendario de uso y que este número subirá conforme se vaya completando la vida útil de medio.

Muchos se preguntarán porque hemos insistido en hablar de discos en vez de sacar a colación las nuevas memorias SSD. La razón es simple! y es que el VOD tal cual está planteado aqui hoy requiere de cantidades de almacenamiento medidas en la escala de los terabytes y al menos que se trate de un proyecto que requiera de un altísimo performance no resulta económicamente viable pensar en estas tecnologías por el momento.

EN NUESTRO PROXIMO POST…

Los administradores de servicios de alta demanda y en especial aquellos que requieren del acceso a videos de la forma más veloz y económica que la tecnología pueda ofrecer han hecho uso de técnicas que explicaremos en un próximo análisis de nuestro Blog y que ejercitan prácticas de localización a través de la aplicación de tecnologías de grabación perpendicular, número de platos y adecuada ubicación de archivos en los cilindros de los arreglos RAID, de modo que se aprovechen las ventajas físicas ligadas a la densidad de data por unidad de área y la velocidad lineal tangencial en los extremos de los platos de los discos.

En esta misma dirección ya se han comenzado a desplazar nuevos modelos de aplicación sobre tecnologías consideradas como “estándares” de la industria y que subyacen en la capa más baja de producción a la hora de transmitir contenidos por la red – o en otras palabras – que tienen que ver con la codificación misma del material audiovisual antes del broadcasting.

Justamente el modelo del cual hablamos en esta oportunidad, tiene relación con una tecnología originada en las necesidades de la telefonía y que se soporta en los desarrollos de la ITU-T y la ISO/IEC bajo el ultra conocido y popular MPEG-4 Parte 10 – más famoso por su nombre de pila – H.264.

¿Y en qué consiste?

Funcionalmente hablamos de una nueva forma de encoding y decoding compatible con el estándar MP4 que permitirá en un solo archivo componer y descomponer diferentes capas de video a calidades variables.

Actualmente este concepto es completamente revolucionario y virtualmente “casi” no existen aplicaciones que soporten el nuevo esquema (salvo algunas versiones preliminares de Main Concept y Mederic Blestel con Mickael Raulet), a pesar de que hablamos de un protocolo estandarizado hace casi 5 años que ha esperado madurez y justificación para su estreno y desarrollo.

A diferencia de lo lejanamente más parecido con los archivos MP4/H.264 de Microsoft para Smooth Streaming donde existe una alternativa de paquetización de audio/video en un solo archivo ISMV, en este esquema tenemos escalabilidad en tiempo real sobre unidades tales como la cantidad de cuadros por segundo o los macrobloques que se dividen en pequeños ítems que integran la unidad llamada Granularidad.

La primera de estas unidades contiene el set básico de datos y los siguientes contienen los posteriores refinamientos

Desde un punto de vista técnico existen aquí dos capas a la misma cantidad de cuadros por segundo y la misma resolución espacial (ancho x alto) pero diferente eficiencia de cuantización. Mientras la capa base es decodificada por el decodificador de largo variable o VLD, el cuantizador inverso en esta base produce los coeficientes del coseno o DCT en la capa refinada (Los niveles más altos de la transformada del coseno y sus coeficientes son obtenidos sumando la base de los coeficientes reconstruidos y su correspondiente residuo refinado).

De manera “relativamente” similar se producen variantes en la escalabilidad temporal y de bitrate que tienen por objeto dinamizar la entrega del contenido descartando o añadiendo información en tiempo de ejecución.

El resultado práctico

Esto por ejemplo, significará que bajo “codificación escalable” en vez de realizar streaming dinámico acudiendo a 5 o 6 archivos de bitrate diferente a través de un archivo manifest lo que produciremos será un solo archivo de medios en el cual estarán todas las calidades por capas sin que ello haga que el archivo final sea la suma de todos los bitrates de cada una de las capas.

En el futuro mediato los sistemas SVC nos permitirán reducir los tiempos de producción de video en encodeo y brindarán características dinámicas a los usuarios de manera transparente en archivos que serán entre un 5 a un 10% mayores a los antiguos MP4 de mayor calidad y conservarán características de B Slices, CABAC y cuadros IDR que podrán ser decodificados sin referencia a cuadros previos.

Referencias:

Streamingmedia (En Inglés)

Datalux (En español)

Y es que desde la mirada más purista, el Streaming vía HTTP no es realmente Streaming del todo (o eso solían decir), pues adolece de una condición fundamental que muchos han aprovechado para objetar y detractar ciertas ventajas que de por si este sistema tiene.

1.- La historia de “La Persistencia”
Hasta la aparición de los primeros sistemas de Distribución Adaptativa, virtualmente todos los proveedores de servicios de radios online, TV en línea y video bajo demanda consideraban que hacer Streaming “Real” solo podía ocurrir bajo protocolos que establecían una contacto 100% permanente con el usuario, ergo, si la conexión caía o había fallos en la red producto de bajas en el suministro (o quizá simplemente porque alguien más en tu casa estaba descargando un torrent) la consecuencia era siempre un mensaje de “Buffer” junto con la correspondiente espera hasta que el sistema volviera a llenar el mismo

En este sentido las conexiones unicast de Windows Media Services representan un clásico y buen ejemplo de dicha persistencia…

Luego de algunos años y la aparición de protocolos propietarios como RTMP de ADOBE este concepto fue reforzado con un intenso sentido técnico en el marketing que intentaba diferenciar ambos sistemas de distribución sobre la base de “cómo se recibía” el Stream de datos por el usuario final y las ventajas que suponía la compleja secuencia de “piratear” los contenidos de audio/video ya que ellos se visualizaban en tiempo de ejecución y no había un caché de los mismos en el PC del receptor.

Sin desmedro de lo anterior muchos proveedores de Streaming malinterpretaron este sentido y despreciaron la venta del producto “no persistente” imputando a la distribución HTTP el nombre de “falso streaming” o en el mejor de los casos “pseudo streaming” con un discurso que tenía en su fondo, más que ver con la rentabilización de las inversiones en infraestructura de servidores/licencias ya realizadas por ellos, pues claramente era una pérdida de capital el darse cuenta que un simple y económico servidor web podía realizar “la pega” de llevar MUY BUEN video a los usuarios finales, quienes no protestarían por una diferencia funcionalmente insignificante para ellos (desde su punto de vista) ya que todos estábamos acostumbrados a pausar Youtube hasta que se terminara de cargar pues suponía una deficiencia atribuible a la red y nunca a quien proveía el video.

2.- La aplicación
Todos aquellos quienes trabajamos profesionalmente en tecnología sabemos que existe una cierta reserva de los usuarios mas “geek” (y quizá tengamos que incluirnos también) cuando Microsoft hace aparición en el mercado, especialmente con un nuevo producto como fue el caso de Silverlight, el cual tenía por destino quitarle protagonismo a Flash en el marcado RIA.

Habrá quienes digan que es por el monopolio, o porque simplemente “Bill” ya tiene demasiados millones de dólares en su cuenta, pero en verdad hay que conceder a MS el crédito que corresponde en la adopción, o quizá debería llamar a esto “el perfeccionamiento y puesta en escena” de una tecnología lógica, basada en el más auténtico sentido con la que está construida la red HOY, es decir, bajo una infraestructura mucho más amigable para hacer Streaming con HTTP híbrido de lo que todos creíamos.
En este instante ya TODOS los desarrolladores de aplicaciones de Streaming están trabajando en soluciones que permiten realizar verdadera distribución dinámica HTTP, algunos lo han tomado con bastante más reticencia y se han apegado tanto como les ha sido posible a sus viejos estandartes como veremos a continuación.

3.- Y que pasa con Flash Streaming HTTP?
Cuando alguien se refiere a Flash HTTP realmente está hablando de un sistema bastante particular donde el protocolo RTMP realmente se “disfraza” de HTTP con una técnica conocida como tunelización. Esta técnica funciona tanto para contenido en vivo y “on demand” motivo por el cual puede sufrir de un leve “delay” y abultamiento en su estructura de datos, cosa no siempre aceptable, especialmente cuando entre el servidor y el cliente existen redes proxeadas ó protegidas con firewalls donde hay analizadores de paquetes.

Según lo anterior, el protocolo de Flash Streaming está diseñado para realizar su distribución bajo TCP en vez del clásico UDP de la conectividad con protocolo RTSP.

Esta debilidad fue muy bien entendida por grupos internacionales como AKAMAI o Nokeena (Ahora Ankeena/Juniper) quienes se sustentaron de manera independiente en la misma API de Flash para realizar antes que nadie sus adaptaciones de streaming HTTP “real” y generar soluciones productivas en el patio trasero del mismo ADOBE.

El motivo es bastante simple y tiene que ver con la escala…
Y es que cualquiera que haya realizado los benchmarks correspondientes (nosotros los hicimos todos) sabrá que distribuir streaming Flash bajo RTMP requiere de una cantidad de hardware y potencia de procesamiento que crece en forma directamente proporcional a la cantidad de usuarios conectados (nada inteligente) y además necesita que cada servidor tenga instalada la serie completa de licencias de software con un costo poco despreciable en su conjunto.

Esto ha puesto a la casa ADOBE en una incómoda situación donde al final del día terminará ofreciendo un producto Flash 10.1 y Flash Media Server 4 que atentará directamente contra todo su esfuerzo en el método distributivo original y generará un nuevo espacio que requerirá de un sistema de protección de contenidos DRM Flash Access, necesario para limitar la desventaja que representa la entrega literal del contenido fuente al usuario final (lo cual no es chiste para los estudios y los dueños de los derechos).

Epíologo:
Sin duda período 2010-2011 será de grandes cambios en la forma en que veamos la entrega de audio y video en la red. Empresas como ADOBE han mostrado cierta resilencia a lo que viene pero será solo cuestión de tiempo para ver la adopción de estas nuevas tecnologías.

También veremos movimientos interesantes en los ISP así como en las CDN, proveedores de Streaming y productores de contenidos, quienes asumirán una carga no menor al tener que arreglárselas para encodear una cantidad considerable de material de manera técnicamente transversal, veloz y que no deberá implicar mayores costos junto con las tecnologías de protección DRM necesarias, quienes finalmente son los verdaderos ganadores de esta pequeña batalla entre dos hermanos algo distanciados por asuntos de “protocolos de familia”.

Si bien es cierto, hoy existen elementos que son comunes a todos aquellos quienes trabajamos profesionalmente en el mundo del Streaming (a pesar lo estrecho que esto suene), no es menos correcto que hay un cierto “know how” en cada empresa respecto de su encodeo de alto performance.

Sin desmedro de lo anterior, en Z estamos convencidos que el conocimiento distribuido engrandece al conjunto (algo así como que, “el todo el más grande que las suma de las partes”) y por eso hoy compartimos uno de los mejores secretos de la digitalización de video…

Sin duda una de las plataformas “clásicas” para distribución de contenidos durante la última década ha sido Windows Media Video y con justa razón Microsoft ha intentado darle tanta vida como sea posible a través de sus algoritmos propietarios de última generación VC-1 y WMA 10 Pro, destinados a competir directamente con los modernos h.264 y AAC.

A este último punto creo que es necesario hacer justicia sosteniendo que la estandarización ISO del antiguo y venerable WMV aún tiene varios rounds por luchar. Sin ir más lejos lo he visto personalmente en películas como King Kong o Dark Knight bajo Blu-Ray sin absolutamente nada que envidiarle a “los otros” codecs, principalmente porque arriba de 35 megabits por segundo la calidad final de un video depende de la experticia de quien configura los parámetros de digitalización y no de el algoritmo usado.

En este sentido siempre habrá quien pueda decir que las gráficas PSNR favorecen a los codecs más modernos, fundamentalmente porque son capaces de manejar mejor una matriz de cuantización o simplemente porque la percepción de color tiene más contraste…Para ellos vayan nuestros “diabitos” pues a nuestro juicio están en un error.

A manera de tutorial explicativo y para que quienes no han “exprimido” todo el poder de VC-1 les invitamos a probar este simple grupo de pasos para hacer Live Streaming con un PC convencional con XP y sorprenderse con la diferencia!

Paso 1: Alejate de Expression Encoder!

Infortunadamente MS no ha dado pié con bola en su última edición del codificador propietario, y es curioso porque a pesar de que en esta oportunidad el nuevo software si ha explotado características de multiproceso aún no tiene un manejo retro compatible con una gran gama de configuraciones internas que si podían manupularse en WME 9.

Paso 2: Baja los siguientes programas e instálalos -ya te explicaré porqué-

Windows Media Encoder 9: Es mucho más estable que Expression y permite customizar los parámetros perceptuales, filtros y B Frames desde un par de aplicaciones externas -te apuesto a que eso no lo sabías- XD.

Windows Media Player 11: Instalará los codecs más modernos sobre la base de los anteriores WMV y en definitiva harán que puedas acceder a las últimas optimizaciones suscritas a VC-1

.NET Framework 3.5: En pocas palabras, habilitará Power Toy.

WMV9PowerToy: Te permitirá acceder a los misteriosos parámetros del registro ocultos hasta hoy.

Paso 3: Instala todo en el orden descrito y configura los parámetros del Power Toy según se indica en la imagen adjunta.

Paso 4: Luego de estos pasos arranca WME 9 y configura en el menú desplegable de opciones la pestaña “Performance” la barra deslizante “When Broadcasting” un punto antes de llegar al extremo derecho (no está numerada pero si tuviera números sería la posición 4 de 5)

Este paso es MUY importante pues supone que debes tener un computador con un CPU suficientemente poderoso como para simular un segundo pass de codificación en vivo, lo que en buen “Chileno” significa que será mejor pensar en un procesador de 4 cores para esta tarea (por precio y rendimiento recomiendo ampliamente un Athlon II 630 con placa que soporte ACM).

Paso 5: Codifica!
Podrás comprobar una diferencia sustancial respecto de tus otros encodings, en efecto a bajos bitrates aún podrás obtener mejor calidad de un buen trabajo con X.264 en h.264 pero por cierto que estamos hablando de cómo sacar el mayor partido de una plataforma existente.


Christian Avalos
Grupo Z

Los sistemas están instalados en tres portátiles diferentes, con su última versión y completamente actualizados. Los concursantes son todos hackers con mucho renombre y expertos en seguridad que luchan por quedarse el portátil y un premio económico de 10000 dólares. Leopard se ejecutaba sobre un Macbook Air, Ubuntu 7.10 sobre un Sony Vaio y Windows Vista en un Fujitsu.

El primer día sólo se permitían accesos mediante la red, y nadie consiguió entrar a ningún sistema. Lo más chocante fue que Mac OSX Leopard fue el primero en caer en cuanto se permitió acceder a los sistemas para hacer cosas como visitar páginas web. Charlie Miller tumbó el portátil de Apple aprovechando un bug del navegador Safari. Windows Vista aguantó el empentón hasta el último día, hasta que Shane Macaulay consiguió hackearlo. Ubuntu Gutsy permaneció intacto hasta el final, aguantando como un campeón.

No es un concurso del que se deban extraer muchas conclusiones sobre la seguridad en general de los tres SO, tan sólo intenta descubrir nuevos agujeros y forzar a las empresas a solucionarlos cuanto antes. Los tres sistemas se exponen a varios expertos que desarrollan aplicaciones y métodos para tomar el control usando alguna vulnerabilidad, y que intentan hacerlo lo más rápidamente posible para llevarse el premio. Por tanto, hay que tener cuidado con las conclusiones que se sacan y no pensar que el hecho de que hayan hackeado antes Mac que Ubuntu no significa que Ubuntu no pueda tener muchísimos más agujeros de seguridad, sólo que no han querido desarrollarlos o era más rápido hacerlo para el otro sistema… o simplemente que al hacker le gustaba mucho más el Macbook Air que el Sony Vaio.

El profesional Alfredo Barriga (Licenciado en Ciencias Económicas y Empresariales de la Universidad Complutense de Madrid y MBA de la Universidad de Navarra) fue nombrado nuevo secretario ejecutivo de Estrategia Digital del Ministerio de Economía en el Gobierno de Sebastián Piñera.

El cargo que anteriormente ocupó Enrique Evans pasó a engrosar el currículum de este miembro del Grupo Tantauco. El profesional de 55 años deberá llevar adelante las políticas públicas para permitir el desarrollo de las tecnologías de información como un eje impulsor del progreso de Chile.

En una entrevista realizada en la edición de marzo para la revista Puntonet de la web Terra, antes de ser nombrado en el cargo, Barriga delineaba que uno de los compromisos más importantes de la entidad consiste en extender el acceso a la banda ancha en el país, a través de un subsidio que permita dotar de una conexión expedita de los hogares que hoy se ven limitados por el costo del servicio.

Otras misiones previsualizadas por el encargado de Desarrollo Digital son aumentar de 75 a 300 la cantidad de trámites de gobierno que pueden realizarse vía electrónica, llevar la tecnología a las salas de clase (con el anhelado proyecto un computador por alumno), aplicar la informática al ámbito médico y al trabajo entre otros.

En la misma entrevista, el ahora encargado digital del gobierno propone dividir la Subsecretaría de Telecomunicaciones en un ente fiscalizador y otro promotor de las herramientas digitales a la que podría adscribirse la unidad informática que dirige desde hoy.

Fuente: La Nacion

Esta situación multiplicó la demanda de video en vivo ya existente en un 750% en solo un par de minutos con miles de peticiones a los sistemas “director” y broadcasting.

La solución:
Habilitación de EDGES adicionales en la R.D.C de Grupo Z, monitorización de servicios y balanceo.

El resultado:
90% de la demanda mensual cubierta sin problemas en solo 5 horas de servicio!