Menu Close

Category: Pruebas

El camino a 10 Gigabit

Pareciera que a donde mire, todos los chicos cool están hablando de la maravilla que es tener una red domestica a 10 Gb/s, basta fijarse en los resultados de YouTube cuando uno busca “10 Gigabit”:

Si no tenes LAN 10Gbps estas out vieja

10 Gigabit Ethernet hoy

Si bien 10 Gigabit Ethernet existe como estándar desde 2002 (con la ratificación de 802.3ae 17 años atrás, o sea, una eternidad), la realidad es que no se ha movido mucho fuera del mercado datacenter.

10GbE ya no es mas aquella vedette del networking dado que existen soluciones de 40Gbps y 100Gbps que tienen mucho mas sentido y por lo tanto esta apareciendo equipamiento 10GbE usado, lo suficientemente barato como para que YouTubers con plata entusiastas se tiren a probar 10GbE.

Para aquellos que no les gusta comprar usado, también están apareciendo soluciones de bajo costo, como el MikroTik CRS305-1G-4S+IN, a USD 149 (en origen, sumale envío y la usura de aduanas si vos también estas en Uruguay)

USD 37.45 + impuestos por jaula SFP+, a tener en cuenta que tenes que comprar los módulos.

Lista de compras

Esta muy copado esto de 10Gbps pero que uso podemos darle realmente dentro del hogar? Nada de cosas, vamos a ver primero en que podemos quemar el dinero y dejamos las excusas para después.

Supongamos que fuera a comprar todo lo necesario para probar esto de 10GbE, con el objetivo de conectar la PC de escritorio con el servidor que esta a 2 o 3 metros de distancia, dejando el resto de la red como esta, a 1Gbps.

Acá es donde se empieza a complicar, porque tenemos varias opciones y el precio varia considerablemente.

Uno pensaría que la opción mas simple y económica seria la de usar 10Gbps sobre cable UTP CAT6a (10GBASE-T, o sea el cobre de toda la vida). Sin embargo, por el costo de una placa PCI-E 10GBase-T se puede conseguir una placa con dos jaulas SPF+ y un modulo, lo cual deja abierta la posibilidad de agregar un segundo modulo en el futuro sin tener que cambiar nada.

(A esto sumale el hecho que muchos vendedores lamentablemente no saben lo que es el CAT6A, no lo importan o te quieren vender una mentira llamada CAT6e)

Pero ademas, por menos de lo que cuestan 2 modulos SPF+ y el patchcord de fibra podemos ir por un DAC (“direct attach cable“). Al momento que escribo esto, estaríamos hablando de USD 14,99 vs. USD 50,99. Para distancias cortas, la opción DAC es la mas económica:

La opción 10GBase-T parece la mas simple, pero es aprox. USD 50 mas cara en nuestro escenario.

Si nuestro objetivo es simplemente agregar un enlace de 10Gbps entre dos equipos, ya tenemos todo lo necesario para salir a comprar, nuestras dos opciones siendo:

  • CAT6a: patchcord + 2x placas de red = aprox. USD 200
  • Direct-Attach SFP+: DAC + 2x placas de red = aprox. USD 153

Pero, podemos ir mas allá y en lugar de agregar un enlace, mejorar la conexión actual de 1Gbps a 10Gbps. Para esto, vamos a precisar comprar un switch.

Una opción siendo el MikroTik CRS305-1G-4S+IN mencionado al principio, cuesta unos USD 149 pero tiene la desventaja que nos limita a un solo uplink de 1Gbps para ambos equipos.

Otra opción seria algo como el Netgear GS110MX, que cuenta con 2 interfaces 10GBASE-T y 8 interfaces 1000BASE-T (o sea el Gigabit por cobre de toda la vida). Este producto se consigue por aprox. USD 250.

Netgear, yuck!

No convencido por ninguna de las dos, y sabiendo que traer usado de eBay estando en Uruguay es una timba, me puse a ver de nuevo el catalogo de MikroTik hasta que encontré que el CRS326-24G-2S+RM tiene todo lo que preciso quiero, y seria el candidato a remplazar mi actual CRS125 ya que:

  • Tiene la opción de usar tanto SwOS como RouterOS, por lo cual puede seguir haciendo de router acá en casa, tal cual lo viene haciendo el CRS125 [*1].
  • Viene con 24 interfaces Gigabit por cobre, al igual que el CRS125.
  • Viene con 2 jaulas SFP+, que es lo que precisamos para lo que pretendemos hacer.
  • Puede alcanzar el wire-speed teórico en lo que a switching se refiere (L2), en otras palabras puedo saturar el enlace 10Gbps entre las dos maquinas.
  • Esta listado a USD 199. Anda saber cuanto cuesta en Uruguay (si se consigue siquiera) pero considerando que la bosta Netgear cuesta USD 250, no esta para nada mal.

