Factores Prácticos del trading: Entorno de Producción.
 
 
  • Usted está aquí:
  • Home
  • Software
  • Factores Prácticos del trading: Entorno de Producción.

Factores Prácticos del trading: Entorno de Producción.

 
TradingSys (AndG) - 7 Oct 2010
8 comentarios
 

tradingsys Hoy tengo el placer de presentarles un excelente artículo enviado por nuestro amigo Pablo Espinar en el que se detallan las ventajas de utilizar un servidor virtual como soporte para la operativa sistemática. También nos describe, como caso práctico, algunos aspectos de su experiencia personal empleando esta tecnología.

 


Respondiendo a la amable invitación de Andrés, quiero compartir mis experiencias en lo que a operativa sistemática se refiere, y en particular a la puesta en producción de la misma.


DIFERENTES ENTORNOS, DIFERENTES NECESIDADES.


En Informática se suelen diferenciar, al menos, entre dos entornos de trabajo (entorno: conjunto formado por hardware, software, red,  y suministros varios - electricidad, temperatura, etc.). Veremos que dicha distinción puede fácilmente hacerse extensiva a la operativa sistemática:

— Entorno de desarrollo: son los ordenadores y demás infraestructura en los que los programadores trabajan para hacer los programas. Se caracteriza por no tener unos requerimientos de disponibilidad y rendimiento demasiado exigentes, ya que los programas no están a disposición del usuario final, y por lo tanto los errores que puedan surgir no tienen especial importancia.

En operativa sistemática esto se puede comparar con los ordenadores que utilizamos para hacer programación, backtesting, walk -forward, estimación de riesgo, gestión del portfolio, etc. En general las tareas que no dependen de un data-feed en tiempo real.

— Entorno de producción: son los ordenadores y demás infraestructura en los que los programas se ponen a disposición del usuario final para su explotación. En este entorno, los requerimientos de disponibilidad y rendimiento son máximos, siendo habitual en los últimos tiempos que se requiera una disponibilidad 24 x 7, y un rendimiento tan alto como permita el presupuesto de inversión en infraestructuras.

En operativa sistemática esto se puede equiparar a la infraestructura que utilizamos para el tiempo real: tanto los sistemas que tenemos funcionando sobre cuentas reales, como los que tenemos en simulación en modo "incubadora".

En el resto del artículo nos centraremos en este último entorno, sin duda el más crítico para nuestra actividad. El entorno de desarrollo en nuestro caso puede ser cualquier ordenador que tengamos en casa, simplemente cuanta más CPU, menos tardará en llevar a cabo nuestras "mega-optimizaciones".  


LO QUE PUEDE IR MAL IRÁ MAL.


La puesta a punto de un entorno de producción no es en definitiva más que un ejercicio de gestión de riesgos: hemos de imaginarnos todo lo que puede fallar y, a continuación, hemos de implementar "contramedidas" que palien al máximo dichos puntos de posible fallo.

Vamos por lo tanto a enumerar las posibles causas de fallo de nuestro sistema de producción de trading, así como las contramedidas usuales para cada uno de ellos.

 

1) Fluido eléctrico. El problema más usual con el que nos podemos encontrar. Desde que la parienta enchufa la plancha, el microondas y el calentador de la niña todo junto, y se van los plomos a hacer puñetas, hasta el apagón general en media ciudad (en Barcelona algunos estuvimos hasta tres días sin luz hace un par de años). Esto se "soluciona" mediante la instalación de un  SAI (Sistema de Alimentación Ininterrumpida), que permita tanto a nuestro ordenador como a nuestro router, seguir funcionando durante un período de tiempo. Normalmente, sin embargo, las baterías de estos sistemas son muy caras, y apenas alcanzan para un par o tres de horas de funcionamiento. Si el apagón se prolonga más tendremos que detener la operativa.

