Sterling API Developer Thread
- Thread starter mnx
- Start date
I think I recall reading that Sterlings API only allows 30 orders per second, so maybe that could be why it took long for the 1,800 cancel orders to be sent?
I have a hot key setup on Sterling's front end to do precisely that. If I can do it on the front end, wouldn't that option have to be also available in the API?
From what I've seen, the 30 message limit seems to only be what comes out of the API. You can send WAY more orders than that into it.
I had some numbers wrong but the correct numbers support me even more.
This morning, the 6400 erroneous orders took me 24 seconds to send, about 3 or 4 minutes to cancel.
My best guess as to why having the Sterling platform do the cancels is so amazingly slow is that it waits for a cancel confirm before moving on to the next order? If so, that is completely idiotic.
No, that can't be so, there is no reasoning for that, it would just be stupid.
What languages are you guys developing in? Anyone have quote bottlenecks with .NET languages?
The MDX case I mentioned earlier, what other instances does that happen? It was the first time I noticed something like that today. Generally I run 1 main ATS from open to close, and I load up a few others throughout the day dependent on time and situations. And I usually reregister the same quotes again in the new programs.
The MDX case I mentioned earlier, what other instances does that happen? It was the first time I noticed something like that today. Generally I run 1 main ATS from open to close, and I load up a few others throughout the day dependent on time and situations. And I usually reregister the same quotes again in the new programs.
Well, in C#.NET I can only receive up to about 700 quotes per second when using a counter in the QuoteUpdate event (and nothing but a counter in the event), whereas in VB6 I have received up to 5000 quotes per second and that also includes all the code I execute for my ATS, even including GUI changes.
That's for about 150 registered symbols. Also, I judge lag by comparing the values from the QuoteUpdate for a single stock which receives a lot of quotes with the quotes from a level1 window from sterling using some Win API. The VB code rarely lags by over half a second (during those high volume times), whereas the .NET code begins to lag after just seconds and obviously the lag increases over time because the quotes get backlogged. The majority of the day in VB6, the API quotes show up faster than that you see dislayed in sterling.
I figure it has something to do with .NET using a COM possibly? Maybe this information can be of use. When I was running an older AMD 64 3000+ I could only get 500 quotes out of .NET, but with a C2Q 6600 I get 700.
Very, VERY interesting post ! At first, I didn't believe it, how can VB (interpreted) code be faster than native code ? And how can you get 5000 events/sec in VB while in Delphi i can only get that 700 you're having in C# NET ? I think the answer is 'IDispatch':
http://vb.mvps.org/hardcore/html/dualinterfacesidispatch.htm
My programming knowledge lacks and I don't understand this in depth yet, but the interface seems to be the problem here. Not sure if in Delphi 7 this can be switched (they're talking about version 2 here), but I'll try to find out. If anybody does understand this in great depth and could elaborate on this, that would be highly appreciated
BTW, I just checked the TLB in Delphi:
From some reading I did ( http://dn.codegear.com/article/10043 ) this supposedly means the COM object DOES have a dual interface and "that an application can call its methods using either an interface or a Variant", I really don't know yet how to do that, maybe someone can clarify ? Or maybe I'm way off here and I'm already using the 'fastest' way ? Wish I had some more programming background, really hoping somebody can jump in here and clarify
Hmmm... it seems Delphi 4/5 are already using 'dual interface', which seems to be the same as 'early binding', meaning that the elements of the COM server are resolved at compile time. So it seems that this is not the reason for the delay ?
I'll time monday how many quote messages I can get exactly per second, but I'd say I'm much closer to 500/second than 5000/second, but never really tested it.
I'll time monday how many quote messages I can get exactly per second, but I'd say I'm much closer to 500/second than 5000/second, but never really tested it.