FIX/Fast 2.0 coming in April?

, ,
1

Imported from previous forum

2

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

3

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.

4

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.

5

Hi Franck,

I believe this is your first post in the FAST Protocol Forum. May I suggest that you summarize your concerns. I’d be happy to take part in a discussion on the shortcomings of FAST and what, if anything, we can do to improve the current standard.

A lot of people that have been involved for some time seem to be happy with the protocol as is, so you may be able to provide a fresh perspective.

Let us know what you think.

/Rolf

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.

6

Fair comment Franck, and I feel obliged to respond.

The solution is very simple, but it does require a look at the problems first.

First of all, you cannot design against network limitations and waste of MTUs on so many ends.

Second you cannot send enveloped data continously and so badly that you lose context for recovery in any decent period of time.

Thirdly, the aproach of utterly serial nature of FAST design is nothing short of a beginner mistake.

Not only does FAST not reduce bandwidth and latency, it introduces it across the board and pushes us back 20 years in terms of processing rates. No exchange has anything less of an arcane recovery protocol, and no customer end has a satisfactory quality of service in response to this design.

Now ‘preamble’ is in fashion they will repeat the same tragedy for customers and their own network but with more IP ports ‘cleared up’. Moreover, each data vendor introduces their own syntactic and semantic quirks that make it nearly impossible to have any stable progress or standard.

Lastly, the expense of something that was meant to be dynamic/adaptable and standard is proving to be very unstable (years after ‘design’).

Bandwidth is much less of a problem that FAST designers seem to continously tout about. FAST isn’t that good at reducing it when compared against many other and well tested (not few message ‘proofs of concept’) approaches.

As for latency, good luck. I have yet to see anyone claim they can sustain 20GB of data a single exchange spits out in FAST which in effect is nothing more than 2GB a day sustainable by a single box - guaranteeing a response time.

Great job! Great job in reducing bandwith and latency with inefficient and unportable decoding, dictionary resets, bit fidling abstraction the entire industry managed to clear out (apart from finance). And a terrific job in not providing industry standard schemas, and data types that are so obvious but late in the spec. And finally, PMAP and template feature are two opposing concepts if someone failed to pick it up.

It might sound like a flame but it is the harsh reality as you can see on your budget, redundancy and duplication issues, and inefficiency and complexity of implementation. No business responds well to waste of resources and time in trivial data distribution problem.

Distribution should have reliability and sound ‘prevention of circumventing a standard’ in mind first and foremost. But that’s not the politics of it is, ie. exchange-acts-as-an-embassy and sells network bandwidth monopoly rather than access to trading service.

The consortium, as far as I am concerned and patchy Service Packs approach demonstrates it better than anything. It is just another CDS-like stack of cards that sells consultancy and cuts out everyone but the clearing members from usual ‘flashy’ timing.

Optimising for bandwidth but not latency for selective customers in order to sell bandwith is not a choice, it is there by-design from exchanges and clearing members. The lobby is strong but technically not above anything or anyone.

Asking for an alternative at this stage is futile. The structural problems need fixing FASTer, as they are currently SLOW ( Seriously Latent for Objective Wonderworld).

That only means one thing, yet another industry push for another cycle, plenty of new versions and hacks, templates and bit twiddling. It must look important and elitist so a very simple problem remains unsolved while introducing more complexity.

7

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.

8

Hi Robert,

afaik, FPL/mdowg doesn’t plan to release a FIX/FAST 2.0 spec in April. Where have you heard this? Could it be that some exchange or other producer of a FAST feed is planning a release?

/Rolf

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

9

just got a mail a forum reader indicating that the next release of the CME FAST feed has been dubbed “FIX/FAST 2”. I haven’t checked, but I would guess you can get information about this release from the CME web-site.

/Rolf

Hi Robert,

afaik, FPL/mdowg doesn’t plan to release a FIX/FAST 2.0 spec in April.
Where have you heard this? Could it be that some exchange or other
producer of a FAST feed is planning a release?

/Rolf

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

10

The CME’s pdf is located here: http://www.cmegroup.com/globex/files/FF20ClImp.pdf

Title: FIX/FAST 2.0 Launch
New Release Availability: 1 February 2010
Launch Date: 25 April 2010

They claim in the pdf, that FIX/FAST 2.0 will be replacing the current FIX/FAST 1.6. That should give people a hint that they are using their own internal version scheme as what they are calling FIX/FAST 1.6 I implemented using the FIX/FAST 1.1 specification found on this site. I could be wrong about this, but this pdf has the first occurrence of FIX/FAST 1.6 that I’ve ever seen.

