|
|
Home
Search
Register
Login
Recent Posts
| Viewing User Profile for: Neil Brennan | |||||||||||||||||||||||
| About | Contact | ||||||||||||||||||||||
|
|
||||||||||||||||||||||
| Post Statistics | |||||||||||||||||||||||
|
Neil Brennan has contributed to 38 posts out of 21251 total posts
(0.18%) in 6,592 days (0.01 posts per day).
20 Most recent posts:
IQFeed Developer Support »
Delays fom IQFeed 66.112.148.x data servers Jun 27, 2011 09:31 PM
(Total replies: 27)
Just quickly, Since we have limited our connections to the .156 farm we have had service as normal, which for us is over 99% of data delivered with a lag of less than 100ms. Today's latency graph is attached. Steve, we will work with you offline to see what we can do about upgrading our client. Thanks, Neil
IQFeed Developer Support »
Delays fom IQFeed 66.112.148.x data servers Jun 22, 2011 06:09 PM
(Total replies: 27)
Hi Steve, As you may recall, I work with Dennis. One of the things that has slowed down any attempt by us to upgrade our client is that (as far as we can see) there is no step-wise way to do it. Once you have a new version, old versions seem to be removed from your site. Is there anywhere we can get some of the older versions of the client that you think are stable and clean, so that we can upgrade in an orderly fashion? The best version for us would be one where we aren't forced to change our code, of course. :-) Thanks, Neil
IQFeed Developer Support »
Delays fom IQFeed 66.112.148.x data servers Jun 22, 2011 06:09 PM
(Total replies: 27)
Hi Steve, As you may recall, I work with Dennis. One of the things that has slowed down any attempt by us to upgrade our client is that (as far as we can see) there is no step-wise way to do it. Once you have a new version, old versions seem to be removed from your site. Is there anywhere we can get some of the older versions of the client that you think are stable and clean, so that we can upgrade in an orderly fashion? The best version for us would be one where we aren't forced to change our code, of course. :-) Thanks, Neil
IQFeed Developer Support »
Feed latency problems for Nasdaq data Nov 5, 2010 02:28 AM
(Total replies: 21)
Craig, I think it's pretty likely that it is a problem at your end. We're watching 1000 symbols. Cheers, Neil
IQFeed Developer Support »
Feed latency problems for Nasdaq data Nov 4, 2010 04:56 PM
(Total replies: 21)
Hi, We are no longer seeing the huge spikes in latency that caused us to open this thread. Normally we would see figures of between 50-100ms, although delays of a few seconds are still fairly common when the market moves swiftly. Of considerable interest was the performance of the combined DTN/our-end system (which is all we can measure) on Wednesday. In a day of fairly savage market movements, our worst latency was only around 3 seconds and was quickly recovered. When we opened this thread a delay of 15 seconds at this point would have been common. Regards, Neil Brennan
IQFeed Developer Support »
Feed latency problems for Nasdaq data Aug 11, 2010 06:41 PM
(Total replies: 21)
Hi Skunk! To be clear, although we personally reside in Aus, our servers are colo'd in New Jersey and are not subject to any kind of inter-continental lag. :-)
IQFeed Developer Support »
Feed latency problems for Nasdaq data Aug 10, 2010 06:42 PM
(Total replies: 21)
Hi, We saw a perfect example of this problem again today, when the Fed made its announcement in the afternoon. At 2:16pm EST we saw a huge spike in latency from the standard value of under 100ms (which had been the case all day) to over 19 seconds! Needless to say, being roughly 20 seconds behind the market probably isn't a great thing. Our graph of the day's latency against the DOW is attached. Regards, Neil Brennan
IQFeed Developer Support »
Feed latency problems for Nasdaq data Aug 2, 2010 07:06 PM
(Total replies: 21)
Steve, Did your investigations turn anything up? We experienced a similar delay (5 seconds, this time) on our NYSE feed at 10am market time today. Regards, Neil Brennan
IQFeed Developer Support »
Feed latency problems for Nasdaq data Jul 25, 2010 03:15 AM
(Total replies: 21)
Hi Steve, Sorry for the delay in responding - for some reason I'm not getting emails automatically forwarded for forum updates (probably my own fault). All the times are Feed time (EST); market open 9:30, market close 16:00. I think we're currently colo'd in New Jersey! On any given day it is incredibly rare for us to see a delay over 600ms. More than 95% of the time we experience latency under 90ms, with a median around 50ms (which is pretty impressive). Regards, Neil
IQFeed Developer Support »
Feed latency problems for Nasdaq data Jul 21, 2010 07:16 PM
(Total replies: 21)
Just a clarification, we are based in Australia (our machines are in the U.S.), hence my references to "last night". The day in question is Wednesday July 21.
IQFeed Developer Support »
Feed latency problems for Nasdaq data Jul 21, 2010 07:12 PM
(Total replies: 21)
Hi, I have not contributed to this forum for some time, purely because, well, things have been pretty good. This is a great value product that delivers exactly what we need nearly all of the time. That said, there are occasional issues and last night we experienced one of them. When market conditions change quickly, we sometimes find that the data we receive from DTN becomes quite delayed. Last night, in the middle of the market fall, the delay on our Nasdaq feed (66.112.156.221) hit 15 seconds. Being intra-day traders, this is quite worrying for us, and could prove to be quite expensive! To be clear, at the same time as our Nasdaq data was being delayed, we had an identically-configured machine receiving roughly twice as much Nyse data (66.112.156.228) that was not particularly impacted. We have actually found this to be very common: Nasdaq data from our DTN feeds is much more prone to being delayed than Nyse data. Neither of our machines is stressed in any way (less than 10% CPU usage), and our internet connections are more than adequate to our needs. We routinely graph DTN latency for each day. The latency graph for 66.112.156.221 for yesterday is attached. Our questions are: 1. Can these latency problems be confirmed/refuted by DTN? 2. Given that they are real, are they across all machines? 3. Why would we see this with Nasdaq data, but not the more voluminous Nyse data? Thanks,
Data and Content Support »
Continual sending of Fundamental Data Jan 9, 2008 11:24 PM
(Total replies: 3)
For those who care, this is still happening as of Tuesday this week (8 Jan) on our Nasdaq feed.
Data and Content Support »
Continual sending of Fundamental Data Dec 18, 2007 07:00 AM
(Total replies: 3)
Same again today on 66.112.156.225, but 66.112.156.112 looks fine.
Data and Content Support »
Continual sending of Fundamental Data Dec 17, 2007 07:28 AM
(Total replies: 3)
Hi, Something very strange appears to be happening on your 66.112.156.221 server this morning. For whatever reason, it seems to be continually sending and re-sending fundamental data messages. We reconnected, unfortunately getting the same server, and re-experienced the same problem. In fact, we received over 80,000 fundamental data messages between 6:35 and 8:00 a.m.! When we reconnected to 66.112.156.114 the problem was not evident. Weird. If it helps in any way, we watch the top 1300 Nasdaq codes. Neil Brennan
Data and Content Support »
Data flow outages Sep 15, 2007 11:58 PM
(Total replies: 14)
Hi Lonnie, Using my available networking tools, I can see that the connection has not been broken. We still receive timestamps, and even the occasional update. Your servers quite simply appear to just stop sending 99.9% of the available information. Your "local timeout" is completely insufficient for our purposes. As I stated in my first post, we use a 10 second timeout for our data feeds. If data from your servers falls below a reasonable threshold during market hours, we drop the connection and reconnect to another server. We are not willing to increase the value of this timeout, as we depend on a timely data feed for our trading information, and hence our livelihoods. As we do not (now) give IQFeed the opportunity to perform its own reconnection, whether or not the IQConnection Manager shows reconnections for timeout reconnects isn't information that we have available to us. It is not surprising that the information I was given was "out of date", considering it was from another user attempting to help me out. If someone from DTN had themselves responded to my earlier post, there may have been a bit less confusion. That said, I am quite puzzled by both your description of the earlier problem, and the solution you chose to implement. Surely the question should have been, "Why does IQFeed not recognise when the server connection has dropped, and how can we fix this?". Your note has at least convinced me that we need not attempt to implement sending a "T\n" to restart the connection. We are better off with our current solution. The question however still remains as to why the servers stop sending data to connected clients. And that is where we started.
Data and Content Support »
Data flow outages Sep 14, 2007 08:59 AM
(Total replies: 14)
I have received a private message from another developer who was struggling with this IQFeed bug in December 2005. The staff member he dealt with was Natalie Hannan, who suggested sending a "T\n" to restart the data feed. So, it appears that not only is this a known problem, but it is nothing like a new one. Would anyone from DTN care to comment?
Data and Content Support »
Data flow outages Sep 13, 2007 12:10 AM
(Total replies: 14)
(Oops. Our last night is your yesterday! All times are US EST.)
Data and Content Support »
Data flow outages Sep 13, 2007 12:08 AM
(Total replies: 14)
Hi, In the past, from time to time, we have encountered a situation where although the IQConnect client is still connected to the DTN servers, the servers seem to just stop sending data. This used to be a very infrequent occurrence, but in the last couple of weeks it has become more and more prevalent - last night we had this happen 4 times on 4 different servers:
After 10 seconds of no data we automatically disconnect and reconnect to a new server, so there is no way for us to know how long the outage would have lasted, but in the past we have seen these situations last for up to 10 minutes (we used to only react to server-side disconnects). Can anyone shed any light on what is happening here, please? Is this a known bug? Is this related to the memory leak problem Jay has mentioned in other posts?
Data and Content Support »
Re: Change in IQFeed date formats Sep 1, 2007 08:41 AM
(Total replies: 3)
As an IQFeed developer, I received an email today containing the following information: Quote: We will soon be standardizing all date fields within IQFeed. ... Following this change, all date fields within IQFeed will soon be sent in the format MM\DD\YYYY. As a developer in numerous countries - including your own - over the last 25 years, I find it amazing that you have chosen to ignore the excellent ISO date format in favor of this absurdly confusing option. It may have escaped your attention that no-one in the rest of the world uses this purely American format, for the very good reasons detailed in this link: http://www.w3.org/QA/Tips/iso-date A standard exists, surely you should consider using it.
Data and Content Support »
Transactions outside bid-ask spread... Aug 25, 2007 06:22 AM
(Total replies: 7)
It may be also be relevant that in "fast" markets (such as those we have encountered recently) DTN may not transmit some proportion of the messages that you would expect to see: http://forums.dtniq.com/index.cfm?page=topic&topicID=1620 |
|||||||||||||||||||||||