IT Central Station is now PeerSpot: Here's why

Pico Corvil Analytics OverviewUNIXBusinessApplication

Buyer's Guide

Download the Network Monitoring Software Buyer's Guide including reviews and more. Updated: July 2022

What is Pico Corvil Analytics?
Corvil transforms Network Data with speed and precision into the powerful real-time truth. Corvil captures, decodes, reassembles, and enriches vast amounts of data in motion, adding analytics and making the resulting enriched data and IT Operations Analytics available to humans, machines and other systems.

Pico Corvil Analytics was previously known as Corvil.

Pico Corvil Analytics Customers
NASDAQ, Commerzbank, Pico Quantitative Trading, CME Group, Interactive Data, Tokyo Stock Exchange Inc.
Pico Corvil Analytics Video

Archived Pico Corvil Analytics Reviews (more than two years old)

Filter by:
Filter Reviews
Industry
Loading...
Filter Unavailable
Company Size
Loading...
Filter Unavailable
Job Level
Loading...
Filter Unavailable
Rating
Loading...
Filter Unavailable
Considered
Loading...
Filter Unavailable
Order by:
Loading...
  • Date
  • Highest Rating
  • Lowest Rating
  • Review Length
Search:
Showingreviews based on the current filters. Reset all filters
Ralph Muro - PeerSpot reviewer
Performance Engineer at a financial services firm with 1,001-5,000 employees
MSP
Central Management Center allows me to deploy multiple CNEs and deploy new decoders through a central configuration point
Pros and Cons
  • "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..."
  • "In terms of performance analysis, if you really want to dig down into the minutiae and get statistics on the important things... that would be the only piece lacking because, in our environment, we have thousands and thousands of symbols. With the architecture that Corvil is built on, it's cumbersome."

What is our primary use case?

Monitoring our environments is our primary use case. We use it to monitor our trading platform, customer experience, troubleshooting message flow, troubleshooting message formations, as well as for capacity performance analysis, and system testing.

How has it helped my organization?

Previously, we were reliant on application logging, which causes a performance hit on the applications that we're trying to understand better. Corvil, being a passive listener, allows us to get the same amount that the application logs previously gave us. It is also more time-granular. Given the fact that we are able to take multiple applications and point them to the same clock, it gives us more confidence in the measurements we're taking. In the sense that it helps us identify performance issues, it does give us a performance advantage over competitors. For example, we found an issue where we thought part of a network was running efficiently. When we hooked Corvil up to monitor that specific feed, it showed us that the network was not performing as anticipated. It helped us make that area more efficient, which resulted in a customer experience advantage. And that helps us as a company in general. Also, customer order-entry has gotten better due to our production monitoring measurements. And we're able to monitor how efficient we are with the market data dissemination, and that answers customers' questions when they're wondering, "Hey, why am I seeing message B before message A? It should be reversed." Corvil helps us identify those things, to know what's really going on. Corvil helps to correlate individual client or trade desk transactions to infrastructure and venue latency. We do order-to-market data correlation and latency measurement. That's what the majority of what anybody you talk to in this field would say that they're measuring. There are some other features that will let you go deeper and let you know if a message got stored correctly or not. When it comes to determining where to focus performance improvement efforts, let's say you have a multi-server architecture. Corvil has what's called a multi-hop type of configuration which allows you to correlate a message. Let's say it's four hops deep - four different servers, and each of them may speak the same type of protocol or different types of protocols. Corvil enables you to build channels and signatures which, after it's seen on the first server for the first time, and on the second server, correlates those. That lets you know how long it took in that server, going in that particular direction; and similarly, across the other servers and back again. You can isolate things: "Hey, this took a second. Oh, but server three took three-quarters of a second to pass it along to server four." If there is something that is happening right now, it gives us immediate awareness of what is going on. Previously, we would either have to have an operations team extract logs or dig through logs and then do manual correlations to figure out what was going on, or wait until the end of the day to get those logs. In terms of increasing our productivity, ops uses it to communicate with clients and to see their behavior, so that would be increased productivity. In performance engineering, it has greatly increased our productivity. Also, the new version has reduced the time it takes to provide a new dashboard. My business guys will call up and say, "Hey, I'd like to do this", and it is much easier to do now than it was with the old dashboard. Depending on what they want, an old dashboard used to take a couple of hours to get it right. The old dashboard was Flash-based, so the performance was not all that good and it was all drag-and-drop. The new one is HTML5 and it is built on XML, so I can actually script something together and throw a new one in there. Finally, it indirectly helps improve our order execution and revenue because the more efficient we become, the more attractive sending orders to our system is.

What is most valuable?

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.

What needs improvement?

In terms of performance analysis, if you really want to dig down into the minutiae and get statistics on the important things to the folks who want this data - such as: How is our system doing overall? How is each, individual component running? What are the statistics there? What are the statistics for a particular client session? What are the statistics for a trading object, a given symbol? If you look at any one of those things, individually, they're all equally great, but you have to choose how deep you want to go. That would be the only piece lacking because, in our environment, we have thousands and thousands of symbols. With the architecture that Corvil is built on, it's cumbersome. I would like to see more visualization. I know they have a product they've been working on called iHub, which is supposed to address a lot of the business visualization needs and analytics. It sounds like it's going to be a good solution. Once they get their hands around it will probably complete their product. The latest version of their visualizations has been a huge upgrade over what it used to be and, but - and these are not just my own thoughts, they come from conversations I've had with them - their future products will handle all of the types of roll-ups and data-pivoting that their current system doesn't do that well.
Buyer's Guide
Network Monitoring Software
July 2022
Find out what your peers are saying about PICO, NETSCOUT, Riverbed and others in Network Monitoring Software. Updated: July 2022.
610,336 professionals have used our research since 2012.

For how long have I used the solution?

I have been using Corvil for about a decade.

What do I think about the stability of the solution?

It's very stable. It just runs continuously. We get hard drive failure alerts every now and then. We had one instance where we got a group of them all at once, but they handled it pretty well. Out of the entire time I've been working with them over the last decade, I've had one server fail.

What do I think about the scalability of the solution?

Scalability is interesting because I use their CMC, the Central Management Center. It's a great concept because it allows me to deploy multiple CNEs, which collect the data. Through the CMC I can deploy new decoders; I can have a central point of configuration. I have a central portal to tell my users to go to if they want to look certain things up. The alternate method to that is having an army of single CNEs. You would have to know which one to go, if, for example, there was a channel or feed I wanted to look at. I would have to know it's on this CNE or that CNE to go look at it. The CMC, initially, is a wonderful way to group it all together so the user has a good experience. Administratively, it has some issues. Taking CNEs out is cumbersome, although putting them in is easy. I have two CMCs because, a long time ago, we decided we were going to separate out order flow from our market data, for business reasons. That being done, nowadays, we want to look at how order flow affects market data. Well, they're in two separate silos right now. It's a little cumbersome to get the order flow CNEs to look at CNEs that are monitored by a different CMC. That would be the only negative thing so far with the deployment. It seems to me that a lot of people I've talked to just use the CNE, they don't use the CMC. But the CMC has more advantages than disadvantages.

How are customer service and support?

I really like their technical support. With the support team, it's mostly emails and those can be a little cumbersome. I hardly ever talk to anybody from support. But I have my technical sales representative, and he is very responsive, as is my sales rep. And I can contact them via email or phone directly. I enjoy that. If I had just one little complaint, it would that I can't pick up the phone and talk to support directly more often. I don't even know what their number is. Maybe that's more my fault. But there have been plenty of times when I said, "Hey, I need to talk to somebody on the phone," and it just stays in email.

Which solution did I use previously and why did I switch?

We used two different solutions prior to getting Corvil. There was a company called Seanet. I don't even know if they're still around anymore. They were a good company. They were great with data. But then, along came this sexy, new system called Correlix which beat out Seanet in our company back then. We ran them for a little while and we found that, while they looked great, what was under the covers wasn't as great. Then we went to Corvil. We just researched other options to the Correlix application and my project manager, back then, set up a meeting with Corvil to pitch their wares to us. One of the things that stood out about Corvil was that it had fewer machines, first of all; it handled data better. The data was more accurate. With the previous solution we had, it looked great. It had a fancy front end, but if you wanted to "carry on a conversation with it," it really wasn't there. The keys were the data and information that we were able to get out of Corvil at the time. Granted, Corvil was much more expensive than Correlix because Correlix was free. Correlix gave it away because they wanted your data. That was their model. But their product just didn't hold up.

