开云体育

A>> Can you give a definition of "biggest movers" ?
Because if you look at TradeRate or VolumeRate, they can be very high on a big MarketCap while simultaneously the PERC_GAIN stay rather small, however this instrument maybe the top mover
a contrario: a small MktCap with a 10% TOP Gain is most probably a very dangerous bet, could even be an exception like during a short squeeze.

B>> The IB Scanner is a wonderful tools and nearly fully accessible trough the API but it is also the most complex (IMHO) request to setup.
I am not surprised that IB doesn't give more info about it because it's fluctuating, and it is tedious to explain the way it can be parametrized.

Your question is a Pandora box it require preliminary that:
1- You are really familiar with it on TWS and very aware of what "filters" allow you to do.
2- You are familiar with XML format to parse and use it.
IBK API send on request the whole available rules as a XML,? see attached XML fetch with a as of today.

For now you can peep in it and guessimate what can be used to patch existing coarse example IB supplied for scanner subscription.
Do search with the UI exact TWS text name and you will find a <displayName> rubric? within a <ScanType> section this give you the <ScanCode> to use.

But best is to parsed it to get the <ScanCode> that you wish to use and then re-index trough <instruments> to see what <RangeFilter>? to use and adjust, in order to match the combination that you can setup in TWS which fit your bill.

It proves that callbacks CANNOT be process anywhere else.
It proves that your callbacks will be processed in same thread and sequentially. (if you have a single eReader which is the typical and the default implementation)

Not sure I follow your concern or understand the case you mention, "isn't done in the other thread*. " ? Which other thread ? Launched by what ?
Message are thrown away once processed and 'callbacked'. Even if a dormant thread exist somewhere (how was it launched ?) it won't catch anything.

Note:
Don't try to create multiple eReader, it's touchy and not the smartest way to parallelize processing.
Massive but blind multi-threading is not the solution. You are serialized by the recv from the connection.
If speed is of the essence you will rapidly see that you need to sort urgent processing from lazy one, and this factored by long processing vs short.
So prioritizing will most likely lead to a message queue dispatching implementation to a thread pool of your own.? Make sense but this is NOT something to start with when "onboarding" the API and anyway it better be piggybacked on existing IB code
Trust a simple implementation, the IB Client codes sample are safe and well designed to make your life simple.

Note:
VisualStudio Code (work Mac/Linux) is pretty efficient to track calls of methods/procs, goes way beyond plain old 'grep', with a pretty developer display of results (clickable) Not tried on Linux.

I have a specific query about how the TWS API adjusts option price calculations in the presence of an ex-dividend date. Below is the full context and what I've tried so far.

IB offers as part of the API IBApi.EClient.calculateOptionPrice. These return the option price as well as the greeks. I've been able to replicate the calculations they do using an off the shelf option black scholes python module ( for those interested). It returns the same greek values to within 4 decimal places of accuracy, e.g. say the delta is 0.2542 from the TWS API, pyvollib returns 0.2541. However, this changes when there's an ex-dividend date during the lifetime of the option.

Black scholes doesn't take early exercise or the impact of dividends causing a price drop into account, so this requires so modifications to the calculations. There's a couple of ways to account for the dividend price drop but none of them seem to match up with the TWS API calculations. Approaches that I've tried:

• reducing the underlying price by the present value of the dividend
• include a term for the annualized dividend rate in the bs model

There was a third approach that I tried but can't find the details of it in my notes.

When I messaged the TWS API team, they got back saying it was the TWS team proper that was responsible for the calculations. And then after following up with the other team I still didn't get any response. I'm hoping someone here has insight into IB's methods.

So, to the experts in this group, do you have any insights into how IB modifies their option price calculations when an ex-dividend date is within the lifetime of the option?

I do not wait for anything, the only thing I do is my order send function is synchronized:

No
Assuming you use a basic implementation, as in the supplied example. You do not have more default processing thread than your number of eReader, typically a single one.
So then all callbacks are processed in same thread as the one that process messages. IB hide for you the multithread queuing of messages in your processing thread, you don't have to worry about it.

Hence they are processed sequentially, This could be in a very different order than request messages, typically "orders" messages are processed faster than "data request" messages)

Typically the reader loop is made of
?? ???? while( client.isConnected()) {
?? ???? ??? client.processMessages();
?? ???? }

and zooming in client.processMessages(); you typically find
??? m_osSignal.waitForSignal();
?? ?errno = 0;
?? ?m_pReader->processMsgs();

How it work:
In same thread (and in the supplied example in main() thread )

on an Inbound Message=>Free m_osSignal.waitForSignal(),
then typical next step is to run a m_pReader->processMsgs(); => which loop on all existing messages (Normally one but could be more that arrived since you get there, this depend upon how slow you process a previous salvo of messages) ,
Messages? are process in the order they arrived using a EDecoder processMsgsDecoder_;

Look code in
void EReader::processMsgs(void)

and? in
int EDecoder::parseAndProcessMsg(const char*& beginPtr, const char* endPtr)

No mystery.

If you want to see how message queue is thread safe, look at EReader::getMsg(void)? you will see a scope lock method using m_csMsgQueue as lock

Thank you for following up because I actually did *not* understand.

”It is this [the main] thread that dispatches to your EWrapperImpl callbacks.” This makes it sound like all reading and writing to state variables I care about is done in one thread, the main thread.?

“So in C++ the message reading and the callbacks are on separate threads.” This makes it sound like two threads are calling functions that read/write important state variables, which means I have to be more careful.?

so to confirm: callbacks like execDetails and orderStatus and tickByTickLast can get called by a separate thread, possibly leading to race conditions, which necessitates synchronization of state variables such as current position, etc.

The data that was attached to your post seems to be for 08:32:57 US/Central, one minute later than when the STOP order happened at 08:31:57 US/Central. Prices during the STOP order second were much jumpier.

Just looking at changes of Bid and Ask price does not give you a good picture of what the order book looks like and whether there is "great activity". Level II can help since it is a snapshot of the sizes for all prices in the order book at and above Ask as well as at and below Bid. At the end of the post is a snapshot for NQZ3 just after trading started at 17:00 US/Central on Sunday. If you have subscribed to Level II data for CME, you can use the TWS "Level II" window (the top window below) and the "Book Trader" (bottom window) to look at 10 levels for the buy and sell side each and your client can request the data as well:

• NQZ3 had only ~40 contracts available for trades within $2.50 of Bid and Ask respectively ($5 range). With such a thin order book, even relatively small institutional orders can push prices around considerably. And the order book cannot have been much fuller in the 08:31:57 second since Bid and Ask sizes were smaller than this.

• Just for comparison, ESZ3 at the same time had ~400 contracts each

• and the ZN futures front month had ~3,200

Paper trading is a simulation, and as such, "always wrong but mostly useful". So you cannot expect that executions exactly match those that would have taken place in a live account at the same time. But as @fordfrog indicated, executions in the paper account closely follow those in the real exchange and in thin order books (such as NQZ3 at start of trading today and on the morning of October 5) even in live trading prices can briefly take place $10 or more away from Bid and Ask.

I can't think of anything more you can analyze for this historical case. Going forward, you could subscribe to Level II data, record the 20 levels of order book details IBKR provides, and use them for analysis for case where you feel simulated trade prices were "too far away" from Bid/Ask. But keep in mind that not all orders make it into the order book and that some (even large) trades are not reporable or reported. So there will always be a some uncertainty.

闯ü谤驳别苍