Joined: |
Sep 29, 2009 11:02 PM |
Last Post: |
Nov 16, 2010 09:24 PM |
Last Visit: |
Jan 16, 2012 05:38 PM |
Website: |
|
Location: |
Vancouver, BC |
Occupation: |
|
Interests: |
|
Avatar: |
|
|
AIM: |
|
ICQ: |
|
MSN IM: |
|
Yahoo IM: |
|
|
DavidG has contributed to 8 posts out of 21251 total posts
(0.04%) in 5,458 days (0.00 posts per day).
20 Most recent posts:
Well that pretty much clears up the matter. Thx.
I'd appreciate a bit of feedback on real-time tick data issues that I've been having. I send the following string to the IQFeed client via TCP/IP, and am receiving some odd results. I'm using version 4.7.0.9.
("S,SELECT UPDATE FIELDS,Symbol,Last,Incremental Volume,Total Volume,Bid,Ask,Bid Size,Ask Size,TickID" & vbCrLf)
Maybe the cause of the problems I'm having is that I've got the order backwards above from the way the data is normally provided without the S,SELECT UPDATE FIELDS request (I haven't tried reversing it yet). The documentation pages say that requests can be made with the fields in any order, but maybe there are consequences in doing this?
Some examples of the ticks I get back via TCP/IP for some high volume symbols are given below (I've only added the local time stamp before the line that was returned)
As you can see, I seem to be getting the same tick number for all the ticks for a given symbol over a period of time (assuming the last 6-digit numbers are really tick numbers.) Is that supposed to happen? It looks like at least some of the same tick data is just being repeated several times, but I don't think that is the case. Also, the total volume does not seem to be updating with the tick volume. Is it supposed to? I'm rewriting some parts of my code, so there are probably issues due to that. I don't believe I was ever getting results like this before though.
Thanks, David.
16/11/2010 7:44:52 AM Q,DOW,30.5600,1966915,200,30.5600,30.5700,1800,600,530101, 16/11/2010 7:44:52 AM Q,DOW,30.5600,1966915,200,30.5600,30.5700,1900,600,530101, 16/11/2010 7:44:52 AM Q,DOW,30.5600,1966915,200,30.5600,30.5700,1900,500,530101, 16/11/2010 7:44:52 AM Q,DOW,30.5600,1966915,200,30.5600,30.5700,2000,500,530101, 16/11/2010 7:44:52 AM Q,DOW,30.5600,1966915,200,30.5600,30.5700,2100,500,530101, 16/11/2010 7:44:52 AM Q,DOW,30.5600,1967115,200,30.5600,30.5700,2100,500,530101, 16/11/2010 7:44:53 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,2100,500,530101, 16/11/2010 7:44:55 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,2100,600,530101, 16/11/2010 7:44:55 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,2000,600,530101, 16/11/2010 7:44:55 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,1900,600,530101, 16/11/2010 7:44:55 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,1800,600,530101, 16/11/2010 7:44:57 AM Q,DOW,30.5600,1967215,100,30.5600,30.5700,1600,600,530101,
16/11/2010 7:43:58 AM Q,BP,41.8400,2784184,100,41.8400,41.8500,2400,1900,396551, 16/11/2010 7:43:58 AM Q,BP,41.8400,2784184,100,41.8400,41.8500,2400,2000,396551, 16/11/2010 7:43:58 AM Q,BP,41.8400,2784184,100,41.8400,41.8500,2300,2000,396551, 16/11/2010 7:43:58 AM Q,BP,41.8400,2784184,100,41.8400,41.8500,2200,2000,396551, 16/11/2010 7:43:58 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,2000,396551, 16/11/2010 7:43:59 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1800,396551, 16/11/2010 7:43:59 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1900,396551, 16/11/2010 7:43:59 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,2000,396551, 16/11/2010 7:43:59 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1900,396551, 16/11/2010 7:44:00 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1800,396551, 16/11/2010 7:44:00 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1900,396551, 16/11/2010 7:44:01 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,2000,396551, 16/11/2010 7:44:02 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1900,396551, 16/11/2010 7:44:02 AM Q,BP,41.8400,2784284,100,41.8400,41.8500,2200,1800,396551, 16/11/2010 7:44:02 AM Q,BP,41.8500,2784384,100,41.8400,41.8500,2200,1800,396551, 16/11/2010 7:44:02 AM Q,BP,41.8500,2784384,100,41.8400,41.8500,2200,1700,396551, 16/11/2010 7:44:02 AM Q,BP,41.8500,2784384,100,41.8400,41.8500,2300,1700,396551,
16/11/2010 7:48:12 AM Q,AAPL,303.1400,5947011,100,303.1000,303.2000,300,300,351756, 16/11/2010 7:48:12 AM Q,AAPL,303.1700,5947111,100,303.1000,303.2000,300,300,351756, 16/11/2010 7:48:12 AM Q,AAPL,303.1800,5947211,100,303.1000,303.2000,300,300,351756, 16/11/2010 7:48:27 AM Q,AAPL,303.1800,5947211,100,303.1200,303.2000,100,300,351756, 16/11/2010 7:48:28 AM Q,AAPL,303.1800,5947211,100,303.1200,303.2000,100,200,351756, 16/11/2010 7:48:29 AM Q,AAPL,303.1800,5947211,100,303.1200,303.2000,100,200,351756, 16/11/2010 7:48:29 AM Q,AAPL,303.1800,5947211,100,303.1200,303.2000,100,300,351756, 16/11/2010 7:48:29 AM Q,AAPL,303.1800,5947211,100,303.1000,303.2000,300,300,351756, 16/11/2010 7:48:29 AM Q,AAPL,303.1996,5947511,300,303.1000,303.2000,300,300,351756, 16/11/2010 7:48:35 AM Q,AAPL,303.1996,5947511,300,303.1000,303.1500,300,100,351756, 16/11/2010 7:49:04 AM Q,AAPL,303.1996,5947511,300,303.1000,303.1500,200,100,351756, 16/11/2010 7:49:05 AM Q,AAPL,303.1996,5947511,300,303.1400,303.1500,100,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.1996,5947511,300,303.1400,303.1900,100,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.1996,5947511,300,303.1500,303.1900,100,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.1996,5947511,300,303.1800,303.1900,2400,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.1996,5947511,300,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.1500,5947611,100,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2000,5947811,200,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2000,5947911,100,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2000,5948411,500,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2000,5948511,100,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2100,5948611,100,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2100,5948711,100,303.1800,303.1900,2500,100,351756, 16/11/2010 7:49:37 AM Q,AAPL,303.2100,5948711,100,303.1800,303.1900,3700,100,351756, 16/11/2010 7:49:38 AM Q,AAPL,303.2100,5948711,100,303.1800,303.2100,3700,300,351756, 16/11/2010 7:49:38 AM Q,AAPL,303.2100,5948711,100,303.1800,303.2100,3900,300,351756,
Hi,
When I make this request: "HTT,SY1017S70,20100623 000001,20100623 235959,0,093000,160000,1,SY1017S70,5000 "
I get this error message: "SY1017S70,E,Invalid symbol.,"
Thats odd. It is a proper symbol name, and is listed in the mktsymbols_v2.zip file as follows: SY1017S70 SY JUL 2010 P 70.000 OPRA OPRA IEOPTION
Also, I note that HTT sometimes returns "E,!NO_DATA!" for valid symbols when there were no ticks for the day requested (for example, same as above using symbol GILD1017S38). Why return an error message in this case?
Thanks, David.
I have the same question. I'd like to get the fundamentals message for a large number of stocks, which I would do after trading hours. Currently I use HDX for this. I assume watch/unwatch for this purpose would be frowned upon? Thx., DG.
FYI: I didn't get the example working as the conversion wizard flubbed it up, and I didn't feel like manually fixing it. I did, however, try the blocking socket read method, and that - together with fixing a couple other bugs - got me up to just under 100,000 ticks/s (which I can live with). Thanks for the help.
Hi Steve, Please send me your VB example and I'll give that a try. Many thanks, David.
I think this may be more of a socket programming issue than an IQFeed issue, but I don't seem to be receiving tick data via HTT data at reasonable speeds.
Programming is in VS2008-VB.NET using the native socket support. In short, I use the VS2008 TCPClient class to connect to IQFeed, and assign it to a NetworkStream via .GetStream(). Two threads connect to IQFeed simultaneously, but one thread is always idle when the other is receiving data.
Upon sending the HTT request, I basically just poll the NetworkStream until .DataAvailable = true, and then grab the data using .Read when available and process it - all in a dedicated thread. The thread is idle about 97% of the time (i.e. .DataAvailable = true about 3% of the time) so it is not a processor speed issue. This is running on a new quad-core processor machine.
Also, I have an "okay" DSL connection that typically clocks just slightly under 3 Mbps receive speed.
By this method, right now I`m getting about 500-600 ticks per second. I don`t know how many bits are transmitted to get one tick, but I would think it has to be less that 300, even considering any other fruit salad that gets sent along. So, that works out to less than 0.2 Mbps.
Any suggestions as to how I might go about speeding this up? I'm wondering if I should use .BeginRead (which I believe is asynchronous) instead of .Read.
Thanks, David.
I note that there are data fields for Bid Size and Ask Size that are returned by HTT, but that these are always zero...
[Req. ID],[Time Stamp],[Last],[Last Size],[Total Volume],[Bid],[Ask],[TickID],[Bid Size],[Ask Size], [Basis For Last]
Can the actual Bid Size and Ask Size be provided rather than zeros?
Thanks,
David.
|
|