How was the initial setup?

Our initial setup was quite a while ago. It was somewhat complex.  Turning on a new machine now is pretty simple. Send some traffic to it and their protocol discovery is pretty good at what it does. As a matter of fact, it gives me more stuff that I have to delete later than it lacks. If I get a new CNE in, it takes a couple of days to get the network hooked up, etc., but once it's receiving data, it'll be up and functional in less than a week. We have another group that actually handles the bare metal pieces of it, the racking, the network connections, and the software installation. There are four or five people in that group, but they don't just do Corvil, they do all monitoring tools.

What's my experience with pricing, setup cost, and licensing?

I'm not generally involved in the cost side of things, but I know we bought a box from Corvil and it was $200,000 for one big CNE. Then there are obviously the recurring maintenance fees. The licensing is perpetual but the maintenance fees are not.

Which other solutions did I evaluate?

We had no other solutions on our shortlist. We had Correlix in place.

What other advice do I have?

Understand what you want to monitor and install those packs. Turn it on and see what you get ahead of time. In terms of venue performance analysis, we, being an exchange, are a "venue" the way most people using Corvil would think about it. We are the venue and we don't measure what are our clients are doing. We only measure how a client is being handled within our system. It helps us understand our venue. Similarly, for making order routing decisions, because we're an exchange, we talk to other exchanges. It's not a primary thing we do, but we do monitor those things to see how they're reacting and what our fill-ratios are. But it's not a big deal to us, it's not a primary metric for us. As far as reducing the time to get to root cause is concerned, if you take out the fact that we used to have to wait for logs, etc., we are still looking at a day or two with Corvil in place. We can isolate the symptom down to a very narrow area with Corvil, and a lot of times we will say, "Hey, we think it is this." But to really figure it out, that's when development takes it and goes deeper into the system, where Corvil can't get to. Corvil used to have some type of a hook where they can go inside the system, but we don't utilize that piece. We've monitored a peak count of about 50 users but that is just a number of people looking at it within a certain time frame. Most of them are technical. We have a few business-role folks on the senior management side of things. Usually, those consumers deal with the data after we've output it into a database, churned through it, and made different types of reports. They're not looking directly at the portal itself. We definitely have plans to increase the usage. We're sending more and more data to it all the time. We're making an effort to get off of application logging. We still have about 20 percent more to go to get fully off of application logs. The timeframe for that is over the next year to two years. Overall, Corvil is definitely above a nine out of ten. Everything they claim they do, everything they pitch you on, they do.
Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Director at a financial services firm with 10,001+ employees
Real User
We are able to perform real-time analysis; we can go granular, all the way down to looking at the network packets when troubleshooting
Pros and Cons
  • "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."
  • "Overall, the Corvil device needs a little bit of training for people to handle it. If that could be reduced and made more user-friendly, more intuitive, it would be better."

What is our primary use case?

We use it to monitor our client connectivity latencies, as perceived by the client. We have a number of clients connecting and we monitor their sessions.

The real-time analytics we use are for the electronic trading environment, the client coming into the electronic trading order flow, the buy side and the sell side. That's where we are primarily using it, but we are planning to expand it further in due course to other trading venues. Right now, most of our Corvil devices are monitoring the electronic trading environment.

How has it helped my organization?

Before Corvil, the business side of our company would talk to the client and would get first-hand information on what the client perceived as issues. They would convey that to the networking folks, and the networking folks would try to look into all the issues pertaining to that client. Troubleshooting was a long process. With Corvil, we are able to perform real-time analysis, monitor things in real-time, measure packet level and any packet-level details, and pull out specific scenarios as the case demands, all on a real-time basis. Corvil has enabled us to troubleshoot and analyze problems in real-time.

Previously, we had sniffers placed in the networking area and then we had to capture data and wait for an issue to recur. Then we could analyze the packets. Whereas now, Corvil has made it easy in terms of monitoring the entire network. It reduced the resolution time from days to hours or minutes.

Using Corvil, the time it takes to isolate root cause is less than an hour. If it's a monitored session already, it's easy to drill down and get to the root cause of the problem.

Corvil definitely delivers a performance advantage for our firm over our competition because we are able to address all issues on a near real-time basis. Obviously, clients look for venues that are more receptive to their needs and companies that listen to their issues. That's one of the reasons that most of the client flow is coming to our company.

We have a few devices on the client-facing side as well as on the internal banking side. Our primary focus was to get things analyzed in real-time for the client-facing sessions, and Corvil has helped us a lot on that. We are planning to get into the internals of the network on the banking side. We are trying to get those monitored as well because we have operations worldwide. We have a diverse network and it's good to monitor everything in one central location.

Corvil helps to correlate individual client or trade desk transactions to infrastructure and venue latency. That is what we primarily use it for. We make sure that the fill rates for a certain client are as expected, and the algorithmic trading as well. We look at the way orders get executed in different venues and which venue is giving us better fill rates. It's used for analysis and tweaking. We haven't gone to the extent of tweaking algorithms based on the Corvil analytics, but that will be in the pipeline.

In addition, it helps us to determine where to focus our performance improvement efforts. It frees up the resources who were looking at the network packets and looking at the connectivity and trying to analyze things packet-by-packet. Corvil does most of the job and frees up the folks who were doing that. It gives us a better picture and also gives us a better front end to navigate through. That's one of the reasons we are able to do it in real-time and monitor most of the venues.

We have seen an increase in productivity by using Corvil. At least when it comes to the people who were put to task when there was an issue - who had to set up the sniffers and try to record a session and analyze packets - it was a pretty manual task. That has improved drastically. Now, with the same number of people, we are able to monitor more sessions in real-time.

We run a dark pool and we have a lot of clients coming into it. The clients measure us by the latency we have in matching their orders. It gives us an ability to focus on points in our system that are bottlenecks, that have high latency, and enables us to make the processing speed more efficient and to focus on the right things.

Corvil has also very much reduced the time it takes to provide reporting or dashboards to answer business questions. The overall dashboard and the things that are seen by the trade desk - because they field the questions from the clients regarding fill rates and quality of execution - make it very easy for them to answer questions from the client side. It gives them more information at hand to answer questions from clients.

What is most valuable?

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.

What needs improvement?

To gain the specific knowledge that is needed to reprogram the analytics requires some training - either trained folks from Corvil or for people to go to some Corvil training. If that could be eased up a little, it would be even better. 

Overall, the Corvil device needs a little bit of training for people to handle it. If that could be reduced and made more user-friendly, more intuitive, it would be better.

For how long have I used the solution?

I've been using it for about two years.

What do I think about the stability of the solution?

It's pretty stable. We have never had any issues or any side effects from Corvil being on the network.

The only times we've had issues is when certain sessions that needed investigation were not monitored to begin with. We had to manually add them and then wait for the issue to recur. But overall, as far as the device itself is concerned, we have had absolutely no issues.

What do I think about the scalability of the solution?

Right now, we are running with a couple of devices but, of course, we need more bandwidth. Our networking bandwidth is higher than what the devices can actually handle. That's the reason we are reducing the number of sessions to be monitored to a bare minimum. We would like to scale more. But we need to make some business decisions on where to invest and which sessions to monitor, based on the benefits of monitoring.

How are customer service and technical support?

Corvil technical support is very receptive. We have never had issues with them. Whenever we have had issues or whenever we have had to raise tickets, they have been pretty prompt in responding back. We're happy with their technical assistance.

Which solution did I use previously and why did I switch?

We had a diverse networking team. I'm not sure what other solutions were being used offshore in the Asia-Pacific region or the European region. But I'm not aware of our using anything before Corvil. We used to have some sniffers and things like that placed at random points in the network, but nothing apart from that.

We brought in Corvil because we are one of the few dark pools remaining in the US, one of the largest dark pools, and we wanted to be competitive for all our clients who are connecting to us. We wanted to improve on the latencies being seen on the network from the client's perspective.

How was the initial setup?

Initially, we had some issues, teething issues, while setting up. But over time, we overcame all that by sending folks to get some training and to get more familiar with the devices and more familiar with the network topology. That's a given whenever you set up a new device; you do have teething issues when setting it up the first time. We've learned a lot in terms of setting up the first one and going forward it should be easier.

Our first deployment took about six months.