2) Conectividad a Internet. Otro clásico. De alguna manera, - normalmente por culpa de nuestro proveedor de Internet, aunque a veces el problema puede ser más general, - nuestra conexión con el broker y/o el data feed cae y todas nuestras posiciones abiertas quedan "huérfanas" del ojo del amo. La contramedida usual es disponer de una conexión a Internet de backup, el típico "pincho" USB de un operador móvil, por ejemplo. Seguimos añadiendo costes, por cierto.

3) Fallo hardware. No es tan habitual como los puntos 1 y 2, pero también puede suceder. Cualquier componente de nuestro PC de trading nos puede dejar "tirados" en un momento dado. Lo más habitual es que sea el disco duro, pero también se averían las placas bases, tarjetas gráficas, monitores, etc. Aquí lo más práctico es tener directamente otro ordenador de repuesto para estas contingencias. En esta categoría podríamos incluir también eventos que afecten a nuestro PC, tales como inundaciones (la lavadora!!), altas temperaturas, etc.  

4) Caída del broker. También puede suceder que nuestro broker o proveedor de datos tenga dificultades técnicas. Esto es un imponderable que no depende de nosotros, y poco se puede hacer. Algunos aconsejan tener cuenta en otro broker y abrir posiciones contrarias mientras dure la avería en nuestro broker "primario".

En todo caso, y tanto para esto como para el resto de averías, siempre es aconsejable contar con el teléfono del broker anotado en una agenda de papel para, eventualmente, cerrar todas nuestras posiciones.

5) Fallo software. De largo el fallo más habitual. "NinjaTrader ha detectado un error y debe cerrarse"... Los fallos pueden deberse tanto a la plataforma utilizada, como a las estrategias que hayamos programado. En este último caso no hay más remedio que probarlas tanto como sea posible, aquí ayuda un generoso periodo de incubadora, así como una correcta gestión de la calidad del software que generemos: registro de los errores y acciones correctivas, etc. En cuanto a las plataformas, las hay más y menos estables. En mi opinión, NinjaTrader es "bastante" estable (siempre hablando de la versión 6.5, versiones beta nunca tienen que acercarse ni de lejos al entorno de producción), pero algún que otro disgustillo suele dar de vez en cuando. Algo que si es importante aquí es que el ordenador de producción tenga el menos software instalado posible, para que no aparezcan las temidas incompatibilidades, a menudo generadoras de fallos y bajadas de rendimiento. En mi caso por ejemplo, ni siquiera tengo antivirus en mi entorno de producción.

Bien, lo lamentable de todo esto es que al final tenemos nuestro pobre despacho lleno de cachivaches, que se calientan, meten un montón de ruido y lo entorpecen todo (la parienta no suele estar muy contenta con esta disposición). Si además algún día tenemos que mudarnos, por ejemplo, los quebraderos de cabeza se multiplican.

Veamos si existe alguna otra alternativa más cómoda.


MANDÁNDOLO TODO A "LA NUBE"


En los últimos años se ha extendido en informática el concepto de "cloud computing", que básicamente consiste en que las empresas (o particulares), para ofrecer sus servicios sobre una plataforma informática, en lugar de comprar e instalar servidores en sus propias oficinas, lo que hacen es alquilarlos a proveedores de servicios de "hosting", que cuentan con enormes "datacenters" que albergan cientos de servidores de sus clientes, en condiciones de seguridad, disponibilidad y rendimiento muchos mayores de las que puede permitirse una pequeña empresa (no digamos ya un particular). Ello unido a la madurez de las tecnologías de virtualización de sistemas, hace que en la actualidad haya una oferta tremendamente competitiva en costes incluso para el trader particular.

El nombre de cloud computing viene porque se dice que tus servidores los tienes alojados en "la nube": algún sitio de Internet, (el sitio físico en el mundo muchas veces ni se conoce, por motivos de seguridad adicional) al que nos conectamos de manera remota, pero indistinguible de la situación en que los tuviésemos en nuestras instalaciones.

Existen dos tipos de ofertas en cuanto a "alojamiento" (hosting) de servidores:

  • Alojamiento de un servidor físico. El proveedor te proporciona un servidor físico completo para ti sólo, te lo pone en su datacenter y te lo alquila mediante un pago mensual. Aquí no hay grandes economías de escala, por lo que la cuota es bastante alta.