[*1]: El CRS-125 (o cualquier CRS de MikroTik) es un switch, no un router. No esta pensado como router, por mas que puedas usarlo como tal dado que viene todas las funcionalidades. Dependiendo de lo que hagas, el throughput te puede sobrar o todo se puede caer a pedazos.

Como dice la canción, Uruguay Latvia es el mejor paiiiis…

Dicho todo esto, nuestra lista de compras quedaría mas o menos así:

  • 2x HP 614203-B21, USD 138
  • 2x 10Gtek SFP+ DAC 3m, USD 30
  • 1x MikroTik CRS326-24G-2S+RM, USD 200
  • 1x Overhead de hacer que todo esto se materialice en la República Oriental del Uruguay (estimado pesimista): USD 253
  • Total: USD 621

Nota: si la haces bien podes traer todo bajo franquicia, incluyendo el CRS326 ya que según Honey, supo estar a USD 139 en algún momento en Amazon. Esto reduce considerablemente la cometa estatal a pagar.

Buscando una excusa

Bueno ya vimos que dependiendo de como la juegue, la joda me puede llegar a costar 600 dólares en el peor escenario o al rededor de 370 dólares si se me da. El tema ahora no es lo que cuesta, mas bien “si lo vale”.

La principal (y probablemente única) ventaja que obtenga al hacer esto es un acceso ridículamente rápido al almacenamiento en el server, cosa que uso al punto tal que no solamente documentos, fotos, música, videos, películas y series se guardan ahí pero también los vmdk de las maquinas virtuales y recientemente las descargas de Steam:

Salvo algún caso donde se justifica tener un juego en el NVMe, las descargas de Steam van a parar a una unidad de red. Parte de mi plan maestro de quitar los discos duros de la maquina de escritorio y dejar solo el SSD.

En otras palabras, cuando bajo las fotos de la cámara, se guardan en la red. Cuando estoy haciendo algún desastre en Premiere, todo el footage viene de la red. Cuando tengo que virtualizar algo, a no ser que requiera la performance de I/O, el vmdk/vdi/vhd/vhdx/whatever esta en la red. Y así con prácticamente todo lo que no resulte un problema, en ese caso lo guardo o en el disco o SSD local.

Esta obsesión de mandar todo al storage arranco hace no mucho cuando me di cuenta de dos cosas:

  • Tengo un montón de espacio disponible en el storage del server.
  • El storage cuenta con redundancia, los discos de mi maquina no.
  • El storage se respalda automáticamente, los discos de mi maquina no (yo respaldo manualmente ciertas cosas que considero importantes).
  • El acceso a mi unidad de red es mas rápido que a los discos duros locales a la maquina.

Ese ultimo ítem fue el que me llevo realmente a coparme con la idea de un storage por red mas rápido, al ver que tener el pool de ZFS con estados sólidos haciendo de cache, la red era mi cuello de botella. En aquel momento, pensaba que si tan solo pudiera hacer link-aggregation entre los equipos y el switch…

No, you can’t always get what you want” —Mick Jagger

El tema es, el CRS125 es un aparato bastante particular, tiene 24 interfaces las cuales podes o asignar a uno de los switches por hardware o manejarlas como interfaces independientes. Si bien puedo hacer agregación de enlaces, solo puedo hacerlo para interfaces que están por fuera del switch y por lo tanto tendría que tener un bridge entre esa agregación y el resto el switch y de solo pensar en todo eso pasando por el CPU del CRS me da dolor de cabeza (aunque un día con tiempo de sobra voy a probarlo).

Multi-gigabit de pobre

Bueno, resulta que tiempo después me entere que, si bien no puedo hacer link-aggregation propiamente dicho (o sea a lo LACP), tenia una alternativa llamada “bonding” (o teaming). Resulta que el kernel de Linux tiene un driver de bonding que me permitía hacer lo que yo quería y por lo tanto me le agregue al server una placa con cuatro interfaces Gigabit Ethernet y nació el “James Bond”.

hmmm… patchcord viejo y peludo

Mientras que en Windows es tan fácil como crear un “NIC Team”… si estas en Windows Server. Al parecer a Microsoft se le “escapo” esa funcionalidad una vez en Windows 10 pero se dieron cuenta y la sacaron, tal como explica Adam Rudell en los foros de TechNet:

While the powershell cmdlet didn’t outright fail on client, LBFO was in a broken and unsupported state, since the client SKU does not ship the mslbfoprovider.sys kernel driver. That kernel driver contains all the load balancing and failover logic, as well as the LACP state machine. Without that driver, you might get the appearance of a team, but it wouldn’t really do actual teaming logic. We never tested NIC Teaming in a configuration where this kernel driver was missing.