In terms of our implementation strategy, we were trying to do analytics in real-time; that was our goal, to begin with. Obviously, Corvil offered that solution. We set it up in in a lab environment to start with. And then we made that device production-ready. The initial setup, the testing, and making sure that everything was fine, and then moving it to production, that's what took some time. Going forward it will be easier to add more devices if need be.

As for maintenance, it requires a small staff because, while the device is being used actively, we are not making any major changes. Even the business side gets to view the system through the Corvil interface. When we need changes, that's when we would need someone who is certified in Corvil. That's when we need more experienced folks, but right now it's on "autopilot."

What about the implementation team?

We had just our folks work on it. We had to send a few people to get trained and then do it in-house. We had two people in London and two in New York with enough knowledge and skills. They were people from market links team, who were looking after our client connectivity and the setting up of cross-connects and the like. They were the people involved in setting up this device and adding networking TAPs to get the device up and running.

What was our ROI?

When it comes to order execution and revenue, at this time we are just using it to analyze the network-level details. When it comes to running a dark pool, of course, the side effect of having the best execution is getting better revenue, better order flow. It does help in terms of keeping the system competitive.

I'm not familiar with the dollar amounts, what the business makes from the dark pool, but it has definitely improved in keeping it more up to date and competitive with respect to the other banks that are running dark pools.

What other advice do I have?

If you're looking at retrofitting Corvil to an existing network, it is a little bit involved in terms of where to TAP, to figure out what business data is flowing through. But if it's building a network from scratch, then keep Corvil in mind and get all the analytics captured at the right points. If you have some analytics device like Corvil in mind while designing a network, that will be helpful.

In terms of order routing decisions, that will be connected to the algorithmic tweaking I mentioned. That's coming, but right now it's mostly looking at the client sessions. 

We'd like to get all the sessions monitored. That's one of the highest priorities, as far as the business is concerned. Right now we are hand-picking certain sessions that need to be monitored and leaving the rest because of the bandwidth issues. So the number one goal is to get everything under the Corvil umbrella. And then we would start thinking about using Corvil at the next level to make some routing decisions.

In our company, Corvil is used by the trade desk, which has six people, and in networking there are another six. Overall, around 15 to 20 people are using Corvil in our firm right now.

I would rate the solution at nine out of ten. It gives us everything we need. The only negative is that it needs people who are more skilled to administer and manage the system.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Buyer's Guide
Network Monitoring Software
July 2022
Find out what your peers are saying about PICO, NETSCOUT, Riverbed and others in Network Monitoring Software. Updated: July 2022.
610,336 professionals have used our research since 2012.
reviewer1020198 - PeerSpot reviewer
User with 10,001+ employees
Real User
Helps us understand how much time is spent within our applications processing any particular order
Pros and Cons
  • "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."
  • "We use the data to analyze how much time we spend within the applications. Then, based on that, we are doing multiple analyses and types of investigations to work on reducing the amount of time spent on the latency, which helps our applications."
  • "I have seen errors where the CNE and the CMC haven't synced because of something missing in the CMC, which was there in the CNE. We would get some type of error, but it doesn't actually say what exactly was missing in the CNE."
  • "For FIX protocol, maybe we could have built-in configurations for signatures and decoders. Also, for certain protocols, which are newer, we would like to just add the signatures within the decoders itself."

What is our primary use case?

We use it for checking the latency for different markets, clients, and brokers across different sites and core locations. We are using this internally within our team for measuring latency for different points, across the whole flow, within our applications.

How has it helped my organization?

We can measure the latency. Usually, we are measuring the client round trip and revenue round trip latency for different markets and clients. We are also tracking our internal latency for our applications. So, it has helped us to understand how much time is spent within the applications to process any particular order, how much time it takes for an acknowledgement to come back from the exchange, and then back to the client. It gives us an understanding of how much time is spent in the applications and where we could improve the time within the applications, if there is certain things were improved, e.g., if there was extra time spent within the applications for an order to be processed. We are currently trying to improve this. This is how it has helped my team.

We use the data to analyze how much time we spend within the applications. Then, based on that, we are doing multiple analyses and types of investigations to work on reducing the amount of time spent on the latency, which helps our applications.

Corvil helps to correlate individual client or trade desk transactions to infrastructure and venue latency. We are using it for tracking the client round trip times, as well as the venue round trip times. The time it takes when the order comes in from the client to the time that it takes when it goes out. Plus, we are tracking the times when an acknowledgement comes back from the exchange. So, these are the type of statistics that we are using at the moment.

What is most valuable?

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?

What needs improvement?

Sometimes, when you are saving any configuration and making changes, there are times  something is missing. An error comes up, or sometimes, there is no error. More details around the error, such as, "This is missing...," or "You need to add this particular...," for this session to work would be helpful. While there are errors, they are not very straightforward as to the issue. If you're saving the session, sometimes there can be errors which are not specific to an actual problem. You see that error and have to figure out what it might be related to, searching around the whole session. You scan it up and down to find out what is missing, which is why it is complaining, then you add that. Therefore, we would like to have more specific errors when any particular configuration is missing.

I have seen errors where the CNE and the CMC haven't synced because of something missing in the CMC, which was there in the CNE. We would get some type of error, but it doesn't actually say what exactly was missing in the CNE. I had an issue where it said, "There was some type of error because the CMC is not in sync with CNE," but it wasn't really clear what was missing. I had to go to the session discovery site and found that there were certain channels discovered in the CNE, but not found in CMC. So, then we had to sync it. However, the error wasn't explicit about what was missing in the CMC, which is there in CNE. 

For FIX protocol, maybe we could have built-in configurations for signatures and decoders. Also, for certain protocols, which are newer, we would like to just add the signatures within the decoders itself.

For how long have I used the solution?

Less than one year.

What do I think about the stability of the solution?

The stability has been good. We haven't many updates on the same platform that we are on (9.2). It has been pretty stable. There hasn't been any type of outages.

What do I think about the scalability of the solution?

The scalability is good. We can use it across multiple applications for analyzing the different data. We have it working with eight to ten applications.

The whole of the desk relies on it (around ten people) along with ten people from our support team and a few from the dev team. Everyone within the team is using it (25 to 30 people).

How are customer service and technical support?

The technical support is good. We can get an answer within the same day sometimes. However, if more analysis is required, then they will provide you updates. Often, an issue can be a bit more complex, then it take some time. Usually, if there are any questions or issues, we just send it to the support team, and they will immediately start looking into it and provide some updates on it.

Which solution did I use previously and why did I switch?

To my knowledge, we were not using a prior solution. Before Corvil, there were manual scripts which were running on the servers. This is not the best solution. So, we went to Corvil. 

Previoiusly, it was more of a manual thing, just scripting and getting the stats.

We had so many applications. The flow was getting bigger and larger everyday. Therefore, it made sense to have a better tool which was more automated, like Corvil.

How was the initial setup?

The initial setup was a little complex, like understanding how the whole flow has to be set up within Corvil and what kind of measurements have to be added. It takes time to set up the latency configuration formation. Whenever there is a new protocol, we have to configure the latency setup for different protocols. For example, if you want to put a correlation between the FIX protocol or any different protocol, then we have to add a new configuration.

If this could be something, which could be built into the decoders, then this would help. This is the most complex part of the setting up Corvil. Otherwise, setting up new sessions and everything else is fairly simple. 

It took around six months for the monitoring to be set up from the time when the order comes through from the client to when it reaches application, then when it goes out to the exchange. Now, we have a bit more complex flow which we have incorporated. Since, we now have more understanding and experience on this tool, it take less time to set up a more complex flow: Around a month or so. So, the time frame it takes depends on the types of environments for different flows and on the experience and understanding of these flow.

Our implementation strategy was understanding the requirements, different points in the flow, and the subnet groups for catching the traffic, along with spanning the correct traffic to those CNEs, adding the class maps, etc. We first putting together all of the requirements:

  • What kind of subnet groups do we require?
  • What kind of class maps would be required?
  • What are the different protocols that are need to be used for a particular flow?

Once that is all in place, then we had to work on putting together the configuration and sessions, laying down all the requirements, such as what kind of feature will be required to be able to set up the whole flow, making things easier. If you have everything in place, you have written down what may be required, then you can just fill up those blanks.

When the process was complex, then it took more time. When it was less complex, it took a day or two. This took two people from our front office support team.