Otra opción dentro de este mismo esquema es que tú te compras el servidor, y el proveedor lo único que hace es alquilarte el espacio en su datacenter.

  • Servidores "virtuales". Aquí se trata de que el proveedor dispone un servidor físico, bastante potente, y sobre él, mediante software de virtualización, instala varios servidores virtuales (ocho, diez, o doce, o más por cada servidor físico). A ojos del cliente, estos servidores son indistinguibles de los físicos, pero para el proveedor supone un aprovechamiento máximo de recursos hardware, con lo que se puede realizar una oferta mucho más competitiva. Aquí los costes son mucho más contenidos, del orden de 30 $ a 100 $ mensuales, dependiendo de sistema operativo, memoria, etc.


tradingsys


VENTAJAS DE "LA NUBE"

En mi opinión, establecer nuestro entorno de producción "en la nube", es decir, alojado en un servidor virtual en un datacenter, presenta una serie de ventajas en comparación al modelo de "todo en casa" (literalmente):

  • Tolerancia a fallos. Veamos las contramedidas de que dispone un datacenter ante las contingencias enumeradas anteriormente:

1. Fluido eléctrico. Los datacenter son alimentados habitualmente por varias compañías eléctricas, que sirven de respaldo unas a otras. En el caso además de apagón general, aún cuentan con gigantescos generadores que les permiten continuar las operaciones sin interrupción por el espacio de tiempo que dure la avería.

2. Conectividad a Internet. Los datacenter están también habitualmente conectados a varios proveedores de Internet, usualmente a sus redes troncales, con lo que no sólo la disponibilidad sino el ancho de banda están garantizados en un porcentaje muy alto.

3. Fallo hardware. Los servidores virtuales están sustentados no por un único servidor hardware sino más bien por lo que se llaman "granjas" de servidores. Si hay un fallo hard en uno de los servidores físicos, los virtuales que se encuentran alojados ahí pasan automáticamente a otro que esté en perfectas condiciones. No se pierde ni un solo ping. Yo lo he visto en directo y es bastante espectacular.

4. Caída del broker. Aquí no hay ventaja sobre el caso de tenerlo todo en nuestra casa, por lo que somos nosotros los que hemos de prepararnos para esa contingencia, como ya se explicó.

5. Fallo software. El mismo caso que el punto 4.

  • Latencia. Este es un parámetro importante en operativa sistemática. Cuanto más cerca, telemáticamente hablando, estemos de los mercados, menor es la probabilidad de incurrir en el temido slippage. Por ello es aconsejable alojar nuestro VPS (Virtual Private Server) o VPD (Virtual Private Desktop) en un datacenter próximo a los mercados, por ejemplo en Chicago o New York si trabajamos con mercados de allí.

  • Costes. Un VPS que pueda correr razonablemente bien NinjaTrader viene a costar una cuota mensual de unos 50$. No hecho el estudio de costes concreto, pero imagino que sale más barato que montar toda la parafernalia de SAIS, doble ADSL en casa, etc.

  • Asistencia. Los datacenter cuentan con personal 24 x 7, con lo que ante cualquier problema se puede contactar con ellos y que te reinicien la máquina por ejemplo. Esto te permitiría, pongo por caso, seguir operando mientras estás de vacaciones o de viaje. En casa se podría montar un acceso remoto tipo Logmein para estos casos, pero si por ejemplo se va la luz mientras estás fuera, ya tendrías que contar con alguien que fuera a tu casa a encender de nuevo, etc.


MI EXPERIENCIA PERSONAL


Después de evaluar los pros y los contras que ofrecen ambas opciones, a principios de este año me decidí por probar la alternativa del alojamiento en datacenter.

