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.

Hi,

I don't use VS2008-VB.NET, but it's always a bad idea to poll for a socket. As you are already using threads, block on the socket instead. If you can't block (because you need to process other events) use select with a timeout. I suspect what is happening is that your poll is either too long or that you aren't reading all the data on the socket when .DataAvailable=true. You should be getting significantly faster than 500 ticks a second.

Regards,

red.

As redblue said, you should certainly be getting much faster than 500 ticks per second.

But I am hesitant to say that the socket polling is the sole responsibility of the decreased performance that you are seeing. For example, I modified the vb example app (which also uses socket polling) to output statistics for datapoints per second for each request and was able to get significantly higher results.

I am wondering if you get similar results using the example app as you do using your own app? Let me know if you want me to email the changes I made to the vb example app to track this down.

Hi Steve,
Please send me your VB example and I'll give that a try.
Many thanks,
David.

Sent

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.