|
PureBytes Links
Trading Reference Links
|
Hello Joel,
> Also, I was told that IB has multiple points of entry into their
> platform and if one of them fails the "proxy" that I am to build can
> switch to a different entry point.
I don't quite understand this. Are you referring to your application
connected to IB's API getting bumped from one of their servers and
automatically connected to a new server?
Anyway, yes, the data feed providers must use the exchange-provided time
stamps in order for this to work. I think this is required by the
SEC, otherwise we have a ridiculous bucket shop situation.
1)
Create a thread-safe hash table object as follows:
(In VB.NET)
=================================================
Private MyHashtable as Hashtable
MyHashtable = Hashtable.Serialized(New Hashtable)
Public Enum DatafeedProvider
Provider1
Provider2
Provider3
Provider4
End Enum
===================================================
2)
Pass your ticks as strings from all your datafeeds, as they arrive in
realtime, to the following subroutine:
==============================================
Protected Friend Sub ProcessTicks(ByVal Tick as String, ByVal Source as
DatafeedProvider)
SyncLock MyHashtable.SyncRoot
If MyHashtable.Contains(Tick) = False then
MyHashtable.Add(Tick,Source)
SaveTick(Tick, Source)
Elseif MyHashtable(Tick) = CType(Source, DatafeedProvider) Then
SaveTick(Tick, Source)
Else
RecordMatchLatencyStatistics(Tick, Source)
End If
End SyncLock
End Sub
==============================================
In the SaveTick Subroutine, the ticks will be unique at one second
resolution, and always from the faster datafeed. Of course, you must make sure that the tick
string formats are identical from each datafeed provider, to avoid
something like this:
Datafeed1 = "ESU5,9:05:30,1205.50,1"
Datafeed2 = "/ESU5,9:05:30,1205.50,1"
Datafeed3 = "ESU5,09:05:30,1205.50,1"
(As you know, hash tables can point to any object type. I'm assuming that the
data feed provider is sending you the ticks as strings already.)
The other issue is the lack of millisecond resolution. Suppose
several trades having identical volumes and prices trade within
milliseconds of each other:
"ESU5,9:05:30,1205.50,1"
"ESU5,9:05:30,1205.50,1"
"ESU5,9:05:30,1205.50,2"
"ESU5,9:05:30,1205.50,1"
"ESU5,9:05:30,1205.75,1"
"ESU5,9:05:30,1205.50,1"
"ESU5,9:05:30,1205.50,1"
We now must assume that each datafeed provider does not send
duplicates (of course, you'll know the truth of this from your
matching statistics.) So, we add the ElseIf condition above, which saves these identical
trades but only from the same datafeed provider, ensuring that these are
not redundant. The small caveat is that you must rely on this single
provider for the completeness and accuracy of this split-second flood
of trades having identical price and volume.
One general comment on millisecond resolution: You run into all sorts of
computer and internet-related artifacts, beginning with the Exchange
Server itself. To name a few, you have the sending of packets through the
internet. You also have ticks getting piped through several
multi-theaded environments, causing bursts of queued-up ticks leading
to distortions at the millisecond level.
And finally, Memory. Unless you have gobs and gobs of RAM, you will
need to envoke a MyHashTable.Clear() method at periodic intervals,
which must be synchronized with the change of the 1-second time stamps
coming from the exchange.
-F
Thursday, June 30, 2005, 11:35:08 PM, you wrote:
> Frank,
> I would gladly discuss the merits of technology with you but we
> should probably do it offline so as not to bore the others.
> A couple of people suggested an interesting application. I'm very
> eager to build a prototype but would like to run it by this list...
> The idea is having a technology that could monitor 2 or more data
> feeds, matching and confirming the accuracy of the data as well as
> monitoring and reporting on excessive latency in either feed is an
> example.
> Also, I was told that IB has multiple points of entry into their
> platform and if one of them fails the "proxy" that I am to build can
> switch to a different entry point.
> Is this a problem that's common to a lot of you?
> How would you match and confirm the accuracy? We are talking about
> matching ticks? This would require that the data feed providers in
> question send you an exchange-provided time stamp with every tick,
> right?
> Thanks, Joel
> On Jun 30, 2005, at 8:42 PM, Frank Fleisher wrote:
>> Hello Joel,
>>
>> There has been a lot of "catch-up" in the realm of multi-threading,
>> networking, and clustering. Erlang would have made sense in the 90s,
>> but today I would stick with more standard and widely distributed
>> architectures like Microsoft's Remoting.
> --
> http://wagerlabs.com/uptick
|