Adam Rudell, Microsoft employee (allegedly), TechNet Forums

A pesar de que había gente en internet reportando que funcionaba, realizando pruebas de transferencia, pero bueno, supongo que lo archivamos en el armario de “Things Microsoft does”. Que tipos simpáticos.

La alternativa para hacer esto en Windows 10 es usar una placa de red que lo soporte a nivel de driver, lamentablemente estoy usando una de esas Intel PRO/1000 PT Dual Port que se consiguen por chirolas en cualquier parte y que funcionan muy bien en Windows, Linux & BSD pero el driver de Intel no soporta bonding en estas placas (fair enough: son bastante viejas).

SMB multichannel

No recuerdo bien como, pero de casualidad encontré que existe en SMB (el protocolo de File Sharing de Windows) una funcionalidad llamada multichannel y básicamente esto le permite a un cliente SMB utilizar múltiples conexiones simultaneas cuando transfiere archivos, sin necesidad de agregaciones o bondings o teams.

Mientras que del otro lado, depende de si usas Windows o Samba (la implementación open-source de SMB que nada tiene que ver con la fiesta brazuca). Si usas Windows se supone que en versiones recientes viene habilitado por defecto y no hay que hacer nada. Si usas Samba (de vuelta, nada de Brasil), tenes que estar en la versión >= 4.4.0 (cualquier distro decente hoy en día cumple con esto) y agregar al menos lo siguiente a la configuración de smbd:

server multi channel support = yes
aio read size = 1
aio write size = 1

Si queres una guía que explique esto de SMB multichannel con Samba, te recomiendo el post de Daniel Vogelbacher (Chaospixel).

Lo único que importa, es que funciona… la gran parte del tiempo:

2Gbps: es como ponerle N2O a un Fiat Uno!

Pero no es perfecto dado que:

  • Hay veces que no levanta el multichannel y transfiere a 1Gbps, vaya uno a saber porque.
  • Tenia en mente usar al menos 3 adaptadores Gigabit en la PC de escritorio, dado que en el server hay 4. Por razones que desconozco, al agregar un tercer adaptador, SMB multichannel hace lo suyo pero se ve que el overhead me juega una mala pasada porque no llega a saturar los tres enlaces, de hecho la velocidad de transferencia es peor que con 2.
  • Es una funcionalidad experimental y hay casos donde podría llevar a la corrupción de datos… oops!

CAVEAT: While this should be working without problems mostly, there are still corner cases in the treatment of channel failures that may result in DATA CORRUPTION when these race conditions hit. It is hence

NOT RECOMMENDED TO USE MULTI-CHANNEL IN PRODUCTION

at this stage. This situation can be expected to improve during the life-time of the 4.4 release. Feed-back from test-setups is highly welcome.

Samba 4.4.0 Release Notes

Quiero mas

Lamentablemente, ya mordí la manzana. Pasar de 1Gbps a 2Gbps puede ser que no parezca mucho, pero en mi caso, esperar media hora a que se copie algo en lugar de una hora entera se siente. Mas importante aun, 2Gbps ya es suficientemente rápido para sacar los discos duros del PC y quedarme solo con el SSD y el storage por red. Por ahora la única contra que le veo es si por algún motivo el storage queda inaccesible durante un tiempo extendido, por ejemplo, si falla el mismo.

Ah, y esta ese detalle menor que SMB multichannel en Samba es experimental y puede ocasionar perdida de datos.

Estuve considerando también otras opciones “multi-gigabit” como 2.5Gbps y 5Gbps pero lamentablemente no se consigue mucho de eso y tendría que cambiar el switch de todas formas, así que 10Gbps no parece algo muy loco, sobre todo si puedo conseguir traer las partes dentro del régimen de franquicias porque seguro que hoy en día no me justifico pagar USD 600 por 10GbE entre el server y el desktop.

De todas formas, todo esto pende de una cosa sola, la cual debería ser la mas obvia: a que velocidad puedo sacar y meter datos del storage?

Solo hay una manera de averiguar y es comprar todo y ver que onda correr unos benchmarks a la carrera, hacer una gráfica y ver que pasa:

Vos hace de cuenta que es un partido Netherlands – Uruguay

Bueno, que manera de pinchar el globo. Las observaciones son:

  • Usar una unidad de red contra el pool ZFS (o contra un SSD fuera del pool), teniendo 2Gbps es mas rápido que los discos duros SATA que están conectados al PC.
  • El pool ZFS del server puede ir mas rapido que mi conexion de 2Gbps, pero no mas rapido que 3Gbps.

Ahora bien, el benchmark del pool ZFS se corrio de manera tal que nos evitaramos el cache en RAM, dado que me interesaba la performance del pool en si.

