config.yaml

@@ -1,7 +1,7 @@
 from: markdown
 to: pdf
 
-output-file: report.pdf
+output-file: output.pdf
 input-files:
   - report.md
 

report.md

@@ -6,113 +6,10 @@
 
 # Subject
 
-The first description of my internship project was given to me as:
-
-> The project is about benchmarking a new service we're building related to
-> exchange connectivity. It would involve writing a program to generate load on
-> the new service, preparing a test environment and analyzing the performance
-> results. Time permitting might also involve making performance improvements to
-> the services.
-
-To understand this subject, we must start with an explanation of what exchange
-connectivity means at IMC: it is the layer in IMC's architecture that ensures
-the connection between internal trading services and external exchanges' own
-infrastructure and services. It is at this layer that exchange-specific
-protocols are normalised into IMC's own protocol messages, and vice versa.
-
-Here is the list of tasks that I am expected to have accomplished during this
-internship:
-
-* become familiar with the service,
-* write a dummy load generator,
-* benchmark the system under the load,
-* analyze the measurements.
-
-This kind of project is exactly the reason that I was interested in working in
-finance and trading. It is a field that is focused on achieving the highest
-performance possible, because being faster is directly tied with making more
-trades and results in more profits.
-
-Because I expressed this personal interest for working on high performance
-systems and related subjects, I was given this internship project to work on.
-
 # Context of the subject
 
-The exchange connectivity layer must route orders as fast possible, to stay
-competitive, reduce transaction costs, and lower latencies which could result in
-lost opportunities, therefore less profits.
-
-It must also take on other duties, due to it being closer to the exchange than
-the rest of the infrastructure. For example, a trading strategy can register
-conditional orders with this service: it must monitor the price of product A and
-X, if product A's cost rise over X's, then it must start selling product B at
-price Y.
-
-A new exchange connectivity service, called the Execution Gateway, is being
-built at IMC, the eventual goal being to migrate all trading strategies to using
-this gateway to send orders to exchanges. This will allow it to be scaled more
-appropriately. However, care must be taken to maintain the current performance
-during the entirety of the migration in order to stay competitive, and the only
-way to ensure this is to measure it.
-
-With that context, let's review my expected tasks once more, and expand on each
-of them:
-
-* Become familiar with the service: before writing the code for the benchmark
-  I must first understand what goes into the process of a trade at IMC, what is
-  needed from the gateway and from the clients in order to run them and execute
-  orders. There is a lot of code at IMC: having different teams working at the
-  same time on different trading service results in a lot of churn. The
-  global execution team was created to centralise the work on core services that
-  must be provided to the rest of the IMC workforce. The global execution
-  gateway is one such project, aiming to consolidate all trading strategies
-  under one singular method to send orders to their exchanges.
-* Write a dummy load generator: we want to send orders under different
-  conditions in order to run multiple scenarios which can model varying cases
-  of execution. Having more data for varying corner cases can make us more
-  confident of the robustness and efficiency of the service. This is especially
-  needed becaue of the various roles that the gateway must fulfill: not only
-  must it act as a bridge for the communication between exchanges and traders,
-  but also as an order executor. All those cases must be accounted for when
-  writing the different scenarios.
-* Benchmark the system under the load: once we can run those scenarios smoothly
-  we can start taking multiple measurements. The main one that IMC is interested
-  in is wall-to-wall latency (abbreviated W2W): the time it takes for a trade to
-  go from a trading strategy to an exchange. The lower this time, the more
-  occasions there are to make good trades.
-  FIXME: probably more context in my notes
-* Analyze the measurements: the global execution team has some initial
-  expectations of the gateway's performance. A divergence on that part could
-  mean that the measurements are flawed in some way, or that the gateway is not
-  performing as expected. Further analysis can be done to look at the difference
-  between mean execution time and the 99th percentile, and analyse the tail of
-  the timing distribution: the smaller it is the better. Consistent timing is
-  more important than a lower average, because we must be absolutely confident
-  that a trade order is going to be executed smoothly, and introducing
-  inconsistent latency can result in bad trades.
-
 # Internship roadmap
 
-The first month was dedicated to familiarizing myself with the vocabulary at
-IMC, understanding the context surrounding the team I am working in, and
-learning about the different services that are currently being used in their
-infrastructure. I had to write a first proof of concept to investigate what, if
-any, dependencies would be needed to execute the gateway as a stand-alone system
-for the benchmark. This has allowed me to get acquainted with their development
-process.
-
-After writing that proof of concept, we were now certain that the benchmark was
-a feasible project, with very few actual dependencies to be run: the only one
-that we needed to be concerned with it called the RDS server. The RDS server
-is responsible for holding the information about all trade-able instruments at
-an exchange. The gateway connects to it to receive a snapshot of the state of
-those instruments, for example the mapping from IMC IDs to the ones used by the
-exchange. I wrote a small module that could be used as a fake RDS server by the
-benchmark framework to provide its inputs to the gateway being instrumented.
-
-I am now currently beginning to write the benchmark framework, using what
-I wrote and learned during the previous month.
-
 # Engineering practices
 
 # Illustrated analysis of acquired skills