[This message was posted by Matthew Chimento of Barclaps Capital Markets <[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/f54afb9b - PLEASE DO NOT REPLY BY MAIL.]
Zzzzzzzzzzzzzzzzzzzzzzzz > Morning, Consortium, of Vietnam. > > (I never thought I'd be referenced as [1] but thanks, thumbs up :) > > Here is a long and probably my last response to all the incompetence of > fixprotocol.org sponsors, fix and fast especially. > > Plenty of you (but not all and they are the people that obviously help > the community), seem to require ever so much constructive criticism > while refusing to address, 1, one, a single point. Who cares about my > tone if you keep playing a cunning game of self-promotion here? > > This is going on for years and you have examples right there, they are > happening in front of you, right now. > > They are all staring at you; go through each post of every single > person and read it (even on this thread). It has commonalities > across the board. What do you do about them apart from a typical > political response? > > The usual politics of blindness and lets pretend nothing is going on, or > that you are somehow interested in change or listening does not work, > not in the long run. > > > > > > So fine, here we go YET AGAIN and in order. Do note I will not bother > any more without a response that addresses *all* the problems mentioned > over a number of years. Random little comments are no use to anyone and > especially the community. > > > Hanno, just stating the obvious here. Insulting or not, that's a > personal opinion and irrelevant. You should FIX the problem in my strong > opinion. If you do not like something that is mentioned but obvious in > practice than please don't avoid it or shoot the messenger. Not being > able to take a basic technical critique and clear observation is > typical. More to come, see below. Your company is now the leader in > promoting bad designs, dynamics in FAST, regardless of the fact you > moved on from a decade old cave-tech Accenture design. > > Toby, usenet or not, I am old enough to remember it when it came > 'online', and it indeed smacked of guys that are messing up, pushing own > interest and on many groups of similar flavour to this they did! History > repeats itself Watch and learn I guess. > > Mark, the change that is desired is a stop-bit on hacks. Of all tag, bit > and wrong bloated focus to get and *sustain* a valid price. We can get > more technical, but seriously. There is no standard when HSBC alone has > globally over 500 people on their IT support just for the exchanges and > hacking connectivity yet it uses a owning-WA Prime Broker to do the > deals. Sad or funny? > > Joakim, constructive criticism it is, you just need to read it > carefully. I can rephrase but what's the point. There is no data > partitioning the moment you introduce state with lossy protocols and you > introduce it on both ends by the virtue of dictionary and so many things > that are plain bad design. For heaven's sake stop thinking about > primitive instruments being the only one in existence. Parallelizing > streams just because CME is teaching a new dog and old trick of > 'preamble' (great jargon btw I alluded to many times), is giving you > nothing in return. > > The protocol, the encoding, the transitions, the sequences, the whole > lot is as serial and loss damaging the moment you lose a single > transmission unit. It isn't suitable for anything but TCP, and it cocks > up even there. I have been posting about this for years. Partitioning on > product was giving you 17000% greater bandwidth 'utilisation' on average > whether you want it on not. Will 5000% extra traffic instead make it any > better? And btw, they are all valid points and there are 500+ of them if > required, but what for? To create another consortium living of its own > complexity and not dealing with the main issue? Self-interest only? > > Rolf, I'll address you separately in some detail as you are involved in > creating this charade. You deserve it for taking time to produce a mess > and talk brave about numbers (should have known better you light speed > and ns-level people will keep chasing the wrong train). > > > -- FAST DESIGN SPECIALS IN DELUSION HPC CODING! > > Is this, again, going to be a "lets test Turing completeness or > translation knowledge" contest in cryptography a la FAST spec? > > what's up with the mess in sections that 'define' undefined, assigned > and repeat it time and time again just because something is NULLable, > not "optionally present" (say mandatory), or optional, or hey considered > 'empty'? If Codd had any point, the Third Manifesto would never be > available. We are not in relational or crippling all-set theory world. > We are in elements of programming and that means safety.. Compile-time > safety doesn't seem to bother people mixing up the pmap on top of it > all; plus, defining redundant 'operators' and most with no use and > causing an empty Fourth-Fish of codd-kind. > > I will not get into arithmetic coding and how bad you guys have > conceived the entire 'tech' to be, and aimed it at the wrong problem > domain. That's a special story in itself and quite obvious to anyone > that ever bothered to ruthlessly test it. > > Minor point, redefining the terms such as XML qualified name or refusing > to use XML document and InfoSet do not seem like an accident. > > But Rolf, an example, please define the semantics of an "empty" integer > and add the reason why you would even consider adding all three : a > PMAP, template instance and optional attribute on top of it? Plus you > make it nullable and optional and empty and pmap dependent and hey > dynamically imposable. That is so flaky and a known problem out there > (re-read above). > > The document is a farce in terms of confusion-interest and terminology > (but not as bad as CME PDF cobolized authoring). But, it is also pulling > some serious wool (more like a whole sheep) onto the reader. Surely you > can see the operator damage and messy mutable state that are > dictionaries, something that clearly breaks. Do we need to even go into > context of IP protocols again? > > Once again, why hasn't anyone provided clear rules as tables, a concise > summary of rules rather than a glaringly obvious shady FAST > spec/document? Afraid to do it or do you have an interest in not doing > it? Either or Rolf? > > Copying Clarks work (and he is one great technician btw) and putting in > a flaky NG schema is not encouraging either. Bravo on the phrasing > though, it must have taken a while to come up with something that will > not let others spot it immediately. But that bit on dynamic templates, > typerefs, (some terminology from HTTP too) is reminiscent of SOAP 1.1 > and 1.2. Dynamic and utter failure springs to mind! > > So why on earth would you virtualise at runtime something that you > cannot even type or hardly semantically check. Can you guys not see > there is nothing dynamic about the domain data and that playing with it > you can wreck the entire industry? And that you are doing a great job in > incompatibility hankering? > > Was it just so the solution is generic for routing and conversion type > of software? Those typeless systems dealing with conversions to > strings to get the price or typed information not requiring it at all > or at any stage? No, it is obvious, you are pushing incompatibilities > over your initial implementation and 'le lead' in FIX tagging the brain- > dead process. > > My point is clear, do not even attempt to twist it: establishing a hack > on top of hack introduced some safety but plenty of useless encoders and > decoders, and lots of list traffic. > > And the key point is that none of it is good enough, it will break on > many templates, protocols, incorrect, processing will be strained and > you're seeing it strained right at the exchange for many products. And > it will break so FAST as you keep seeing and the reason is so simple: > you have no processors of simple and semantically clear domain > information which is trivial. > > Why? Because you are focusing on the bits not the clearly static type > problem only. Here's a brain dead example: what is the number of lines > of code you need to run to get a best quote for Eurodollar front month > and trade it? Look at those terrible designs and someone do their own > coverage test and report it. It isn't under 30,000 with all the code > underneath and not without 17000% (percent) extra useless traffic on the > wire. So what is that CEO and his support of working group/manifesto > talking about? > > That's exactly why everyone hacks their things on top and provides 'mass > governor' type of COBOL terminology. > > Btw, did anyone tell CME to put their own namespace on top? I thought > so, here I'll get an undergrad to do it and post it to you. But hang on, > it is a global FIX namespace so why bother. Meanwhile shall I tell him > to write an XML comment to state that what they are doing with > timestamps is illegal unless done by the host? > > And what's with the application-type copycat from another standard? Was > it really necessary to divert that far while all of this is global due > to the phenomenal dictionary designs (ugh). > > I could go on and on, but seriously. Someone needs to start fixing that > 5.0 SP623 as well or show them how to form a schema that makes sense > rather than hinting with 'oh-so-mysterious merge' (NOTE paragraphs) in > FAST spec. > > I am not paid to do this, you guys are. I do this for unadulterated love > of FAST and FIX, the fast-fix methodologists (same small set of people > on the list). And since you are paid while creating this mess for > yourselves or to thrive in, well, FIX it yourself :) Sounds harsh but > what do you want me to do, hang? Or hang out and praise you for this, at > the very least, tangential bit focus? > > Bandwidth and latency and reliability and fairness are no problem if you > drop CME network and FAST designs, simple. Demonstrable! Painful! And > someone point out to all the exchange salesmen to not sell what they do > not have or is not required. > > And on hard data, I stated it explicitly a number of times and you keep > coming back with no response. Lets do a comparison to simple > alternatives with a hard, as realistic as it can be, data set, any > decent day data set. Show off the best of shiny FAST and vendors and > then face losing those delusions. MAKE IT PUBLIC, COMPLEX SAMPLE AND > BIG! It will encourage the best of tests and lets compare, without a lab > that does promo machinery and not publicly accessible data. > > Remember validators? W3C is still running them, but lets make it a > public tool that shows the savings in bandwidth, latency, complexity, > manipulation and everything else. Make it something acting as a fully- > fledged in functionality of an exchange distribution system so you get > the meaningful result when comparing. Then you have Apples vs Apples and > you know what they say: you cannot run and hide against the bananas. > > I want to clearly state that you might have deliberately overcomplicated > the spec to edge cases and terminology to gain an advantage for your own > benefit and implementation relying on self interest and promotion. You > either left a window open to defend against it or you are doing it > because you do not know better (I doubt that but some rookie mistakes > were made and you keep saying "we are open to improvements"). What is > needed therefore is not an apology but addressing the issues and > smacking the exchanges if you ask me; a huge and frank simplification > for less fragility and it will lead to lower latency too. > > Hiding behind a marketing lab, 420ns hackers, or dreadful op-code > designers and Russians adopting Chinese tactics in IP theft is typical > of desperation and practices that do not paint a pretty picture if you > have the capacity to think critically. > > But lets get the stats and hard facts and put an end to this so the next > generation has a better chance rather than posting hex on forums (dear > me) or throwing dynamic errors (what IS dynamic in meta definition of > domain : literally, nothing ). > > Thus, a monster was created focusing on the wrong problem, with derailed > focus on top, wrong solution and wrong choice of dynamic solution. > Think, who benefits from it and who is clearly pushing for it? > > Exchanges are helping you jump into the abyss and you are falling into a > trap that they sold you via a consortium sponsored by same people. They > take more money and resources away from the real problem (plus sell you > the reasons for more bandwidth, products, reasons for Deutsche dynamism, > SCP etc). All this is going on while incompetent productions of > specifications are continously approved or around for 5 years!! > > Perhaps all of you (FAST loving) guys are writing a cognitive piece of > magic that thinks for itself what any meaning at any point in runtime > is? Seriously... > > Anyway, what IS the result? > > I would say exchanges will have to break up away from the technology for > one. Incompetence is ripe. > > Here is the damage if you are blind to list traffic from its inception: > All implementations are now open to a huge space of invalid prices, > undefined behaviour, dynamic error invention of fourth-kind, and falling > apart in what now exchange and vendor has full control of. All of this > before you start solving the real problem. What you are all missing is > that it eliticises the free market and deliberately puts your clients at > disadvantage and manipulated risk. It standardized nothing whatsoever > that's for sure. It also selfishly helps the consortium and consultants > only, certainly not the 'community'. > > And if this is a shooting match between who has a faster fast encoder or > decoder, not on marketing paper but hard data, we can do that. Do it as > a side challenge though because it is a pathetic Morgan Stanley or HPC > like exercise and one in broken design and mantra. I will take it on, > but do not forget this will *not* solve the main problem. You all know > what it is by now. Simply use a bit of your heart, plenty of your eyes > and brain and read it all again if unclear about anything. And either > respond to *all* the concerns in context of an ultimate solution not > picking a random bit in stream or fix the problems (yes, pun is yours). > > Alternatively, get real TM and let the community (or people that use > their brain to think and not just follow sheepishly) decide and see for > themselves rather than via consortium self-promotion. Let people see > the data for FAST and sales-driven idiotic distribution choices of > exchanges while their primary upgrade excuses of increasing volume are > fake - it is clearly the implementation choices (of both network and > FAST design level). > > Data on all of this is available, glaring, heart-poking, for years! > > Let people see alternatives for themselves, allow them to make a > judgment for themselves. > > It really isn't that hard to face the music and accept where the > problems are; all of them have been eye-shattering for years now. > > Selfish Mess! > > Sincerely, The Pope and Robin Hood [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.