Sin embargo, en un uso real, el cache de I/O esta siempre ahi dando la nota, por lo cual corresponde volver a correr el benchmark como un gentleman, teniendo el cache en cuenta. Veamos que pasa:

Diria Sergio Gorzy: “FOR OL IU”

LPM, ahora tengo que hacer todo este post de nuevo, pero para 25 Gigabit Ethernet [*2]. Pero mientras tanto… SAMBA!!

[*2]: Si y no. El cache del filesystem en memoria puede ayudarme mas que nada al correr programas, donde aplica algo similar al “principio de localidad“. Para la ida y vuelta de archivos grandes no le veo que pueda aportar mucho.

Jugando con h265

Con toda la llegada del mundo de resoluciones actualmente ridículas pero que en un futuro van a ser estándar para dar lugar a nuevas resoluciones ridículas (lease 4K) se vio necesario el desarrollo de nuevos codecs para seguir haciendo “mas” con “menos” e increíblemente lo han logrado. O en realidad, no tan increíblemente porque siempre te pasa que tenes un codec hermoso y te hacen otro mas eficiente aun. Este es el caso de h265 (HEVC), que viene a responder a las necesidades de “bandwidth” del vídeo en 4K.

Básicamente h265 promete mejor relación tamaño de archivo vs. calidad que h264 (a cambio de complejidad o sea, uso de recursos de la maquina) lo cual no solamente lo hace ideal para guardar y mandar esos gloriosos 8 millones de pixeles de vídeo, sino que también sigue siendo más eficiente que h264 para el viejo y querido vídeo en 720p y 1080p.

Y lo único que hice para probar fue agarrar un batch de 8 videos filmados directamente de la cámara, sin edición, sin correcciones de color, sin títulos, sin nada raro y pasarlos por el encoder de Adobe. Los originales son 1080p30 y se encodearon a 720p30 con h264 (AVC) y luego en 1080p30 y 720p30 en h265. No creo que los resultados sean realmente representativos ya que tiré los bitrates a “ojimetro” basándome en los presets del Adobe Media Encoder, por lo cual hay lugar para optimizar más aun. Lo que si te puedo decir es que el tiempo de encoding se dispara considerablemente (bastante mas del doble pero soy manco y me olvide de medir) usando h265 que h264.

Pero de todas formas, el titulo de este post es dice “Jugando” así que tampoco te estabas esperando un análisis en profundidad. Capaz que algún día lo hago, pero ya hay gente que sabe en serio de esto y ya lo hizo, como por ejemplo ExtremeTech. Mis resultados chanchos son los siguientes (en naranja los originales):

Comparacion poco seria entre h264 y h265
Comparacion poco seria entre h264 y h265

Anecdoticamente agrego que estos mismos vídeos tal cual tomados por la cámara pesan unos 5GB aproximadamente [1], esto se debe en parte a que las cámaras no pueden andar desperdiciando recursos en encoding y en otra parte porque usa un formato retardado llamado Quicktime. En realidad Quicktime no tiene nada que ver, pero me gusta darle palo.

Bueno no se si te esperabas menos, o te esperabas más. Para mi bajar cerca de 60MB en ambos casos no esta nada mal considerando que no me puse a jugar con los parámetros. Te diría que es compresión “gratis” siempre y cuando el tiempo de encoding no sea drama (o que no tengas un CPU muy polenta, esto lo hice en un i7-6700k).

Aca te van los tamaños reales de los archivos para cada caso:

En cuanto a que encoders hay en la vuelta, esta lleno de encoders pagos, pero gratuitos… … …

La gente de VideoLAN está manteniendo el codigo fuente de x265 y un programa que lo implementa es el gratuito y fácil de usar Handbrake que ademas también implementa x264. En cuanto a los pagos obviamente no he probado ninguno y no pienso perder el tiempo. Si tenes acceso a la suite de Adobe CC, el Adobe Media Encoder anda muy bien, es cómodo de usar (sobre todo en batches) y ya viene con un montón de presets (ademas de dejarte ser granular con unas cuantas cosas).

En cuanto a si le voy a dar uso, depende. Por ahora probablemente voy a seguir pasando todo lo de la cámara a h264 [2] ya que la reproducción obviamente también consume mas recursos en h265. Prueba de esto es que tenemos un Intel Compute Stick conectado en la TV del Living y parece costarle reproducir vídeos encodeados en h265 1080p30. En una de esas le tiro un 4K a ver como se prende fuego.

[1], [2]: En realidad de la cámara ya vienen en H264/AVC dentro de un contenedor Quicktime, pero tienen un bitrate ridículamente alto y el encoder de la cámara no es muy complejo, porque requeriría que las cámaras pasen a ser computadoras prácticamente. La conversión que hago es usar el preset de mas alta calidad en Adobe Media Encoder donde generalmente los vídeos resultantes me quedan del 10% o menos del tamaño original.