Imported from previous forum
Dear All,
Most people believe that connecting via FIX is slower in cases where the incoming message needs to be translated from FIX to API which introduces an additional step also FIX message will take longer to parse since it is not a fixed format. You have to parse the tags in addition to the values themselves.
could you please share your experiences here ?
Regards
Deepak
Maybe a fussy answered, but you got me triggered!
FIX is slower than some other protocol – yes.
Slower in terms on latency and messages per second. FAST FIX is a lot faster for example. A format with fixed binary structures is always faster than text that has to be parsed – fastest is to send a fixed structure in a binary format, same format as the CPU:s uses for storing values (int, float) etc. Removing all kind of parsing. If the security information is also binary, example is to send “security id=112” instead of “security id=ERIC B”, then you can also remove all kind of searching on the receiving part.
To remove steps in a chain is also removing latency. To have to pass 3 switches in a network is always slower than to only have to pass 2. To parse from FIX to another API is a waste of time.
In general: “Something is always slower than something else”
Exchanges differentiate them self by offer unique protocols. The exchange unique protocol is always faster and offers additional features. This differentiation motivates higher cost in every step (vendors) – and drives the market to offer faster and faster and more expensive solution in terms of hardware, software, bandwidth and all other factors.
If regulators word regulate in such as all exchanges uses ONLY FIX and FAST FIX (a standard), then gates, order management system, market data etc would fast be commodity and vendors become price takers – lovely for us customers. We can then focus on differentiation on a higher level than technical and add some real value for end customers.
This is even a bigger problem with stuffs like market data, structural information such as instrument identifier etc. Creating a lot of jobs, no real added value. Could be mush more efficient.
Until then, lovely time for vendors – hard time for us who have to pay for all the technicians playing with their funny toys.
Market value?
Fairness?
At least it gives me a lot of job.
/ Jan
Dear All,
Most people believe that connecting via FIX is slower in cases where the incoming message needs to be translated from FIX to API which introduces an additional step also FIX message will take longer to parse since it is not a fixed format. You have to parse the tags in addition to the values themselves.
could you please share your experiences here ?Regards
Deepak
Jan,
the term “FIX” unfortunately always gets bundled together with the transport/encoding being used. Therefore, I say that FIX is NOT “slower than some other protocol”. The main encoding of FIX is still ASCII tag=value and that is where the issue is. FIXML and FAST are further options whereby I have not heard anybody say that FAST is SLOW 
I am making this argument because people might not choose FIX at all due to performance concerns. This thread is proof of that. However, there is a huge value in FIX semantics which have become a world-wide standard. Some of the verbosity of FIX semantics have been removed in recent years, e.g. by introducing to allow multiple executions occuring in a single matching engine transaction to be reported in a single message. Jim Kaye pointed to the new High Frequency Trading Working Group (HFTWG) that tries to address encoding as well as semantical verbosity.
I would also respectfully disagree that exchanges differentiate themselves by offering unique protocols. The business services and the associated costs (direct or indirect) should be the driver. Offering unique protocols will be less and less accepted by the community. Only the incumbent exchanges can still afford to mandate a proprietary protocol. The encoding part (e.g. ASCII vs. binary) is not the worst bit of the proprietary nature. You implement it once and it works for all message types across all asset classes. The proprietary semantics are what is really driving the cost for investors (and makes vendors happy as they can charge more for complex multi-exchange applications). Some exchanges try to exploit the “comfort level” created by FPL by re-using FIX field names (without tags) but often enough this leads to false expectations, e.g. regarding the message flows which might be very different from FIX. Unfortunately, semantics go all the way into the core matching engine. Engine developers simply need to have FIX semantics in mind when they develop new systems. Then the usage of FIX for the fastest interface to this system is no longer a contradiction as it is perceived by many today.
FIX 5 introduced transport independence, i.e. you can choose to do FIX over XYZ if you do not like FIX over FIXT. Market data services already choose FIX over FAST, clearing services choose FIXML over AMQP or FIXML over MQSeries. In all cases it is “FIX over some syntax/transport” and not “some semantic over some syntax/transport”. FPL has recognized that it has to provide a high performance transport to remove the incentive for proprietary protocols. This is one of the objectives of the HFTWG.
Regards,
Hanno.
Maybe a fussy answered, but you got me triggered!
FIX is slower than some other protocol – yes.
Slower in terms on latency and messages per second. FAST FIX is a lot faster for example. A format with fixed binary structures is always faster than text that has to be parsed – fastest is to send a fixed structure in a binary format, same format as the CPU:s uses for storing values (int, float) etc. Removing all kind of parsing. If the security information is also binary, example is to send “security id=112” instead of “security id=ERIC B”, then you can also remove all kind of searching on the receiving part.To remove steps in a chain is also removing latency. To have to pass 3 switches in a network is always slower than to only have to pass 2. To parse from FIX to another API is a waste of time.
In general: “Something is always slower than something else”
Exchanges differentiate them self by offer unique protocols. The exchange unique protocol is always faster and offers additional features. This differentiation motivates higher cost in every step (vendors) – and drives the market to offer faster and faster and more expensive solution in terms of hardware, software, bandwidth and all other factors.
If regulators word regulate in such as all exchanges uses ONLY FIX and FAST FIX (a standard), then gates, order management system, market data etc would fast be commodity and vendors become price takers – lovely for us customers. We can then focus on differentiation on a higher level than technical and add some real value for end customers.This is even a bigger problem with stuffs like market data, structural information such as instrument identifier etc. Creating a lot of jobs, no real added value. Could be mush more efficient.
Until then, lovely time for vendors – hard time for us who have to pay for all the technicians playing with their funny toys.
Market value?
Fairness?
At least it gives me a lot of job.
/ JanDear All,
Most people believe that connecting via FIX is slower in cases where the incoming message needs to be translated from FIX to API which introduces an additional step also FIX message will take longer to parse since it is not a fixed format. You have to parse the tags in addition to the values themselves.
could you please share your experiences here ?Regards
Deepak
Hi
I agree, I am just waiting for the cost of our system to decrease insted of increase. As a result of using standards as FIX/FAST etc.
Generic gates, generic market data - all wellcome. Should show result in increase competion and descreast cost soon. Some vendors are not there yet.
/ Jan
Jan,
the term “FIX” unfortunately always gets bundled together with the transport/encoding being used. Therefore, I say that FIX is NOT “slower than some other protocol”. The main encoding of FIX is still ASCII tag=value and that is where the issue is. FIXML and FAST are further options whereby I have not heard anybody say that FAST is SLOW
I am making this argument because people might not choose FIX at all due to performance concerns. This thread is proof of that. However, there is a huge value in FIX semantics which have become a world-wide standard. Some of the verbosity of FIX semantics have been removed in recent years, e.g. by introducing to allow multiple executions occuring in a single matching engine transaction to be reported in a single message. Jim Kaye pointed to the new High Frequency Trading Working Group (HFTWG) that tries to address encoding as well as semantical verbosity.
I would also respectfully disagree that exchanges differentiate themselves by offering unique protocols. The business services and the associated costs (direct or indirect) should be the driver. Offering unique protocols will be less and less accepted by the community. Only the incumbent exchanges can still afford to mandate a proprietary protocol. The encoding part (e.g. ASCII vs. binary) is not the worst bit of the proprietary nature. You implement it once and it works for all message types across all asset classes. The proprietary semantics are what is really driving the cost for investors (and makes vendors happy as they can charge more for complex multi-exchange applications). Some exchanges try to exploit the “comfort level” created by FPL by re-using FIX field names (without tags) but often enough this leads to false expectations, e.g. regarding the message flows which might be very different from FIX. Unfortunately, semantics go all the way into the core matching engine. Engine developers simply need to have FIX semantics in mind when they develop new systems. Then the usage of FIX for the fastest interface to this system is no longer a contradiction as it is perceived by many today.
FIX 5 introduced transport independence, i.e. you can choose to do FIX over XYZ if you do not like FIX over FIXT. Market data services already choose FIX over FAST, clearing services choose FIXML over AMQP or FIXML over MQSeries. In all cases it is “FIX over some syntax/transport” and not “some semantic over some syntax/transport”. FPL has recognized that it has to provide a high performance transport to remove the incentive for proprietary protocols. This is one of the objectives of the HFTWG.
Regards,
Hanno.Maybe a fussy answered, but you got me triggered!
FIX is slower than some other protocol – yes.
Slower in terms on latency and messages per second. FAST FIX is a lot faster for example. A format with fixed binary structures is always faster than text that has to be parsed – fastest is to send a fixed structure in a binary format, same format as the CPU:s uses for storing values (int, float) etc. Removing all kind of parsing. If the security information is also binary, example is to send “security id=112” instead of “security id=ERIC B”, then you can also remove all kind of searching on the receiving part.To remove steps in a chain is also removing latency. To have to pass 3 switches in a network is always slower than to only have to pass 2. To parse from FIX to another API is a waste of time.
In general: “Something is always slower than something else”
Exchanges differentiate them self by offer unique protocols. The exchange unique protocol is always faster and offers additional features. This differentiation motivates higher cost in every step (vendors) – and drives the market to offer faster and faster and more expensive solution in terms of hardware, software, bandwidth and all other factors.
If regulators word regulate in such as all exchanges uses ONLY FIX and FAST FIX (a standard), then gates, order management system, market data etc would fast be commodity and vendors become price takers – lovely for us customers. We can then focus on differentiation on a higher level than technical and add some real value for end customers.This is even a bigger problem with stuffs like market data, structural information such as instrument identifier etc. Creating a lot of jobs, no real added value. Could be mush more efficient.
Until then, lovely time for vendors – hard time for us who have to pay for all the technicians playing with their funny toys.
Market value?
Fairness?
At least it gives me a lot of job.
/ JanDear All,
Most people believe that connecting via FIX is slower in cases where the incoming message needs to be translated from FIX to API which introduces an additional step also FIX message will take longer to parse since it is not a fixed format. You have to parse the tags in addition to the values themselves.
could you please share your experiences here ?Regards
Deepak
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
FIX FAST may be fast, but is it popular? The CME use it but who else?
Anyone care to comment on this?
Maybe a fussy answered, but you got me triggered!
FIX is slower than some other protocol – yes.
Slower in terms on latency and messages per second. FAST FIX is a lot faster for example. A format with fixed binary structures is always faster than text that has to be parsed – fastest is to send a fixed structure in a binary format, same format as the CPU:s uses for storing values (int, float) etc. Removing all kind of parsing. If the security information is also binary, example is to send “security id=112” instead of “security id=ERIC B”, then you can also remove all kind of searching on the receiving part.To remove steps in a chain is also removing latency. To have to pass 3 switches in a network is always slower than to only have to pass 2. To parse from FIX to another API is a waste of time.
In general: “Something is always slower than something else”
Exchanges differentiate them self by offer unique protocols. The exchange unique protocol is always faster and offers additional features. This differentiation motivates higher cost in every step (vendors) – and drives the market to offer faster and faster and more expensive solution in terms of hardware, software, bandwidth and all other factors.
If regulators word regulate in such as all exchanges uses ONLY FIX and FAST FIX (a standard), then gates, order management system, market data etc would fast be commodity and vendors become price takers – lovely for us customers. We can then focus on differentiation on a higher level than technical and add some real value for end customers.This is even a bigger problem with stuffs like market data, structural information such as instrument identifier etc. Creating a lot of jobs, no real added value. Could be mush more efficient.
Until then, lovely time for vendors – hard time for us who have to pay for all the technicians playing with their funny toys.
Market value?
Fairness?
At least it gives me a lot of job.
/ JanDear All,
Most people believe that connecting via FIX is slower in cases where the incoming message needs to be translated from FIX to API which introduces an additional step also FIX message will take longer to parse since it is not a fixed format. You have to parse the tags in addition to the values themselves.
could you please share your experiences here ?Regards
Deepak
Yes it is popular, please check FAST protocol - Wikipedia. I believe the list is incomplete.
FIX FAST may be fast, but is it popular? The CME use it but who else?
Anyone care to comment on this?
As a FIX technology provider, I can tell you usage is growing.
An example in EMEA is NGM Elasticia: they joined the club last year
http://www.ngm.se/elasticia/
Yes it is popular, please check FAST protocol - Wikipedia. I believe the list is incomplete.
FIX FAST may be fast, but is it popular? The CME use it but who else?
Anyone care to comment on this?
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
I think I’ll pass on the references to wikipedia. I am sure that anyone who uses it would be happy to share that knowledge here.
Yes it is popular, please check FAST protocol - Wikipedia. I believe the list is incomplete.
FIX FAST may be fast, but is it popular? The CME use it but who else?
Anyone care to comment on this?
I think I’ll pass on the references to wikipedia. I am sure that anyone who uses it would be happy to share that knowledge here.
??? - Sounds like there is something you are trying to tell us here without saying so…
[ original email was from John Greenan - john.greenan@alignment-systems.com ]
If there’s something I want to tell you Hanno, I will tell you.
I’m asking a pretty simple question, who uses FAST. So far Michel Balter has said one of his clients does, I know the CME does and you have pointed me at wikipedia.
I think I’ll pass on the references to wikipedia. I am sure that anyone who uses it would be happy to share that knowledge here.
??? - Sounds like there is something you are trying to tell us here without saying so…
I think I’ll pass on the references to wikipedia. I am sure that anyone who uses it would be happy to share that knowledge here.
I’m the lead developer of QuickFAST – an open source implementation of FAST – and the moderator of the QuickFAST users discussion list and I can assure you that there is a lot of interest in FAST and there are quite a few market data sources using it.
People don’t always identify the source with which they are working on the mail list, but a sampling from recent messages includes:
BATS
CME Group (CME)
Eurex
EBS Live
ICAP
International Securities Exchange (ISE)
LSE-Millennium IT platform
NYSE Archipelago
NYSE ARCABook
NYSE LIFFE XDP
OMX
OPRA
SWX
Xetra (trading system)
[There are some duplicates. People refer to the same exchange in different ways, and I didn’t really clean this list up – I just piped the messages to a file, deleted everything except the data source names, sorted and “uniqued” it.
Dale Wilson
Principal Software Engineer
Object Computing, Inc.