|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: quickTick | |||||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||||
|
|
||||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||||
|
quickTick has contributed to 53 posts out of 21185 total posts
(0.25%) in 3,813 days (0.01 posts per day).
20 Most recent posts:
IQFeed Developer Support »
How to create bar from tick data Feb 16, 2023 01:13 PM
(Total replies: 22)
If so, there might be a value in having a third option for LabelAtBeginning, where the label for BeginTime would be at beginning, and the label for EndTime would be at end.
IQFeed Developer Support »
How to create bar from tick data Feb 16, 2023 12:44 PM
(Total replies: 22)
Quote: I was going by your statement "If you intend to ask for a 24 hour period by using 00:00:00 and 00:00:00 as BeginTime and EndTime, and you do it for two consecutive days." In this scenario, if it is an HTT request, you would get the first second after midnight as part of both requests. HIT requests will not have this problem. Your example doesn't show an HIT request using 00:00:00 and 00:00:00 as BeginTime and EndTime. Only the example HTT request does so.--- Original message by DTN_Gary_Stephen on Feb 16, 2023 06:22 AM So far, I would expect two HIT requests for two consecutive days, using 00:00:00 and 00:00:00 as BeginTime and EndTime, to both include the 00:00:00 bar that is between these two days. I believe this according to the example in the documentation. However within a single request that crosses midnight, I would not expect any problem within the middle of the request, as your example shows. I would not expect such a problem for HTT either. The bars within a single request never overlap. Or if they did, that would a bug and completely different. I don't think we have a bug here, just that the documented behavior is easy to misunderstand when deciding which labels to use for BeginTime and EndTime, if you actually want the first bar to be *after* the BeginTime label, and the last bar to be *before* the EndTime label, which is spresumably the case if you use 00:00:00 to 00:00:00 intending to get 24 hour period. Since then, depending on the value of LabelAtBeginning, both the first and the last bar will be either before, or after each midnight.
IQFeed Developer Support »
How to create bar from tick data Feb 16, 2023 04:22 AM
(Total replies: 22)
Within a single request, there is no overlap.
IQFeed Developer Support »
How to create bar from tick data Feb 14, 2023 02:00 PM
(Total replies: 22)
> A 24 hour period would be: [00:00:00 - 00:00:00), that is it starts on midnight, > and includes everything up to but not including the next midnight (less than) That actual implementation appears to be 'less than or equal' for the interval specification. The following example is from the documentation, asking for the days between the 19th and the 30th. It includes both the 19th and the 30th: Request: HDT,GOOG,20080919,20080930,,,TESTREQUEST,2500,0<CR><LF> TESTREQUEST,2008-09-30,425.10,392.32,395.98,400.52,8824587,0,<CR><LF> TESTREQUEST,2008-09-29,423.51,380.71,419.51,381.00,10764969,0,<CR><LF> TESTREQUEST,2008-09-26,437.16,421.03,428.00,431.04,5292751,0,<CR><LF> TESTREQUEST,2008-09-25,450.00,435.98,438.84,439.60,5026917,0,<CR><LF> TESTREQUEST,2008-09-24,445.00,430.11,430.34,435.11,4242795,0,<CR><LF> TESTREQUEST,2008-09-23,440.79,425.72,433.25,429.27,5206644,0,<CR><LF> TESTREQUEST,2008-09-22,454.13,429.00,454.13,430.14,4409119,0,<CR><LF> TESTREQUEST,2008-09-19,462.07,443.28,461.00,449.15,10008745,0,<CR><LF> TESTREQUEST,!ENDMSG!,<CR><LF> So, my current understanding is this: If you intend to ask for a 24 hour period by using 00:00:00 and 00:00:00 as BeginTime and EndTime, and you do it for two consecutive days, you actually get the 00:00:00 interval twice. Depending on LabelAtBeginning, you get either the interval before midnight twice, or the intervall after midnight. Although each intervall begins with .000000 and ends with .999999 microsconds. Only the unspecified values are 'less than', whereas the specified interval is 'less than or equal'. So if you are querying for minute intervals in a 24 hour period, you need to query either 00:00 to 23:59 or 00:01 to 00:00 next day, depending on LabelAtBeginning. Although in each case, the bar before midnight ends with 23:59:59.999999 , and the bar after midnight ends with 00:00:59.999999. Please correct if incorrect in any detail. Edited by quickTick on Feb 14, 2023 at 02:01 PM Edited by quickTick on Feb 14, 2023 at 02:02 PM Edited by quickTick on Feb 14, 2023 at 02:04 PM Edited by quickTick on Feb 14, 2023 at 02:05 PM
IQFeed Developer Support »
How to create bar from tick data Feb 12, 2023 02:21 AM
(Total replies: 22)
I think my previous message needs at least one correction: I asked: "So that at the upper end, 10:40:00 is just a shorthand for saying 10:39:59.999999, regardless of the labelling direction?" However I now think that at the upper end, 10:40:00 is a shorthand for 10:39:59.999999 only if the labelling is at the end. If labelling is at the beginning, it is a shorthand for 10:40:00.999999 . Strangely that seems to mean that at the lower end, with labelling at the end, 10:40:00 stands for 10:39:59.000000 . So labelling at the end seems very confusing if one is interested in that detail at all. The default now seems to be "1" for labelAtBeginning. For that, the range for the whole day appears to be 00:00:00 to 23:59:59 . Which will include 23:59:59.999999 . The specification 00:00:00 to 00:00:00 (next day) would be wrong in either case.
IQFeed Developer Support »
How to create bar from tick data Feb 12, 2023 12:37 AM
(Total replies: 22)
I'm not completely clear on this comment: "It defaults to the end, so "10:40:00" represents 10:39:59 to 10:40:00." The meaning of the text seems to imply that more precisely, it includes only 10:39:59.000000 to 10:39:59.999999. So that at the upper end, "10:40:00" is just a shorthand for saying "10:39:59.999999", regardless of the labelling direction? And 10:40:00.000000 is in the interval labeled "10:40:01", if the labelling is at the end ? The point of my question is to make sure that with labelling at the end, I'd have to ask for "00:00:01" to "24:00:00" to get the whole day. If 24 is an allowed value, otherwise I'd have to take the next days date and "00:00:00". I'm not quite sure I'm asking this question in the best possible way. I wonder if it's more complicated. Or more simple. Edited by quickTick on Feb 12, 2023 at 12:37 AM Edited by quickTick on Feb 12, 2023 at 12:39 AM
Data Questions »
What's Different for Index (VIX.XO) Level 1? May 5, 2021 11:22 PM
(Total replies: 2)
In case this wasn't resolved in the meantime: I've been seeing 15 sec updates for VIX.XO today.
Data and Content Support »
Gap in quotes for @ESH21 around 10:30 am eastern today? Mar 1, 2021 07:56 PM
(Total replies: 2)
Thanks for letting me know! It did come back quickly enough. Edited by quickTick on Mar 1, 2021 at 07:57 PM Edited by quickTick on Mar 1, 2021 at 07:57 PM
Data and Content Support »
Gap in quotes for @ESH21 around 10:30 am eastern today? Feb 26, 2021 03:31 PM
(Total replies: 2)
I had a SERVER DISCONNECTED and a gap of quotes today around 10:30 am. Was it just on my end or a general thing? It was shortly after @ESH21 went below 3800. The second time @ESH21 went below 3800, around 16:00, quotes continued, however the "T" time signal went up to 3 seconds behind. Edited by quickTick on Feb 26, 2021 at 03:32 PM
IQFeed Developer Support »
KB Queued in Admin Status Message Aug 18, 2020 02:22 AM
(Total replies: 6)
According to the documentation, the info about KB queued is available on the admin port, if you ask for S,CLIENTSTATS ON. As you say, it wouldn't make much sense for it to be in the port being queued. Providing the info in the admin port assumes the admin port itself is not queued, which is in fact less likely than for other ports.
IQFeed Developer Support »
Corrupted L1 data-in recent past on multiple products at 'random' times Feb 21, 2019 03:07 PM
(Total replies: 28)
Quote: Attached is the HTT response for @NQH19. @ macNote that the bids do not change for 17 minutes. --- Original message by mac on Feb 21, 2019 07:20 AM In your text file, the bid keeps the value it first acquires at 02:01:12.834878, at the value of 7091.75. That's about a screen down from the beginning. Right in the next line, the bid gets crossed by both ask and trade. Perhaps that is not a coincidence that it happens so close. Perhaps the bid gets stuck because bid and ask cross. For example, somewhere might be code like "if ask < bid", perhaps even as a safety guard, and that code causes it to get stuck at that value. If so, bid and ask probably shouldn't cross in the first place, but that might be just a delay in the delivery of one vs the other. Just a suggestion, since I don't see that on my own screen displaying the historical tick data for NQ, as far as I can tell.
IQFeed Developer Support »
Corrupted L1 data-in recent past on multiple products at 'random' times Feb 20, 2019 04:38 PM
(Total replies: 28)
@ aQuant I'm not sure about which field is which, but it doesn't seem to show the beginning. Do quotes get crossed because they are stuck, or do they get stuck because they are crossed?
New IQFeed Forum »
Best Way to align local machine time and IQFeed server time Feb 12, 2019 02:26 PM
(Total replies: 4)
A quick test: the difference between local NTP time and "T" server time indicates "T" time has a small delay in addition to half of ping roundtrip. Symbols from Chicago have another, yet small, delay on top of that, and symbols from New York a bit higher delay. As far as I can tell, nothing strange or unexpected.
New IQFeed Forum »
Best Way to align local machine time and IQFeed server time Feb 12, 2019 11:31 AM
(Total replies: 4)
There are 'T' messages giving you the server time each second. I haven't tried to use them to synch yet, however I would assume they are sent at each full second.
IQFeed Developer Support »
Corrupted L1 data-in recent past on multiple products at 'random' times Feb 12, 2019 12:18 AM
(Total replies: 28)
As of right, now, I also see the gap in the historical tick data. Or maybe that's where I saw it in the first place. The quotes got stuck at 2707.50, trades do continue (in the historical tick data).
IQFeed Developer Support »
Corrupted L1 data-in recent past on multiple products at 'random' times Feb 12, 2019 12:12 AM
(Total replies: 28)
Today as in 2019-02-11 CST, that is.
IQFeed Developer Support »
Corrupted L1 data-in recent past on multiple products at 'random' times Feb 12, 2019 12:11 AM
(Total replies: 28)
I believe I saw it at about the same time today, for ES.
IQFeed Developer Support »
Fundamental Data Message Feb 8, 2019 08:18 PM
(Total replies: 3)
Quote: Not currently. Sounds good. Do you have an estimated time frame for 6.1 ?
In IQFeed 6.1 we plan to release a new feature that will enable you to download batches of fundamental data by exchange/security type. --- Original message by DTN_Steve_S on Feb 8, 2019 08:51 AM
IQFeed Developer Support »
Cannot get iqconnet.exe to run on Ubuntu AWS Instance (import_dll Library mfc110.dll) Dec 24, 2017 07:23 PM
(Total replies: 6)
Not sure what exactly the output means, but IQConnect has a configurable timeout that determines how long it waits for a client application to connect. This timeout is quite short by default, so it is good to have the client app already trying to open a connection as you issue that command. After that, IQConnect closes automatically. As I said, I'm not sure if your output indicates this situation.
Data and Content Support »
Day/Time when lists and option chains are updated Nov 7, 2017 11:41 AM
(Total replies: 4)
Thanks for the info! So if I load or reload an option chain maybe 1 hour before OPRA market open, there will be no need to check for updates for the rest of the day. Regarding the listed markets, I did a quick comparison of the current list, and the one you have on your website. It seems the listedMarketID is more stable than the shortname. For example, ARCA changed to NYSE_ARCA, yet remained at ID 11. And NMS changed to NGM, yet remained at ID 1 (although ID 21 was added). So does the ID remain the same as long as a listed market exists? For security types, can we expect that types 1, 2, 6, 8 and 9 will always keep their meaning, even if others are added or removed? Edited by quickTick on Nov 7, 2017 at 11:42 AM |
|||||||||||||||||||||||||
