[This message was posted by John Cameron of Cameron Edge <[email protected]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/5009ad37 - PLEASE DO NOT REPLY BY MAIL.]
Hi Franck I must admit that I was sceptical when I first encountered FAST. I have a mathematical background and felt that it was unlikely that any significant improvements were likely in the well researched area of data compression. However, when I started to work with FAST, I realized its true value. It is all about CHEAP data compression - "cheap" in the sense of low CPU demands. That is where FAST really does deliver. While working for Orc Software, I wrote CameronFAST, a commercial FAST implementation. I wrote it directly from the FAST specification, and following a few minor clarifications on this discussion forum, I had a working implementation. Two things impressed me: 1. The performance was impressive 2. It connected and worked pretty much out of the box with other, independently developed, FAST implementations - namely implementations from Pantor Engineering, the open source OpenFAST, and CME's FAST implementation. For me, that is a tribute to the precision of the specification. Of course, when it comes to performance, as with any software, careful coding is required. Poor coding will kill performance no matter how clever the algorithms might be. I should mention that I had nothing to do with the development of FAST, so I don't have any particular reason to support or not support the protocol. Also, I no longer work for Orc Software, so I have no commercial interest in CameronFAST or any other FAST implementation. I hope you find this helpful. Best regards John Cameron > Hi, > > I read your flame-thrower post and a few others who ridiculed Fast. Not > being an engineer myself, I am in a stunned position trying to > understand what should be the better solution (if any) to replace Fast. > If there was a consensus on a potentially better and longer-life > solution out there, we ought to debate it. > > My day job is to make decisions on the basis of engineers > recommendations and business common sense, to invest resources where > they are likely to produce longer term benefits. > > Fast has not yet met this criteria in my eyes, but I have not seen an > alternative that does either (criteria includes an amount of consensus > on the alternative choice). > > Do you have one or more suggestions, so we can open a healthy debate to > get other people like me out of their stand-still hesitation ? > > And YES, there is a need to address the bandwidth issues created by > electronic Market Data dissemination needs. > > Thanks in advance, > > Franck MIKULECZ > > > > Where can I get info about a FIX/Fast 2.0 spec? > > > > > > Thanks, > > > > It used to be only available to selected guys from selected bit > > invention commitees and that's how politics work. > > > > But you can get the late info from CME, just ask for it. > > > > But as mentioned before, FAST is a disaster that will keep having new > > versions. > > > > However, this time it is going to get even harder until all the colo > > network salesman and pushers (all major exchanges) are the target of > > the next competition probe. > > > > Welcome to the bit-level, dreadful network and reliability > > designers forum. [You can unsubscribe from this discussion group by sending a message to mailto:[email protected]] -- You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/fix-protocol?hl=en.
