mathpaquette has contributed to 22 posts out of 19969 total posts
(0.11%) in 985 days (0.02 posts per day).
20 Most recent posts:
Just to inform you that I released IQFeed.CSharpApiClient 2.6.0 with the required change in order to limit 50 requests per second to avoid potential exception.
Please review or comment.
Quote: Hi, Gary. I'm confused about the purpose and implementation of the new limit.Hi @taa, can I see your implementation? I mean, 50 requests per second means 3000 requests per minute. How do you get 2 requests per second?
Each day after the main trading session (at 7PM Eastern) I fetch tick history for all the symbols I'm screening. Currently there are 4090 of them.
My first reaction on hearing about the new rate limit was "That's fine; I'm OK with a lower limit, though I doubt I'm hitting 50 requests per second as it is." I run 8 threads, each of which performs history requests sequentially, so there are at most 8 requests in flight at any given time, and it takes a while for each one to complete and a new one to be issued. (The data has to be received, reformatted, compressed, and written to disk before a new request is issued.)
Yesterday, for example, the history fetch took 339 seconds, for an average of about 12 completed requests per second.
Today the history fetch took 2031 seconds, for an average of 2 completed requests per second. Wow; that's quite a change. It's slower than the days when I had a 6Mbps DSL line.
My best guess is that the majority of history requests finish quickly, so they're hitting the rate limit and are being delayed by as much as a factor of 6. However, a fair number of requests take a long time to finish, which drags down the average way below the nominal rate limit. High peak rate, low average rate.
So I'm curious as to whether your intent is to limit the rate at which requests are initiated, or the bandwidth demand on the servers. If the latter, the current approach may be too drastic; my connection is idle more than 80% of the time.
--- Original message by taa_dtn on Dec 23, 2020 07:15 PM
Added 2 additional examples for Python and one is related to what you were asking for.
Please have a look to Streaming level 1 example.
Feel free to create an issue https://github.com/mathpaquette/IQFeed.CSharpApiClient/issues if you need more support.
For the benefit of everyone and for those who want to fully enjoy the true speed of IQFeed without too much compromise, IQFeed.CSharpApiClient is now offering support for Python in most cases. I received a lot of comments how the client is superior in term of performance compared to existing Python implementation.
Have a look and feel free to reply for any concerns.
IQFeed.CSharpApiClient with Python
what do you mean by cross platform client?
I'm curious, which programming languages are you using ?
https://github.com/QuantConnect/Lean (compatible with IQfeed)
Did you check https://github.com/mathpaquette/IQFeed.CSharpApiClient
I already provided a lot of examples to do what you try to achieve.
I added more examples including one with Expired Options:
Thank you so much Tim.
BTW guys, in the newest version 1.4.2 of IQFeed.CSharpApiClient, I've added a very simple way to retrieve those expired options and market symbols.
var lookupClient = LookupClientFactory.CreateNew();
var expiredOptions = lookupClient.Symbol.GetAllExpiredOptions()
.Where(x => x.EquityOption.Expiration >= DateTime.Now.AddMonths(-6)).ToList();
var marketSymbols = lookupClient.Symbol.GetAllMarketSymbols().ToList();
This will take some time the first time but the code will reuse the cached file and check for new update every time.
Hope this helps.
Excellent news Tim, I'm in the process of adding support for this file in the IQFeed.CSharpiApiClient wrapper. Will be very easy to use. Ill post back on this thread once available.
Thank you Tim,
I think we should keep the file option.. For me this is a more convenient way to retrieve expired options. Can you expose to us the long term goal get them at the end?
Guys, dont hesitate to open an issue on GitHub rather than posting on this site.... I think its more related to the project itself.
Will always happy to help you out with that.
Well, if you wish to see the result as a data table, I suggest you to use the Raw facade, i.e. lookupClient.Historical.Raw.ReqHistoryTickDatapointsAsync method and then open up the return filename in Excel as a CSV file.
The reason you it in that format its because I didnt override the ToString in the TickMessage class.
Please dont forget to star the project on github and you can also ask question over there!
Very nice, thank you!
Split.string is the way to go:
Well, I'm still skeptical about the real performance benefit of not using .Split. I'll do some performance tests to conclude on this.
Any updates regarding this request?