After it is deployed, there will be four to five people who will be monitoring Corvil. It is a very high-level tool. There are hourly reports which are generated. We just check whether we are getting the right stats. If something is missing, then we just go back and see what is required to be added, or what needs to be further investigated. Then, we raise a backlog ticket for it.

What was our ROI?

As I am working more with Corvil, it looks like it is improving diagnostic times.

In the cases where we go live with any new client, or if we go live with any new exchange flow, then it helps to know the latency on day one. Then, we can produce the latency comparing it to any other flow or with any other statistics. E.g., if their latency has increased or improved the performance. It definitely helps in doing this.

What other advice do I have?

Corvil is really useful, if you want to produce statistics for your application across different platforms then I would definitely recommend it. It is easy to maintain. You can do a proper analysis around it. The support services are good. You can reach out to people, and they're pretty helpful. Once you start working on it and getting the experience, then it becomes easier to configure new sessions or configurations around different flows.

If more time is spent on the venue round trip's time, there is very little control that we have, because there might be an increase in latency at the venue's site which we don't have visibility of. Therefore, we can discuss with the exchange or market, why there was an increase in latency at this particular time, and whether there was any particular changes at their site or if something was different. If we have those statistic, then we can go to the market or the client, providing them those statistic and talk about them in more detail. For example, why was there an increase or decrease in any particular latency during a certain day?

If we have the venue round trip time from the time it leaves the application, we can just go back to the exchange, discuss this, and say, "Why has it taken so much time?" Maybe there has been scenarios where the exchange or market comes back saying they did some type of configuration changes at that site during that particular time, and that's why there was an increase in latency. Or, they needed some type of changes at their site to improve the latency. This helps in our venue performance analysis.

For different venues, depending upon the application, we have different requirements. For example, for certain application, we target the time that it takes for the acknowledgement to come back, or for the request to go to the exchange, it should be seamless. So, we use different statistic for different markets. Based on that, we can work with different markets or exchanges to match the timings. Or, we use a different routing logic within our application to be able to process the order at the same time. Based on this analysis and the statistics that we have, we can use it to match or change the routing logic that we have. There have been a few scenarios where we have done this.

We are on 9.2 version of Corvil and plan to upgrade to 9.4 over the coming weeks. We are building the roadmap for this year:

  • What is the plan to use it across different application?
  • How many more devices will we need?

They have plans to expand it across different applications. There are certain applications which we haven't already moved onto Corvil, but there are plans to onboard them in the future. We are in the process of building those up. Going forward, we definitely see our usage increasing. Everyday, we have something which we need to analyze and use Corvil. There is higher dependency for a lot of things. We want to look at tracking a smarter routing flow for different flows in different applications as a future roadmap item for us. 

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
User at a financial services firm with 10,001+ employees
Real User
Gives us a complete, real-time view of latency in our platform
Pros and Cons
  • "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's the real-time decoding and getting the latency information statistics that we find the most useful."
  • "Before I got the Corvil training... one thing that was not very efficient was that every time you had to create a new stream or a new session from within Corvil... you had to tell it what protocol the message is going to come through and how to correlate messages, etc... After I went for the training, they had already added these nice features in the 9.4 version where it could do auto-discovery... Based on the traffic that it has already seen, it could create sessions on the fly."

What is our primary use case?

We use it primarily for latency monitoring and capturing latency statistics.

How has it helped my organization?

The product that we offer to our clients internally is a low-latency platform. It's a trading platform and the primary pitch for the product is low latency. We have clients who want to get to the market as fast as they can and that's how we have designed our product and that's what we sell. The way we constantly reevaluate that our product is the best in the market and how it is doing against competitors is by measuring latency. Corvil has done exactly that throughout our product evolution in the last three or four years. I've been using it for two years, but the Corvil installation has been with our firm for a while now, four-plus years.

This information that constantly comes from Corvil is what has helped us to evolve our product in terms of latency. That's primarily how Corvil has helped our product.

In the last year-and-a-half we've also extracted this information and presented it in different ways so we can actually pinpoint, at various points of the day, where we see higher latency or a hit to our median latency. We then want to know, when the latency deviates from the median latency, what has caused it? Our application is Java-based. There's something in Java called "garbage collection." As soon as the garbage collection hits, there's a higher latency and we can actually pinpoint these points from the Corvil data because Corvil has statistics for each individual order throughout the day. So we can look at a certain time of day and get the metrics for that order. We can then go to our application logs and see what was happening at that point and confirm that the issue was Java garbage collection.

We had a client who was concerned with outliers. There is the median latency and, at various points in time, we find outliers which jump away from the median. We can use Corvil data to identify that it was the garbage collection points where the client was seeing pretty high latencies compared to the median. We were then able to redesign our product, make some changes to the JVM parameters, and make the product perform better. Doing so made the client happy.

In terms of the product's performance analysis for our electronic trading environment, as I've said, our application is a low-latency application. We have our own internally developed proprietary system that runs on our own servers. Corvil is sniffing for traffic that comes from the client to our process and through to the exchange and then it's calculating latency between these different endpoints: coming from the client to our servers, from our servers to the exchange, and it's giving us latency. Apart from the network latency, the area where we want more control is inside our process. As I already mentioned, it has helped us improve our product.

The solution helps to correlate individual client or trade-desk transactions to infrastructure and venue latency. As long as the client message or the trader message has the relevant information, you decode it and you have that information. So we have statistics based on client. We have statistics based on exchange. With the new introduction of this Intelligence Hub, which we are still reviewing, you can break it down by any number of parameters, like symbol, or site, etc.

We have all that information. In fact, we were able to break down the information by client because we have a particular instance of our process that just handles client traffic. We get multiple clients sending into the same process and we can see, by visualization, that there's one client who seems to have better performance, another client who seems to have a little degraded performance. Why is that the case? We were able to drill down into it and we saw that it looked like the client who was doing better was trading on a different market which is a particular protocol, a FIX protocol, for example. The other client who's trading on a different market could be on an OUCH protocol. And his trading behavior is different. All of these patterns of trading from different clients on different markets can be drilled down into. In this scenario, it helped us to look at the protocol implementation of our process and see if we could make improvements to our protocol. It actually did help us and we found that there was an issue with one of our protocol implementations. We had to go and fix it.

When you break it down by client or by market you can see which client is performing better, which market is doing better. Then you can drill down into that and see the trading pattern of that client: Why he is doing well, why the other guy seems a little off.

We have also seen increased productivity from using this solution. If I had to go figure out the latency and then see where the problem is, I would have to do a lot more analysis from my own logs, but that wouldn't be as reliable. If I'm capturing anything in my process then I'm adding a latency on top of my processing, as well as disk latency, network latency, etc. Having a source outside of my process telling me how my process is doing is way better than just doing everything from my process. It has definitely helped us improve a lot of things including our productivity.

What is most valuable?

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.

What needs improvement?

Before I got the Corvil training I got information from other colleagues who had already used it. One thing that was not very efficient was that every time you had to create a new stream or a new session from within Corvil - if you wanted to capture new traffic that's going through - you had to tell it what protocol the message is going to come through and how to correlate messages, etc. That was not as efficient as I would have liked. 

After I went for the training, they had already added these nice features in the 9.4 version where it could do auto-discovery. That was a pretty cool feature. Based on the traffic that it has already seen, it could create sessions on the fly.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

The stability is pretty impressive. I have heard that the newest offering of the server is even more awesome. We don't have the newest server yet. Our servers are pretty old, as in a few years old.

We have a couple of flows that are taking a little hit, meaning there is so much traffic coming in that the servers drop packets. But again, that's an old server. We've already spoken to Corvil about it and Corvil has said the solution would be to limit the amount of traffic or get the newest servers that they have. Those have bigger capacity, bigger hard disks, bigger memory, etc.

But the other business offering that we use Corvil for, which I personally support, has no problem at all. There are no dropped packets, it's completely reliable. I wrote what we call our "end of day" process. It takes the data from Corvil and the data from our process and tries to reconcile them, to see if all the data that my bosses get is actually in Corvil. It always comes out 100 percent clean, which means all data is being captured. So the reliability is very high.

What do I think about the scalability of the solution?

For our business, scalability has not been a problem. We don't add sessions every other day or new clients every other day. We don't add a new exchange every other day. We have not reached the capacity in any way. 

Scalability would not be an issue. But Corvil has mentioned that they have better devices now that can handle three times more traffic.

How are customer service and technical support?