just got a mail a forum reader indicating that the next release of
the CME FAST feed has been dubbed “FIX/FAST 2”. I haven’t checked,
but I would guess you can get information about this release from the
CME web-site.

/Rolf

Hi Robert,

afaik, FPL/mdowg doesn’t plan to release a FIX/FAST 2.0 spec in April.
Where have you heard this? Could it be that some exchange or other
producer of a FAST feed is planning a release?

/Rolf

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

11

I looked at the document - this is just a case of confusing documentation and a bit of unfortunate document titling.

This is “CME FIX/FAST 2.0” which I believe is based upon FIX/FAST 1.1 features (the documentation doesn’t say) would be nice if someone from CME could post a clarification.

It would be nice to know which versions of FIX/FAST were used to create CME’s CME FIX/FAST 1.6 and CME FIX/FAST 2.0.

For the record there is no FIX/FAST 2.0 in the plans as Rolf and other’s stated. There isn’t even a FIX/FAST 1.6 which is a good indicator something was amiss.

And Rolf correct me if I am wrong - we don’t have any enhancements being worked on at this time within the working group.

The Market Data Optimization Working Group that oversees FAST is open for participation by any FIX member. We encourage you to participate and contribute.

The FIX/FAST specification is open to anyone to use of course, regardless if you are a member of FIX or not.

The CME’s pdf is located here:
http://www.cmegroup.com/globex/files/FF20ClImp.pdf

Title: FIX/FAST 2.0 Launch New Release Availability: 1 February 2010
Launch Date: 25 April 2010

They claim in the pdf, that FIX/FAST 2.0 will be replacing the current
FIX/FAST 1.6. That should give people a hint that they are using their
own internal version scheme as what they are calling FIX/FAST 1.6 I
implemented using the FIX/FAST 1.1 specification found on this site. I
could be wrong about this, but this pdf has the first occurrence of
FIX/FAST 1.6 that I’ve ever seen.

just got a mail a forum reader indicating that the next release of the
CME FAST feed has been dubbed “FIX/FAST 2”. I haven’t checked, but I
would guess you can get information about this release from the CME
web-site.

/Rolf

Hi Robert,

afaik, FPL/mdowg doesn’t plan to release a FIX/FAST 2.0 spec in
April. Where have you heard this? Could it be that some exchange or
other producer of a FAST feed is planning a release?

/Rolf

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

12

What troubles me about this coming CME change is that they are drifting away the FAST standard. The prepending of sequence number and a “sub-channel” ID, outside the actual FAST message itself, just seems kludge to me.

Of cos, I could understand pragmatically why they are doing it, it allows some “pre-processing” of the message block without incurring the “initialization cost” of FAST decoder. But a well constructed FAST decoder with JIT decoding mechanism can do the job just as it. I look the FAST processor is essentially a bit-shifter (for lack of a better phrase). And with processing speed at 5/6/7M+ msgs / sec, I don’t see the need to deviate from the FAST standard.

I will fire off an e-mail to CME (as an equity member), and see what the thinking behind the scene is.

I looked at the document - this is just a case of confusing
documentation and a bit of unfortunate document titling.

This is “CME FIX/FAST 2.0” which I believe is based upon FIX/FAST 1.1
features (the documentation doesn’t say) would be nice if someone from
CME could post a clarification.

It would be nice to know which versions of FIX/FAST were used to create
CME’s CME FIX/FAST 1.6 and CME FIX/FAST 2.0.

For the record there is no FIX/FAST 2.0 in the plans as Rolf and other’s
stated. There isn’t even a FIX/FAST 1.6 which is a good indicator
something was amiss.

And Rolf correct me if I am wrong - we don’t have any enhancements being
worked on at this time within the working group.

The Market Data Optimization Working Group that oversees FAST is open
for participation by any FIX member. We encourage you to participate and
contribute.

The FIX/FAST specification is open to anyone to use of course,
regardless if you are a member of FIX or not.

The CME’s pdf is located here:
http://www.cmegroup.com/globex/files/FF20ClImp.pdf

Title: FIX/FAST 2.0 Launch New Release Availability: 1 February 2010
Launch Date: 25 April 2010

