[This message was posted by Hanno Klein of Deutsche Börse Systems <[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/bbf79909 - PLEASE DO NOT REPLY BY MAIL.]
Here we go again. Just in case someone wasted time by reading the post below, it is meaningless indeed. However, it should not stand without objection which I hereby submit. > Yes, you are right. It is meaningless. > > As an example take CME, it produces data (which you have no control over > if you wanted best prices or trades for example) for 6 markets with its > depth. Now, that is an equivalent to an entire output for another > alternative futures exchange does for over 6000 markets. You guessed it > couple of orders of magnitude lost in scalability, and as proven by > <insert exchange> TM ! > > As for FAST, it has been tested on meaningless and small sample data. > Then it got 'approved' and story was sold of bandwidth and latency, wait > for it: reduction! Hmm, what a marvelous achievement, but watch now as > they'll push the depth to 10.. > > Please note you have read the facts above right and can easily verify it > for yourself. That is the equivalent volume in traffic you will get, > FAST encoded, so FAST has little benefit to communication designs that > are as bad; especially TCP tunneled UDP. > > Then you get recovery nonsense as designed as it is, plus bundling of > data you do not want, plus FAST, plus TCP mixed with FIX and FIXFast.. > oh dear. FAST stream is so prone to errors, one byte gone bad will make > you wait a good while (in time, dev and money).. > > FAST apart from introducing huge latency, another fact easily testable > in production exchange data shows a requirement for thousands, sometimes > 100s of thousands of messages a second. That is another matter; so it is > clearly the worst protocol in existence for latency reinvented so far. > Again, if you require data on this try it out with all the vendor > products, consultant designers etc and see for yourself. > > Then bundle the waste of ethernet frame as it is commonly done, bundle > the dictionary requirements, bundle the over-engineered compression > (that is so oddly further compressible), you get the no meaning in > FIXING FAST fever forever.. and voila, you get: > > A clear disaster! > > What's more, it is a disaster that will keep having new versions! (you > will pay for in bandwidth, smart-designs in latency, over-engineering, > smart bandwidth/depth/subscription control, committee ‘sense’ and > telecom resales on the 'upgrade' path). > > An adopter, whether forced or not, really ought to be inexperienced and > young to this industry not to be able to see the flaws from the outset > of the fixprotocol.org. If it is of any reconciliation, all > implementation lunacy, and fat too, eventually gets trimmed. > > Good luck wasting a lot of resources though.. > > Regards, Le Truth [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 -~----------~----~----~----~------~----~------~--~---
