[This message was posted by Rolf Andersson of Pantor Engineering <[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/cf7e8c55 - PLEASE DO NOT REPLY BY MAIL.]
William, thank you for taking the time respond. Your points are well-taken. Please find my comments below. There are a number of knowledgeable and helpful forum members. Let us know if we can be of assistance. Please post your questions and we'll chip in and respond the best we can. Good luck with your implementation. Best regards, Rolf > 20%... I am saying by not using bit 8 in the stream you have > lost 1/8 of the data possibly.. Sorry that is 12.5% None the less, there is an overhead to enable varying length fields. The stop bit can be viewed as a length field that is amortized over multiple bytes. '1'b means 1 byte, '01'b means 2 bytes, etc. In FIX fields are separated by a byte. We made a decision when designing FAST not to use a full byte for separation of fields. > The Fast Fix documentation and sample code. For example just to > understand what the message structure is I have on page 44 a few > words about "Transfer Encoding" with no diagrams etc. Agreed. We have discussed complementing the specification with tutorial documents that describe how to implement and use FAST. As almost all of the standardization work so far has been on a volunteer basis, we have yet to get the tutorials written. > The translation of FIX into Fast is something else again. We have not released a FIX over FAST document yet. It is actually being written just now by a few volunteers and the FAST 1.2 proposal is partly a consequence of the need for further specification to support the FIX FAST encoding. > The documents are really really hard to get to grips with. Also the > sample code is very limited. String Delta operation for example. > Unless I am missing something you have not bothered with that in the > c# sample code but it used all the time. I don't think you are missing anything. If I recall correctly the C# implementation is FAST 1.0 and string delta is a 1.1 feature. Clive and the other guys at Rapid Addition (who wrote the C# refimpl) can respond more in detail. > I used to get EBS LIVE via XML and the code was trivial - literally > a few days work. I am trying to use their new Fast Fix feed but it's > really a nighmare. So far it has taken me about a week and I have > still not logged on properly. I haven't been involved in the ICAP EBS FAST feed, but I seem to remember that they have a few aspects that could be improved. That said, I have been involved in using the XML feed and it's verbose beyond reason. I once did a test where I FAST encoded a 500 MB sample of the old EBS XML feed into FAST. By using fairly aggressive optimizations and relying on a TCP transport for the FAST feed (as with the XML feed) I was able to compress by a factor of over 30. Admittedly, this was in lab conditions and a lot more testing would be needed, but suffice it to say, the EBS folks haven't been very aggressive in their encoding. > Even when i have done all this I see EBS LIVE sends strings like > "SPOT.EUR/USD" down the line. It is all a mess. Yes, symbology is a generic problem. Strings are much more verbose than some enumerated/mapped identifier. The FAST 1.2 proposal contains both enumerations (defined in the template) and maps (defined in the data stream). We had a long discussion on the mdowg confcall last week where Greg Maynard of the ISE described how they had solved the symbol identifier problem in their ISE Depth feed. The ISE feed is one of the empirical sources together with the CME and Eurex feeds for continued FAST standardization. > What would I do instead? I don't pretend to have an answer to that > but for EBS LIVE they could have written a much easier format which > saved a lot of space and was super easy to pass. Using Fast Fix was > a nighmare and a waste of time unless you own a fast fix engine > already. > Why bother with mantissa and exponent when all their prices could > be sent as integer? they have no text data to send just prices so > I would have had no strings in the messages at all. Why send body > length and checksums in the fix over fast stuff. Just more work. I'll not defend their choices, but they had to decide on this when they designed the feed without any help from the mdowg, as we hadn't provided any guidance or best practices at that time. I can see their rationale for including these fields, but I agree with you that it isn't obvious that they should be included. > Why send string timestamps when it takes 40us to turn a time to a > string when you could send an int64 tick time. By trying to do > everything it just turn into a nightmare and > is slow to boot. Indeed, different flavors of timestamps are included in the FAST 1.2 proposal as a parameterized integer data type. [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 -~----------~----~----~----~------~----~------~--~---