Corvil's technical support staff are very amazing. They're very responsive. They come back to us immediately. For example, Corvil provides something called the analytic stream, which is something that you can use in real-time. As I said, I wrote a process which does an end-of-day download of the data into a CSV and then I do more visualizations via CDF. We are trying to see if we can do the same thing in real-time. Mine runs at 5:30pm after the markets are closed. This one is more real-time, so we get the data as Corvil is decoding.

We emailed Corvil support, myself and a couple of other developers, and said we need a connector API, because they provide APIs for different sources. We wanted to use Apache Kafka, which is an open-source platform. We said we need a connector for that. They have pre-built, pre-developed APIs. We said we need an account as well. I did not have a developer account with them. They immediately created an account and put the packet in there, and it was good to go. This all happened within one hour.

They also have a dedicated sales person at Corvil and a dedicated business/technical person who comes and trains us and who can also come and do setups for us. They visit regularly. They come here to check how we're doing and if we need help.

Their support is awesome. I'm very impressed with them. I've been in this industry for ten-plus years and I don't know another vendor who works like this.

What other advice do I have?

My advice is "Go for it." It's an amazing product. Data is power. In the new data era, data is everything. Data is power. Data is knowledge. Corvil does exactly that. It captures data and does a lot of good stuff with the data. I think it's a must-have for any company, not just a company that cares about low-latency. You can capture any kind of traffic and you can do amazing things with the data. It can be used for many things like keeping servers' time in sync, capturing the data at the right time.

I went for training with Corvil about three or four months ago and I got my certification. Our company is now starting to use the full potential of Corvil. When I went for the training I realized that we weren't using the full potential of Corvil yet. We have a very limited installation of Corvil, as far as I understand. We primarily use it for latency. Corvil is not just for that. You can do many other things.

I personally wanted to get the certification because I was so impressed with the product. I wanted to get certification to learn more about the product. It has this amazing view of the entire platform. I have my process, I get messages, I decode, I know what's happening. But Corvil is such a powerful device that it can see the entire network trafficking. It can see everything that's going through your network.

The data can be downloaded as a CSV file. We use that in our own internal application and we visualize it in a different way. One of them that we use extensively is called a CDF graph: accumulated distributed function. If you visualize the same data in terms of percentile distribution - this is a CDF distribution and it's different from a normal distribution - you can see that up to the 95th percentile, the latency seems to be in line with the median. But from 95 to 99 it seems to be pretty bad. And above the 99th it is very bad. Things like that just help visualize data in a different way. Intelligence Hub is going to be able to do all of that, as far as I understand.

For us, Corvil is a supplementary tool. It's not used for major business decisions like improving order routing. One of the things we do to make business decisions is look at the amount of flow. Our process itself captures stuff like that. It's not latency data but the amount of flow, and the rate at which the flow comes. Corvil is able to capture all of that, the number of orders, the number of canceled replaces, and the rate such as 100 messages per second or 1000 messages per second. You can see all of these breakdowns in Corvil itself. We make decisions on our capacity and the like from Corvil. Other than that, I don't believe we would use it for any other business decisions.

The deficiencies that we felt before, regarding maintenance being a little bit difficult are completely gone now. We have started looking into Corvil a bit more and we have dedicated people maintaining it. That was not the case previously. There is now a lot more attention on this product and the maintenance has become easier with the newer software.

In our company there are three users of Corvil who are all developers, and there are three users who provide support for Corvil and for our business. We also have three or four business users who get reports. Those users are pretty technical too, because our business is a low-latency platform. Everyone is technical, in other words. Even the business people are tech savvy. They understand technology. So they use Corvil as well.

In terms of increasing our usage of Corvil, as I said, we are looking at this new offering, the Intelligence Hub. Corvil is an amazing device. When I was doing the training, the trainer mentioned that there are Financial companies with 200-plus servers. I was so shocked. They use it for everything, like phone call monitoring and web traffic monitoring - everything. We use it so little that I was a bit shocked and realized, "Okay, this has so much potential we don't seem to be using". It has changed the mindset a little bit. I've explained it to the business, which knew this from the beginning. They were the ones who primarily installed this. I see our use going up in the next few years. I don't know what the pace will be, but there is a lot more focus on it now. As is with any bank, things don't happen overnight. It will take time and it will grow.

I give the product a ten out of ten because I just love the product.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Network Operations at a financial services firm with 1,001-5,000 employees
Real User
Provides visibility into microsecond timestamping
Pros and Cons
  • "We like the dashboards because they essentially organize all the sessions into one viewpoint."
  • "The analytics feature is very nice, but it's mostly software. We are hoping that it could be embedded in ASICs, so it could be faster."

What is our primary use case?

We are using it mostly for order entry and FIX protocol.

How has it helped my organization?

Most of the tools that we have don't have any visibility into microbursts. Corvil can provide that visibility into microsecond timestamping. It has more granularity into the scope of how data has passed.

The performance analysis that Corvil provides for electronic trading environments is very nice. That is what we primarily use it for: To monitor order routing and order execution to all the venues, as well as to our trading partners. It performs very well.

What is most valuable?

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.

What needs improvement?

The analytics feature is very nice, but it's mostly software. We are hoping that it could be embedded in ASICs, so it could be faster. The competitors are going through providing hardware solutions. So, that's what the trend is, going through ASICs. Hopefully, Corvil can do the same.

For how long have I used the solution?

More than five years.

What do I think about the stability of the solution?

Corvil is pretty stable. We just have too much data going into the boxes. Because of that, it requires more maintenance than average.

We have one person in the USA and one person in Europe maintaining about 90 devices. The product is high maintenance. We have a lot of sessions, more than Corvil's overload. So, we get packet drops, high CPU rates, and disk drive discards.

What do I think about the scalability of the solution?

The scalability is pretty good. We just have to buy another unit and snap it onto the CMCs.

We have less than 100 people using it right now, e.g., market data teams and market data support teams. Since market data rates are going up, we will probably increase our usage in the future. With market data rates going up, we will be getting more clients. Once you get more clients, you have to add more order execution sessions.

How are customer service and technical support?

Their technical support is very good. They usually respond within 24 hours and are very knowledgeable.

A recent example where we contacted support: We had an issue where we installed the latest decoder pack 1812, but it was causing Watchdog errors. They had a fix right away. They found out the decoder which was having issues and recommended installing 1901.

Which solution did I use previously and why did I switch?

The company did not have a previous solution for market data monitoring. They decided to purchase this solution for visibility into market data, order routing, and market data feeds.

How was the initial setup?

The initial setup was straightforward. Everything is almost done out-of-the-box, as the decoders do all the work. Plus, Corvil has session auto-discovery built-in, making it pretty simple.

The previous upgrade was pretty smooth. Though, from the previous version to 9.4, it did take a while. However, once you have 9.4 loaded and install 9.4.2, it's pretty quick. The major releases can take up to an hour per box, but the deltas, like 9.4.2, take about 20 minutes.

The initial deployment process took about a week. This includes prepping switches and dashboards, installing the license, and having LDAP working.

What about the implementation team?

We used our own network deployment team, who handles these type of equipment rollouts. It required two network development engineers.

What was our ROI?

It helps us determine where to focus our performance improvement efforts. We can ensure the round trip time: From the time we push out an order to the time that we receive an ACK back. Before we started using this tool, we didn't have any visibility into this scope of information. Now that we do, we can tweak our performance on the smart order routing (SOR) engines.

Corvil reduces incident diagnosis time. Market data feed going down triggers a traffic detection gap, which will send an alert to our SNMP destination. Without Corvil, it would take 20 to 30 minutes, and with Corvil, it takes a minute. We have incidences pretty often, so this solution is saving us about two hours a week.

We have seen increased productivity from people using Corvil in the bank. From a fixed point of view, they get a look at the data and payload. 

It has reduced the time that it takes to isolate root causes.

What's my experience with pricing, setup cost, and licensing?

The pricing is very expensive. Corvil could work on the pricing.

It is also pricey versus its competitors.

Which other solutions did I evaluate?

The company also evaluated Ixia and cPacket.

I am familiar with Ixia TradeVision, but I don't think it is up to par. They just entered this realm.

What other advice do I have?

Corvil is a great tool. It is the only one of the vendors that has 100% visibility into the market data stream. I would give it a thumbs up.

We break down the latency to each of our clients. It provides the accurate timestamping on most of the sessions that we use for ordering, showing us the time that we send out an order to the time we get our execution report back. So, we can monitor that latency very closely.