They claim in the pdf, that FIX/FAST 2.0 will be replacing the current
FIX/FAST 1.6. That should give people a hint that they are using their
own internal version scheme as what they are calling FIX/FAST 1.6 I
implemented using the FIX/FAST 1.1 specification found on this site. I
could be wrong about this, but this pdf has the first occurrence of
FIX/FAST 1.6 that I’ve ever seen.

just got a mail a forum reader indicating that the next release of
the CME FAST feed has been dubbed “FIX/FAST 2”. I haven’t checked,
but I would guess you can get information about this release from
the CME web-site.

/Rolf

Hi Robert,

afaik, FPL/mdowg doesn’t plan to release a FIX/FAST 2.0 spec in
April. Where have you heard this? Could it be that some exchange
or other producer of a FAST feed is planning a release?

/Rolf

Where can I get info about a FIX/Fast 2.0 spec?

Thanks,

13

And Rolf correct me if I am wrong - we don’t have any enhancements
being worked on at this time within the working group.

That’s correct - no enhancements are planned.

14

Jim (and all the rest)
Thank you for making this clear.
As a customer of CME I was having a WTF moment reading the announcement, and being a newbie to the FIX/FAST scene I started to get realllllly stressed with the fact I never even heard about fast 2.0.

My question:
Is my current fix/fast 1.1 decoder should work with this “cme fix/fast 2.0”?

Thank you,
S.

I looked at the document - this is just a case of confusing
documentation and a bit of unfortunate document titling.

This is “CME FIX/FAST 2.0” which I believe is based upon FIX/FAST 1.1
features (the documentation doesn’t say) would be nice if someone from
CME could post a clarification.

It would be nice to know which versions of FIX/FAST were used to create
CME’s CME FIX/FAST 1.6 and CME FIX/FAST 2.0.

For the record there is no FIX/FAST 2.0 in the plans as Rolf and other’s
stated. There isn’t even a FIX/FAST 1.6 which is a good indicator
something was amiss.

And Rolf correct me if I am wrong - we don’t have any enhancements being
worked on at this time within the working group.

The Market Data Optimization Working Group that oversees FAST is open
for participation by any FIX member. We encourage you to participate and
contribute.

The FIX/FAST specification is open to anyone to use of course,
regardless if you are a member of FIX or not.

15

I discussed your question informally with my contacts within CME.

The answer is YES cme-fix/fast 2.0 (let’s call it CME-2.0) is intended to work with a decoder that is compliant FIX/FAST 1.1 standard.

We haven’t had the time to run OpenFAST with CME-2.0 to verify this claim yet. I imagine the QuickFAST folks may have already tested with CME-2.0. You may want to check their forum.

Jim (and all the rest) Thank you for making this clear. As a customer of
CME I was having a WTF moment reading the announcement, and being a
newbie to the FIX/FAST scene I started to get realllllly stressed with
the fact I never even heard about fast 2.0.

My question: Is my current fix/fast 1.1 decoder should work with this
“cme fix/fast 2.0”?

Thank you,
S.

I looked at the document - this is just a case of confusing
documentation and a bit of unfortunate document titling.

This is “CME FIX/FAST 2.0” which I believe is based upon FIX/FAST 1.1
features (the documentation doesn’t say) would be nice if someone from
CME could post a clarification.

It would be nice to know which versions of FIX/FAST were used to
create CME’s CME FIX/FAST 1.6 and CME FIX/FAST 2.0.

For the record there is no FIX/FAST 2.0 in the plans as Rolf and
other’s stated. There isn’t even a FIX/FAST 1.6 which is a good
indicator something was amiss.

And Rolf correct me if I am wrong - we don’t have any enhancements
being worked on at this time within the working group.

The Market Data Optimization Working Group that oversees FAST is open
for participation by any FIX member. We encourage you to participate
and contribute.

The FIX/FAST specification is open to anyone to use of course,
regardless if you are a member of FIX or not.

16

We haven’t had the time to run OpenFAST with CME-2.0 to verify this
claim yet. I imagine the QuickFAST folks may have already tested with
CME-2.0. You may want to check their forum.

I took a look at the CME documentation for FIX/FAST 2.0 and I agree with Jim’s assessment that a compliant FAST 1.1 decoder should work without any modifications to decode the body of the message.

For QuickFAST I had to make some minor changes in the multicast receiver in order to handle the preamble.

At this point these comments are based solely on the documentation. So far there has been no testing of QuickFAST against CME data.

Dale
Principal Software Engineer
Object Computing, Inc. (www.ociweb.com)
Lead Developer of QuickFAST (www.quickfast.org)