What needs improvement with Corvil?

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.

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.

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.

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.

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.

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.

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.