Para ello lo primero que hice fue escoger el proveedor adecuado para mis necesidades. Hay muchos proveedores de servidores virtuales, lo que también favorece que baje su precio. Entre los que yo miré en su momento me he quedado con: Triple 8 .  Motivos:

  • Es de los pocos que ofrecen servidores virtuales con sistema operativo XP (en este caso le llaman Virtual Private Desktop). La mayoría lo ofrecen con Linux (no sirve en nuestro caso) o Windows 2003 Server. En éste último si que se puede instalar NinjaTrader, pero debido a ciertas características de seguridad del 2003 server, resulta algo más lioso de configurar, aparte de que consume más recursos que XP, que es suficientemente estable para nuestros propósitos.

  • Precio. Está en línea con el resto de proveedores.

  • Periodo de prueba. Es de los pocos proveedores que ofrecen periodo de prueba, en este caso una semana. Con ello puedes ver el rendimiento de tus sistemas en el hosting remoto.

En este caso, este proveedor no tiene datacenters en Chicago ni New York, que sería lo ideal ya que ahí están los mercados. En mi caso mi VPD está en Dallas. Ahora bien, con los anchos de banda que gasta esta gente, no creo que haya mucha diferencia.

Una vez contratado el servicio, desinstalé el poco software que viene por defecto (un antivirus que yo recuerde), e instalé el NT 6.5 última versión. A continuación se muestra una vista típica de la consola remota. Cuando lo pones en pantalla completa no lo distingues de tu propio ordenador salvo por una pequeña barra de herramientas en la parte superior.

 

tradingsys

>> Ampliar.


Y desde entonces estoy funcionando con esto desde abril de este año, y todavia no he tenido ni un sólo incidente, siempre he podido acceder a mi "Virtual Private Desktop" sin problemas. Empecé con una configuración mínima (512 Mb de memoria), y recientemente la he actualizado a 1 Gb de memoria, ya que con 512 Mb el Ninja va un poco justo, aunque se puede trabajar.

Finalmente comentar también, para el que le pueda interesar, un par de aspectos de mi forma de trabajar con esta configuración:

  • No habría inconveniente en tener la consola remota encendida todo el día y tenerla en una pantalla como si de un ordenador local se tratara. En mi caso, sin embargo, me encuentro más cómodo "olvidándome" del entorno de producción, para así poder centrarme en las tareas de diseño y desarrollo de nuevos sistemas (si se está cada dos por tres consultando la consola de producción, se pierde eficacia en el resto de tareas, y se aumenta el stress, en mi opinión, que es, por supuesto, muy personal). Sin embargo esto no significa que tenga la operativa completamente desatendida, lo que no sería prudente. En mi caso lo que hago es que algunas estrategias, en algunos momentos del día (puntos de control) me envían un mensaje de correo electrónico, lo que me confirma que todo sigue funcionando correctamente. El código en NT que hace esto sería algo así:

 


       // Alarma de inicio de sesion

       if (Bars.BarsSinceSession == 0)

