As part of my role in monitoring multiple client connections, I would use Pico Corvil Analytics to set up alerts for performance issues, such as TCP resends and dropped packets. These alerts would trigger when the volume was low and performance was poor, allowing me to work with our trading partners to find a resolution. I would present them with the statistics I had and together, we would identify the source of the issue. This collaboration resulted in the client often reconfiguring their systems. For example, we may find that a network connection needed to be made. Overall, this proactive approach helped to maintain strong connections with our clients and minimize disruptions to trading revenue.

In my work, I created an equation to forecast when application latency would occur, specifically regarding end-to-end latency from entry into the dark pool to when the dark pool sends an economic order back to clients. These long order act times were associated with clients sending orders to us. If a client noticed that we were slow in responding, typically due to high load, they would stop sending order flow to us. Therefore, analytics played a significant role in maintaining efficient trading operations.

The analysis I conducted resulted in giving more weight or momentum to an application upgrade project. A specific investment bank's trading platform was essentially a monolithic JVM, which had its limitations in terms of speed and tuning. Therefore, there was an initiative to replace it with a microservices-based Java framework. This involved breaking down the functionalities of the JVM into smaller microservices, which could be orchestrated to handle increased loads efficiently.

What I demonstrated was that we could achieve excellent processing speed with moderate latency. However, upon examining the 99th percentile, the processing time could increase to 100, 200, or even 500. I pinpointed specific areas within the application flow that needed attention, emphasizing the critical role of microservices in improving the framework's performance. The second crucial factor was the broker, which could either enhance or hinder the system's overall performance.

What is most valuable is the ability to troubleshoot when a client complains of spikes in latencies. It gives us the ability to go granular, all the way down to looking at the network packets and analyze them.

Regarding the analytics features, the good part is that it's not just the networking folks who are able to get an in-depth view of the client latency measurements. The business can also take a look and actively participate by looking at them. The front end of Corvil makes it appealing in terms of the ease of navigation and giving them an inside picture of what's going on with their clients.

We just use the basic, core features of Corvil. I know Corvil offers a lot more. As a company, we don't have too many experienced people who are able to write Corvil-specific stuff to make it more advantageous or useful.

I like most features in Corvil. Lately, with their recent releases, their visualization has gotten a lot better. That helps me the most with telling stories to management.

We're able to quickly drill down and find answers to events that are happening in real-time, using Corvil's analytics tools. That's the feature which is most in the spotlight, the feature we're using it for right now.

The correlation and statistical metrics that they provide, on the fly, without us having to reprocess, is also a wonderful feature.

The latency measurements are the most valuable feature. It has the entire view of our platform, as we would see in our own internal processes. It has all the decoders so it's capturing every network packet and it's decoding in real-time and it's giving us latency information in real-time. It is easier to identify the flow and get quotes whenever we want. It's the real-time decoding and getting the latency information statistics that we find the most useful. Absolutely.

The analytics features are something that we are starting to dig into it. Until now, we have only tapped into the latency part of the device. The analytics part is pretty good in terms of what it's already generating. You can get some cool visualizations of the data. The analytics part of the Corvil is pretty cool and you can get a lot out of it. But we also want to use the same data in our own internal processes. It's something that we want to tap into. We haven't used the full potential of Corvil, yet. They're also coming out with a new product called Intelligence Hub, which we are starting to review. It will give more analytics from the Corvil data.

Finally, Corvil provides these nice "APIs" so we can download the data as a comma separated file and do our own analysis. We've been looking at that for the last year-and-a-half: How to use that data and put it into a big-data platform and use that data for other, even more advanced visualizations and analyses.

The performance metrics are pretty good. We've got everything from the network layer to the actual application layer. We can see what's going on with things like sending time and batching. 

Time-series graphs are very good for performance analysis. We can do comparisons. We can do minus one week, or we can say this is the latency in the last 24 hours, and this was the same 24-hour period a week ago and overlay the two time-series graphs on top of each other, so we can see the difference. That's a really powerful tool for us. We make improvements in the network all the time, so it's useful to be able to quantify what the effect of a change was.

The performance analysis is pretty strong.

The ability to dig into the messages is definitely a valuable feature. We don't have any other tool like that, at least in the network space where I work. It is very useful to be able to get such granular information.

As network engineers, when we deal with packets, we can dig down into the TCP level and that's about it. We can't actually decipher the actual messages. For latency analysis, sometimes you're dealing with Exchange-driven time stamps and you actually do need to dig down to that level of detail. That's been the most valuable feature for us.

The analytics features of Corvil are really good. It's the fact that you can build your own metrics. The fact that, as long as you know what the field is in the message, you can build your metrics based on that field and that is very good. It means you can do the analytics that you actually care for. You can customize it in a certain way, which is good.

The functionality is its most valuable feature. We can use CLI with the UI for configuring the new monitoring system, which is good. 

With the Corvil Stored Data Analyzer module, we can use it for test data or a set of production data to set up the configuration for latency setup, so we can use the fields to correlate messages. 

The analytics feature is good. Sometimes, we are using the data search functionality for analyzing certain data over a day or so to find out if we are seeing some increased latency over a certain period of time. We are using the inspect the data analysis or data search to find outliers for anything specific, trying to identify:

• Whether for an order canceled or an order that has been replaced where we are seeing an increase in latency?
• What period of time during the day do we see an increase or decrease?
• For any issue, how much was the latency, and whether it increased or decreased?

The scope of the solution is quite broad. There are a number of other aspects to it, so it is quite multifunctional, as well as delivering a solution for latency monitoring of the trading flow. It also allows us to see at a very granular level the amount of time taken through each of our components, both internally and externally. Therefore, we can use this solution to establish whether or not we have any suboptimal applications, network configurations, switches, or client providers.

In addition, it allows us to trace the flow. The logic is built sufficiently for us to be able to break down clients' orders, underlying child orders, and execution. Thus, it's a good way for us to trace client flow through a myriad of different internal systems.

We use the whole suite of features:

• Latency management
• Gap detection
• Microburst sideloading
• Dashboards
• Analyzing payloads.

We like the dashboards because they essentially organize all the sessions into one viewpoint. The dashboard are very nice. We have a central location where we can look at all sessions, instead of searching for each session. Everything is in front of you in groups in dashboards.