We do measure latency of our market data feeds coming down from the exchanges. If it breaches a threshold, we do contact the venues, then they make necessary corrections. This helps us improve our order routing decisions, because if it is too high of a latency, we just go through another venue.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
Senior Network Engineer at a financial services firm with 501-1,000 employees
Real User
Helps us determine where to focus our performance improvement efforts and provides us with venue performance analysis
Pros and Cons
  • "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 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."
  • "The analytics features of Corvil are really good... As long as you know what the field is in the message, you can build your metrics based on that field... It means you can do the analytics that you actually care for. You can customize it..."
  • "There is definitely room for improvement in the reporting. We've tried to use the reporting in Corvil but, to me, it feels like a bolt-on, like not a lot of thought has gone into it. The whole interface where you build reports and schedule them is very clunky."
  • "Alerting isn't great... you can only put in one email address in. And that's for all kinds of alerting on the box."
  • "It's quite difficult to see, sometimes, how hard your Corvil is working. When we had a very busy feed that chucked out a lot of data it wasn't working very well on Corvil. We had to raise a case for it. It turned out to be that, in fact, we were overloading Corvil."

What is our primary use case?

Latency analysis is our primary use case.

How has it helped my organization?

What we've done a lot of work on is tick flow. We generate prices on various instruments, for example DAX Futures. We need to understand, internally, how long does it take for the DAX Future tick to leave the exchange and to exit our pricing infrastructure, which generates the prices and feeds them into the apps that the clients use. We need to know at every step what that latency is.

What we've built in Corvil is a dashboard that shows that. It shows the latency from the exchange to us. Then it shows the latency from us into what we call our MDS system, and from there into our calc servers, which actually do the grunt work of generating the prices, and from there into our price distribution system. At each point, we have a nice, stacked view that shows the latency of each component.

We can look at this and say, "Oh, actually it's our calc servers that are causing the most latency." A good example is that recently our platform guys did some analysis on the kind of improvement we could expect if we put Solarflare network cards in our servers. The analysis showed we could get a 50 microsecond improvement. By using our Corvil data, we could say that, while Solarflare would give us 50 microseconds of improvement, our calc servers alone are generating something like 20 to 30 milliseconds of latency on a bad day. So in the grand scheme of things, spending all this extra money to save 50 microseconds isn't going to cut it when there is a lot more scope to save latency by just rewriting the code on our calc servers. That's a good example of how Corvil helps us. It gives us that kind of level of detail so we can pinpoint exactly where the latency is.

Corvil helps us determine where to focus our performance improvement efforts.
With the tick flow process, we've split it to cover four key parts of our infrastructure. We can see, straightaway, which part is generating the most latency, and that tells us where we should focus our efforts, where we should spend time and effort and money. You have to build that view. You definitely can't take it out-of-the-box and it will come up with that view. You have to understand how your traffic flows, and build that view.

In addition, we do venue performance analysis. A good example is FX pricing. We take all the OTC pricing from various liquidity providers like the Tier 1 banks. Key metrics for us with FX are things like sending-time latencies. We look at that. We always knew anecdotally that one of our feeds was really poor when it came to latency. But without Corvil, we didn't have the numbers to prove it. We could just tell by looking at the quotes from the others to know how far out this particular feed was and from that deduce that the latency was really bad. Corvil helped us show that information in a nice, graphical manner and gave us some metrics to justify a scheme of works to improve matters. Corvil makes it really simple to extract the information required. For example, we are asked sometimes asked something in the line of "Could you supply us with quote ID where you observed these issues," maybe, in some respects, thinking it would take us a long time to get that information. But we can literally, in two clicks, export the spreadsheet and send it to them.

Having latency information helps us improve order routing decisions. A lot of our trading is automated. It's not that the Corvil tool is used to directly feed the automation, but it has provided visibility to allow us to support the process. For example, we can determine precisely when a venue was down and what trades were impacted. That's definitely helpful. We never had that kind of correlation in the past. It was a case of a trader coming up to us and saying, "Did you have a problem with XYZ at this particular time?" We'd have to dig out multiple logs from the network and other infrastructure components and try to figure out what was going on at that time. It allows us to narrow down on the problem a lot quicker. We've got a copy of all the messages, we know what went on at each point. 

Corvil has definitely helped reduce incident diagnosis time. Just the fact that it's so easy to pull out captures or the actual messages, whereas before that was probably the thing that would take us the longest, just getting the data. Before you can start looking at the data you actually have to get the data. Now, it's easy. We just say to the user, "Tell us the time XYZ happened." We can find it, we can zoom in on it, we can extract the messages. It happens a lot of when we're talking to third-parties about latency.

In terms of Corvil reducing the time it takes to isolate root causes, quite a few times we've been able to look at a stream in Corvil and straightaway we can identify what the issue is. A good one is always batching. We can always tell, nowadays, when latency is being caused by batching. We can download the capture straightaway, take a look at it, and it's very easy to see that when a particular venue is sending multiple quotes together, queueing up one behind the other, rather than as they are generated. 

We're definitely able to diagnose things like that really quickly now, whereas before it would be a big struggle to get the data in the first place. If I had to put a number on how much time we save it's at least a good three or four hours.

Finally, the dashboards have helped reduced the time it takes to answer business questions. We sit down with some of the application support teams and say to them, "What do you want to see?" So that's definitely there immediately for them so they don't have to be generating their own stuff. I don't know how much time it saves but the ability's there for them to log in, have a look at their dashboards for their particular products. The information is all there for them.

What is most valuable?

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.

What needs improvement?

There is definitely room for improvement in the reporting. We've tried to use the reporting in Corvil but, to me, it feels like a bolt-on, like not a lot of thought has gone into it. The whole interface where you build reports and schedule them is very clunky and I find that, whereas on the GUI you can pull out all the metrics you want and it's very flexible and nice and easy to customize, the reporting is not very intuitive. And the metrics don't display nicely, as they do on the GUI. It's always a case of trial and error. You add a metric to a report, generate, the report, and find, "Oh, that doesn't look quite right." Then you have to go back in, edit the report and fiddle around. There's no preview button, which would be useful. It's just very clunky and hard to use. We don't use it because it's not great.

Alerting isn't great. It's very flexible in that you can put it in protection periods so it's not constantly giving you false positives. Sometimes if there's a latency spike, and it happens just once in five minutes, we might not particularly care about it. You can configure that kind of stuff with the alerting. But there's other stuff that's really not well thought through. For example, the email address that you use - this is a really simple thing that I've mentioned to Corvil a few times - I'm pretty sure you can only put one email address in. And that's for all kinds of alerting on the box. So we infrastructure guys might be interested if a power supply goes on the appliance, but for somebody in our application team, they don't care about that. They're more interested in: Did the latency go over X in a certain period of time? But because there's only one email address we can put in, it's very hard to manage that. 

The whole alerting and reporting side of things - more the reporting than alerting - definitely needs a bit of work.

Corvil could do a bit more around system performance visibility (although I believe there is an action widget now which can help). It's quite difficult to see, sometimes, how hard your Corvil is working . When we had a very busy feed that chucked out a lot of data, it wasn't working very well on Corvil. We had to raise a case for it. It turned out to be that, in fact, we were overloading Corvil. It was very hard to determine that without raising the TAC case with Corvil. Their engineers have the CLI commands to dig this stuff out.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

We've had no problems at all with its stability. We haven't had a failure, we haven't had to replace one, there's no disk failures or anything like that. You'd think a box like this, with disks constantly in use, that they would be the first things to go. That's been fine.

We did have one issue with a decoder causing the whole capture daemon to crash and restart. That was fixed pretty quickly by Corvil. We said to them, "We keep getting these errors," and they took a look at it and said, "Yeah, it's the decoder." They were able to reproduce it in the lab. We gave them a sample of the data and by the next month - they do monthly Decoder Pack updates - they fixed it. You can tell when that happens because you see in the Decoder Pack release notes "such and such decoder: Improved the robustness of the decoder." That invariably means it was crashing the appliance. That was the only reliability issue we've had but luckily that was specific to one decoder.

What do I think about the scalability of the solution?

I don't have anything to compare the scalability with. Our MDS spits out a lot of data, and it doesn't help that their messages have a lot of fields. This system was causing the Corvil to overload which we had to subsequently manage by being very prescriptive about what flows Corvil sees.