SendMail ("xxx@gmail.com", "xxx@gmail.com", "Inicio sesión Ok " +  this.Name + "_" + Instrument.MasterInstrument.Name + "_" + BarsPeriod.Value + "m", " ");    

   


         
  • Automatización del registro de los trades. Soy un firme defensor de automatizar todo lo posible las tareas que no aportan valor añadido. Para realizar el registro de los trades de mis sistemas me valgo del excelente programa Market System Analyzer (MSA), del que ya se ha hablado aquí en otras ocasiones. Dicho programa almacena los datos de las operaciones en ficheros de texto con extensión csv. Pues bien, yo me he fabricado una rutina, que he incorporado a todas mis estrategias, que lo que hace es escribir directamente en ese fichero en tiempo real los datos del trade, entrada, salida, stop loss... De esa manera siempre tengo actualizados los ficheros MSA sin necesidad de introducir los datos a mano. Adicionalmente, me valgo de otra característica de "la nube": se trata de Dropbox (http://www.dropbox.com), un disco duro "virtual" (gratuito hasta 1 Gb) ubicado en Internet, como Gmail por ejemplo. Una particularidad especialmente útil de Dropbox es que viene con un programa (el único que tengo instalado en la estación de producción, además de NT 6.5) que permite tener sincronizadas algunas carpetas de tu disco duro, con las carpetas del servidor central, y eso lo puedes instalar en tantos ordenadores como desees. De esta manera, almaceno mis ficheros MSA en esas carpetas, y para ver los resultados de mis trades de cada día ni siquiera tengo que conectarme a la consola: basta con que abra los ficheros MSA de mi PC local que ya están actualizados en tiempo real con los datos de las operaciones.

En el área de descargas de la web hemos dejado una copia de la rutina de volcado de los trades, por si a alguien le resultara de interés.

 

© Pablo Espinar.

Tradingsys.org, 2010.

 

 


 

 

Comentarios

 

wamp - Estupendo artículo

Te felicito Pablo, por esta estupenda implementación de la técnica de sistemas a los sistemas de trading. 
 
Lo único que me chocó fué que sólo pensases en dos entorno, desarrollo y producción. Para mis preferencias personales, me gusta disponer de un intermedio, el de Test o Pruebas, que serviría para lo que has descrito como incubadora, ya que como dices muchas veces un nuevo sistema puede tirar el sistema de producción. De esta forma añadirias un poco mas de seguridad a la producción. 
 
La idea del entorno de test, es que sea calcado al de producción pero con menos recursos, para abaraar costes y que por otro lado se pueda estresar de una forma mas sencilla.  
 
En este tercer entorno, se podrían hacer pruebas de estres a los nuevos sistemas. Probar antes de aplicar en el entorno de producción nuevos parches y versiones de software y S.O., en un entorno virtual mas similar al de producción que el de desarrollo en hardaware convencional, etc... 
 
Por otro lado nuestra experiencia con la virtualización es que parecen la panacea hasta el día que deja de serlo. 
 
En los desktop de Citrix hay que estar muy atentos a las perdidas de rendimiento respecto de las máquinas físicas, con lo cual habría que tener en producción monitores de rendimiento y algún sistema de monitorización un poquito mas evolucionado. 
 
Luego el capítulo de hardware cuando lo elevamos a la granja en un datacenter, se hace bastante mas complejo que en casa, y los sistemas tolerantes a falllos, muchas veces dejan que desear. Ya me imagino que la prueba del ping y la caida física de una máquina es impresionante, pero no todos los eventos son así de programados y el día menos pensado falla un switch y el de backup .... estaba desactualizado y no ha arrancado. 
 
Con esas pequeñas digamos "manias mías" de sufridor de eventos en producción creo que el entorno que utilizas es realmente estable por el precio tan razonable. 
 
Muchas gracias por compartir tus experiencias y espero que las mías colaboren en la robustez de tu entorno. 
 
Yo sigo buscando algún entorno para el desarrollo de sistemas de trading bajo linux / unix. Realmente si tuviese que escribir una carta a los reyes magos, les pediría un entorno de desarrollo de sistemas en unix o windows, pero que a ser posible pudiese ejecutar luego en un servidor de aplicaciones J2EE. 
 
Os leo!!!

flyscalper - Entorno de \"pre-producción\"

Hola wanp, 
 
gracias por el comentario. 
 
Efectivamente, como dices, lo habitual es tener tres entornos, el que tu llamas de test y que yo suelo llamar de pre-producción, que en el caso del trading sería la "incubadora". No lo mencioné por no complicar las cosas pero sería lo suyo. Podríamos entonces tener dos máquinas virtuales, una para los sistemas en incubadora y otra para los sistemas en real. De esta manera, un posible fallo en un sistema simulado no afectaría a uno en real, aunque esta situación de momento no me la he encontrado. 
También de acuerdo en que la virtualización no es la panacea. En realidad, para mi es sobre todo un sistema de ahorro de costes, donde aprovechas al máximo el hardware existente. Pero efectivamente, cualquier fallo hard puede ocurrir igualmente, y además tienes una capa de virtualización que puede introducir algún elemento de fallo adicional. Pero con todo y con eso, mi experiencia hasta la fecha no puede ser más positiva, y es lo que he querido contar. 
En cuanto al entorno de desarrollo de sistemas que buscas, no se si conoces Algodeal (www.algodeal.com). Es un sitio en donde te proporcionan todo un entorno de desarrollo de estrategias (en java), llegando incluso a la posibilidad de una vez desarrollada ponerla en producción. Quizá le podías echar un vistazo, yo tengo pendiente mirármelo con un poco más de profundidad. 
 
Un saludo, 
 
Pablo

madeharo - Conoces a estos??

http://www.layeredtech.com/ 
 
Estos si alquilan en coresite.com que parece ser el mejor sitio de los posibles. 
 
Sito en Chicago entre otras cosas. 
 
Gracias por el artículo.

madeharo - Una pregunta.....

Podrias decirme que ping te da desde tu servidor virtual a estas direcciones? 
 
64.202.118.179 
64.202.118.208 
64.202.118.247 
 
Son las del feed que uso en estos momentos (zen-fire) en realidad son los antiguos 7ticks, que ahora son los de www.interactivedata.com 
 
Desde mi casa da unos 200 ms.  
Seguramente desde Dallas, dará menos. 
 
Yo también uso ninja y estoy a punto de empezar a hacer pruebas mas serias. 
 
Un saludo y gracias de antemano.

flyscalper - re: Una pregunta.....

Cita: madeharo
Podrias decirme que ping te da desde tu servidor virtual a estas direcciones? 
 
64.202.118.179 
64.202.118.208 
64.202.118.247 
 
Son las del feed que uso en estos momentos (zen-fire) en realidad son los antiguos 7ticks, que ahora son los de www.interactivedata.com 
 
Desde mi casa da unos 200 ms.  
Seguramente desde Dallas, dará menos. 
 
Yo también uso ninja y estoy a punto de empezar a hacer pruebas mas serias. 
 
Un saludo y gracias de antemano.

 
 
madeharo, 
 
acabo de probarlo y ninguna de esas tres direcciones me contesta, ni desde casa ni desde Dallas. Lo lamento. 
 
Sin embargo te puedo poner los ping de las direcciones que yo creia que eran de zen-fire, que es el que yo uso también: 
 
C:\>ping 64.202.118.1 
 
Pinging 64.202.118.1 with 32 bytes of data: 
 
Reply from 64.202.118.1: bytes=32 time=32ms TTL=248 
Reply from 64.202.118.1: bytes=32 time=31ms TTL=248 
Reply from 64.202.118.1: bytes=32 time=31ms TTL=248 
Reply from 64.202.118.1: bytes=32 time=31ms TTL=248 
 
Ping statistics for 64.202.118.1: 
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
Minimum = 31ms, Maximum = 32ms, Average = 31ms 
 
C:\>ping 64.202.118.2 
 
Pinging 64.202.118.2 with 32 bytes of data: 
 
Reply from 64.202.118.2: bytes=32 time=32ms TTL=247 
Reply from 64.202.118.2: bytes=32 time=31ms TTL=247 
Reply from 64.202.118.2: bytes=32 time=32ms TTL=247 
Reply from 64.202.118.2: bytes=32 time=34ms TTL=247 
 
Ping statistics for 64.202.118.2: 
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), 
Approximate round trip times in milli-seconds: 
Minimum = 31ms, Maximum = 34ms, Average = 32ms 
 
Un saludo, 
 
Pablo

madeharo -

Que raro.....  
Las que te di, son a las que esta conectado mi ninja ahora mismo.  
 
Pero esta claro que son del mismo sitio. 
 
32 ms es muy muy poco. Es increíble. 
Eso es una pasta a lo largo del tiempo en deslizamientos. 
 
Ya que estamos en la misma onda.... quizás fuera interesante compartir mas ideas y experiencias. 
 
Un saludo.

madeharo -

Muchas gracias.  
 
Voy a probar un server de triple 8 esta misma semana. 
 
Un saludo.
No es posible añadir comentarios sin hacer login
 
Modificado por TradingSys (AndG) - 7 Oct 2010
 
 

* Campos obligatorios

 
 

 
 

Secciones

 
 
 

Entradas recientes

 
 

Enlaces