You could argue, in some respects, that it's our fault because in the PoC we probably should have tested it against this particular MDS system. But Corvil doesn't publish the numbers. It's not obvious where to find numbers like "this is the number of flows an appliance can handle," "this is the number of sessions."

So I don't know if scalability is a problem, but Corvil could do more around giving customers the information about how scalable a box would be.

How are customer service and technical support?

Their technical support is really good. I used to work for big organisations where I'm used to dealing with a lot bigger vendors where, when you raise a ticket it goes into this "first-line" type of queue and they don't really do a lot with it. Effectively, they just give you a ticket number, make some notes, and then pass it on to some engineering team.

What's really nice about Corvil is, first of all, you don't have to fill in a web-based form or call some number. You can just email support. You get hold of someone straight away who knows what he or she is doing. There's no passing around. You're straight in touch with someone who understands and can support the product. They don't start asking for things like serial numbers. Straight away you're into, "This is my problem, here are my logs," and they'll help you fix it. And when they do fix it, they're very knowledgeable guys. Most of the stuff is fixed by the person I'm emailing. In a few circumstances they have to go back to "engineering," but most of the time they'll fix it there and then or tell me how to do it. 

Support is really good. Maybe as Corvil gets bigger that will change but I hope not!

Which solution did I use previously and why did I switch?

We didn't have a previous solution. We were running custom scripts and parsing logs before Corvil. We had some latency-analysis tools but they were all things built in-house.

When I joined the company two years ago, the Corvil PoC was going on, so the decision to move to something better was made before my time here. The way they were doing it before Corvil wasn't very scalable. It needed to be centralized. Each team was doing things their own way. It wasn't very joined up. You ended up with a lot of duplication or slightly different ways of doing it. These guys have got other things to be getting on with, rather than doing the analysis. That was the big gap. We had multiple teams using FIX, for example, and one person might build something that showed some kind of metric, how many market-data snapshots we get in X period. Some other team might build exactly the same thing, but in a slightly different way. So we just ended up with this myriad of tools and there was no compatibility between them and there was no easy way of comparing them. 

It was clear that we needed some centralized way. That was one problem. 

The other problem was that none of these tools - they were mostly scripts that people wrote - could work at that nanosecond precision that Corvil gives us. Market data has moved on and the trading has moved on where that kind of granularity matters. Whereas before we could probably get away with it - the millisecond range was okay for us - now, we need to know things like spending this amount on a Solarflare card adds 50 microseconds. We need to be able to measure that 50 microseconds, which was something we couldn't do before.

How was the initial setup?

Our initial setup was straightforward. 4 appliances with a central manager. Our SE from Corvil came in and helped us do the initial setup. It was very good because he let me do the work, just telling me what to do. His attitude was, if you do it, then you will remember how to do it, rather than having him do it for me. That was really good. It was very straightforward. We gave him a few flows that we were interested in and he showed us how to set them up. We had a few follow-up questions which he handled via email. It was very straightforward.

Altogether, the setup took a couple of weeks to get it to where we wanted it to be. Some of that was scheduling because we had to schedule to get this guy in, but from initially unpacking the box and sticking it in our data center, cabling it up, to actually spitting out useful data, it took a couple of weeks.

In terms of our implementation strategy, we did a PoC beforehand, which gave us an idea of how we wanted it set up. From there, we came up with a plan of having one per DC plus the central manager. Once we made the decision to buy Corvil, we put a little bit more effort into thinking about what places in the network we wanted to monitor, where were the key points we wanted to put SPANs and TAPs in. We also thought about how we were going to use our aggregation switches. In terms of Corvil itself, apart from the PoC, we didn't spend a lot of time with it. In some respects, we didn't know all it could do at that point. We knew the basics and we had to make a decision on what we saw in the PoC. So some of that came out during setup. We knew, for example, that we wanted to monitor our FX feeds. But when we got to the day where the SE came, he showed us that we could display this kind of view and have these kinds of metrics displayed. It was a case of, "Oh, you know that's actually good." And then we fine-tuned it from there.

For the deployment, it was pretty much just me involved from our side. Since it was deployed and configured, it has been just me maintaining it. That is a bit of a sore point because it makes me something of a single point of failure. We have to sort that out because it's not sustainable in the long-term.

We have about 15 people using it. They're mostly application development guys. Obviously, we network guys use it for troubleshooting and the like. But in terms of the non-infrastructure teams, they are mostly application developers or those who run those teams.

What about the implementation team?

Implemented via a mixture of Corvil themselves and in-house. Corvil team was excellent.

What was our ROI?

Our ROI is probably more cost-avoidance than anything. Corvil allows us to see where our issues are and then we don't waste money on areas that aren't going to give us the biggest gains. The whole Solarflare example I mentioned elsewhere is a good one.

What's my experience with pricing, setup cost, and licensing?

My perspective can be summarised as Corvil is a bit expensive but you get what you pay for. 

I like the way they've decoupled the hardware now. That makes sense because hardware's a commodity now. It's natural that they had to do that. Everything's based on the licensing side now. The way they do the packs is fair. It iss very flexible in that we are not charged per decoder; we are charged for a certain pack. Whether we use 1 decoder or 20 decoders, as long as they're in the same pack, there's no extra charge.

It's expensive but it's no more than I would expect for this kind of product. They throw in some things for free, which is nice. We've just started doing the UTC clock sync, where you can use the Corvil to analyse your time signals and generate a report. They don't charge for that kind of stuff, which is nice. I remember I was pleasantly surprised when I found that out. 

Expensive but fair is how I'd summarise it.

Which other solutions did I evaluate?

We evaluated the product against ExtraHop which you could argue was not the correct thing to do as the products are targeted for similar but different use cases. We, quite late in the day shifted the PoC towards comparing Corvil with Velocimetrics but as we were running out of time and already liked what we saw with Corvil, we decided to proceed with them.

What other advice do I have?

Definitely understand how your traffic is flowing and remember that Corvil won't magically fix your latency issues, rather help you identify where they are and what impact they are having on your business. Corvil is only as good as the data you put into it, so if you're monitoring in the wrong places, for example, you're not going to pick up the whole story. The advice I would give is to educate your users. You don't just spend money and, miraculously, all your issues are fixed. Rather it will help you understand where your issues are. But to do that you have to know the various application flows, how they work.

Make sure you're monitoring the right places and that Corvil has all the right data, to a high level of detail.

Ideally we would like to use Corvil for other things, apart from just pricing-related stuff. For example VOIP and PTP. I'd like to use it more on the enterprise side. We've got a file-sharing issue at the moment between two locations and if we could get that traffic into Corvil it might be useful to help show us what's going on. There are some powerful analytics on Corvil, especially for network engineers, like the TCP side. We want to use it more for that. Maybe that means we buy another Corvil that is dedicated to those uses. That's where we'd like to go.

Regarding Corvil and productivity, in a small company like this we're not as siloed as they would be, say, in a big bank. Someone in my role is expected to know a bit about the trading side and a bit about protocols like FIX, etc. Corvil has changed the way we work in that it means that we need to know more about how the whole business works.

In terms of what it does, I'd give Corvil a ten out of ten. I've never seen a tool like it.

Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
EMEA Head of Electronic Trading App Management at a financial services firm with 10,001+ employees
Real User
Quickly identifies areas of concern from a performance perspective
Pros and Cons
  • "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."
  • "While the product is scalable, it's not easy to scale. It needs investment hardware and network bandwidth consideration. It's not something you can just do overnight."

What is our primary use case?

We primarily use it for latency monitoring and benchmarking. We look at the geographical location of our servers and European exchanges, using this product to measure the amount of time:

  1. It takes for us to receive an order from a client.
  2. Routing the client's order to the exchange in the exchange data center.
  3. Executing on the order book.
  4. The hops all the way back to the client's execution. 

That latency allows us to establish whether or not there might be any problems with the connection, or understand if we're meeting expectations around latency benchmarks from the clients' perspective.

How has it helped my organization?

The benefits are two-fold:

  1. Corvil is industry recognized. If we provide a client with latency metrics, from Corvil, that it has taken X amount of milliseconds or microseconds for us to execute their order, or reach the exchange. Since it is an industry standard product, the clients recognize and trust in it. Therefore, it's easier for us to demonstrate the performance benefits of our applications, because our clients recognize Corvil as an industry-standard product and trust in it.
  2. We don't have anything internally which would holistically provide the type of granular breakdown of each hop through each of the different systems using different messaging protocols in different applications or in different languages. We wouldn't be able to do it easily with a product that wasn't off-the-shelf, like Corvil.

What is most valuable?

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.

What needs improvement?

The iHub add-on comes with a lot of analytical functionality, which would be nice to have built into the original application rather than as an additional component. Corvil is more focused around high volumes of data and network peak-ups, rather than being able to cut the data in a lot of different ways to use as an analytical tool. While I understand why they have developed the iHub, it would be nice to include it in the Corvil package rather than have it as a separate application.

The configuration could be simpler. It takes a long time to set up. 

Some of the exchange protocol decoders could be published in a more timely fashion. 

They need a bit more consideration around the complexity of their product. This would help in estimating the amount of effort required to get their product deployed and supporting it on an ongoing basis.

For how long have I used the solution?

One to three years.

What do I think about the stability of the solution?

The stability has been good. We have not had any major outages.

What do I think about the scalability of the solution?

With scalability:

  1. The network bandwidth needs to be a consideration, because the traffic is quite heavy. For example, if we were scaling the platform out, we would need to be quite careful, spending some money around our network bandwidth to ensure it didn't impact on our trading.
  2. There are obviously predefined limitations around how many sessions you can have on a CME.

While the product is scalable, it's not easy to scale. It needs investment hardware and network bandwidth consideration. It's not something you can just do overnight.

The primary users run the bank in products and support. There are some users on the service desk, sitting on the trading desk, providing a service function. There are a couple of users on the product desk, more on the execution side of the business. However, there are probably not more than 10 to 12 total users in London.

How are customer service and technical support?

I have had some interactions with their technical support. We have a strong relationship with the people there. Generally, the response has been very good. They give us their time when we need them. My opinion is favorable.

How was the initial setup?

While I wasn't part of the initial installation, I did go through the Tera upgrade, which was a fairly significant build-out. It took a long time, approximately nine months front to back.

What about the implementation team?

The upgrade was very complicated. We had a high dependency on the vendor to assist us with the configuration. It was not easy to configure.

The configuration has a dependency on different message protocols, from an exchange perspective. Also, internally, it needs a lot of bespoke configuration around different languages that we use internally for our systems to communicate. You can't just get the product out-of-the-box and plug it in. There's a lot of configuration work, which had to be done exchange by exchange and client by client. That process took a very long time.

For our upgrade implementation strategy, we prioritized venues and clients. We relied on the vendor a lot to give us time to assist us with the upgrade. I think Corvil probably spent a significant number of man-days (probably a 100 man-days) on this. That amount of time was not necessarily factored into the contract, so they did a lot of pro-bono work for us.

Our experience with them was good. The people are very strong technically and technically aware. They have a strong understanding of their product. We have a good relationship with them. We would like not to depend on them so much. However, part of the reason that we have to depend on them so much is due to the complexity of the product.

For deployment and maintenance, there are probably two to three people from our side, and one to two people from the Corvil side. On our side, there are probably one or two people from a production management perspective, who are actually undertaking the configuration. In addition, there will probably be someone from specialized infrastructure, like a network engineer involved, who would help facilitate things like firewall changes and open up the right ports.

What was our ROI?

This solution help us determine where to focus our performance improvement efforts. It quickly identifies areas of concern from a performance perspective. It allows us to see the outliers and any increases in the median latency, which tell us whether or not there is a specific area that we need to focus on in terms of performance improvement.

Broadly speaking, this solution has reduced incident diagnosis times because it is a tool that we don't have elsewhere. Sometimes, we use it to breakdown issues.

We seen increased productivity from using this solution. It provides us with a holistic overview of the client order flow through client connectivity to our internal components and risk checks in an exchange. This is not something that we can easily provide ourselves. By definition, it increases our productivity because it allows us to have visibility of that flow in a more granular way.

Corvil has also reduced the time it takes us to isolate root causes.

What other advice do I have?

You should try to build an accurate picture of how much effort will be involved in the deployment, then ensure that you have adequate support from the vendor.

This solution helps to correlate individual client or trade desk transactions to infrastructure and venue latency. It allows us to break down the latency performance at both the venue level and client level. So, we can cut the data different ways to look at it, either from an individual client perspective, trading across multiple venues, or we can target the analysis on a specific venue.

By definition, we are measuring the performance of the venue. Though, it's not something that we specifically focus on. As a firm, our focus is more on the things that we can change.

I don't personally have much experience with the analytics features. We have had some discussions with Corvil around an additional product, which is called iHub, which is bolted onto Corvil. It comes with many more analytical tools out-of-the-box. However, with the exception of allowing us to understand and analyze the latency, there is not much else from an analytical perspective that we use the solution for.

The business have their own dashboard, which they configure themselves. We have not really been too heavily involved in giving them dashboards.


Disclosure: PeerSpot contacted the reviewer to collect the review and to validate authenticity. The reviewer was referred by the vendor, but the review is not subject to editing or approval by the vendor.
PeerSpot user
Global Head of Performance and Service Metrics at a consultancy with 51-200 employees
Consultant
It provides a good drill-down ability into transaction flow and causes of latency, but may have difficulty breaking out of the latency niche due to market perception that this is what they do.

The challenge when measuring transaction and market data latency is to do so without impacting upon the latency, which applies especially in ultra-low latency and HFT environments. The Corvil appliance allows passive on-the-wire monitoring and provides latency root cause analysis with a high degree of accuracy.

Architecture

The Corvil Appliance uses FPGA technology to capture and timestamp the data on the wire. Corvil use their own proprietary precision time protocol service to synchronise timestamps between appliances with sub-microsecond accuracy, depending on the distance between appliances.

Data can be acquired from the wire using mirroring, tapping and aggregation techniques allowing the data to be captured in raw packet capture format as well as analysed in multiple domains. The data is written to disc then decoded normalised, persisted, analysed and correlated before being written to the database for reporting purposes.

Measurement and analysis capability

The Corvil appliance supports most commonly used protocols including FIX, FAST, TIB-RV, LBM, Solace, EMS, MQ, and NASDAQ.

Once the events have been recorded, Corvil uses the data to produce a production profile of the monitored system.

A typical report would show the distribution of recorded latency and will identify outliers for attention. The exercise of visualizing the message flows through the system provides a more holistic view of performance management which helps to identify where the biggest gains can be made for the budget available, leading to a quick and pragmatic approach to where improvements can be achieved.

Persisted and normalised messages and performance metrics can be sent to third party systems for real time alerting of any significant deviation from normal behaviour, and can also serve as a source for risk, compliance and other analytic systems.

Streaming Analytics

An added value of on the wire packet capture is the ability to use this data to perform transaction based APM – a feature that Corvil have branded as Streaming Analytics. An auto-discovery feature will identify applications by comparing network headers against a list of known ports, invoking an Analytics plug-in which will reconstruct messages and transactions to extract application specific metrics.

Visualisation and scope

The web-based Dashboard Viewer supports the creation of business-level dashboards that offer instant views of key performance and business analytics. Big Data Adapters enable integration with existing reporting systems such as Splunk, Hadoop, Tableau or Storm.

Additionally, Corvil provides management reporting to schedule regular reports on the network, applications or specific business analytics. For example, infrastructure trending data can be scheduled to run monthly and distributed to network engineering management, or end of day reports to managers on key application metrics, such as user experience performance summaries, server hit counts and application errors.

My thoughts

What's good: 

  • It's a market leader in latency detection and monitoring with extremely precise time stamping even over a wide area.
  • It's got good auto-discovery of message flows.
  • It provides a good drill-down ability into transaction flow and causes of latency.
  • There are a wide range of libraries available to decode different message types on the wire.
  • It's got an attractive way for the presentation of data.
  • It has automated management reports.

What could be improved: 

  • It is perceived as an expensive option, even in the financial services sector.
  • It may have difficulty breaking out of the latency niche due to market perception that this is what they do.
  • It's not got an open API for input or output and can be seen as a bit of a black box solution (which does have advantages but also limits the way in which the product is used).

Disclosure: I am a real user, and this review is based on my own experience and opinions.
Buyer's Guide
Download our free Network Monitoring Software Report and find out what your peers are saying about PICO, NETSCOUT, Riverbed, and more!
Updated: July 2022
Product Categories
Network Monitoring Software
Buyer's Guide
Download our free Network Monitoring Software Report and find out what your peers are saying about PICO, NETSCOUT, Riverbed, and more!