My IQ Feed streaming doesn't seem to be working in quotes tool or charts. The feed is working fine (tested it using other apps).
I'm using the latest version of everything.
I'm using the latest version of everything.
Rename
Not enough information.
What does the Log Viewer say?
What does the Log Viewer say?
The log viewer says IQFeed connected. When I turn on streaming on a chart or quote tool the green light comes on as if the streaming is working but no updates are coming through.
The data updates through data manager work fine. It's only the streaming affected.
The data updates through data manager work fine. It's only the streaming affected.
Here is an example. If I pull up a security with data source IQFeed the history populates correctly but no streaming data comes through and no updates from the moment I select the security. There is nothing in the log viewer indicating anything is wrong.
side by side with td streaming
So the problem is premarket. Deselect the IQFeed option for RSO.
See how this works in the Help (F1) > IQFeed.
After changing the RSO setting, you should restart WealthLab to reconnect the client with the new setting.
See how this works in the Help (F1) > IQFeed.
After changing the RSO setting, you should restart WealthLab to reconnect the client with the new setting.
Thanks for the help. The problem was I had an older version of the IQ Feed client. Once I updated it, everything works fine now. Thanks again.
Thanks, I didn't think of it.
The minimum client compatible with the WL8 IQFeed Provider is the 6.1 IQFeed client.
Install IQFeed 6.1 or later.
The minimum client compatible with the WL8 IQFeed Provider is the 6.1 IQFeed client.
Install IQFeed 6.1 or later.
It was actually the 6.1 that didn't work. 6.2 worked fine.
I can't get IQFeed (or any other provider) to stream on the Quotes window. IQFeed streams fine on the Chart. I'm running WL Build 104.
This is the first time I tried to stream on the Quotes window for WL8, so I'm probably overlooking something.
This is the first time I tried to stream on the Quotes window for WL8, so I'm probably overlooking something.
File > Offline Mode?
Did anyone figure out why the live quotes doesn't work with IQFeed 6.2 and WL8 IQFeed ver 27?
I wasn't even aware of a report of a problem with ver 27.
There certainly wasn't anything changed that could have caused that problem, except the build process itself.
.. but we're looking into it now.
There certainly wasn't anything changed that could have caused that problem, except the build process itself.
.. but we're looking into it now.
This is the first I'm hearing of any issue, so far cannot replicate!
Until we get this sorted out, we provided a link on the IQFeed page to drop back to Build 26.
We're not having any trouble with IQFeed builds 26 or 27 on our Windows machines, but we do see the problem with IQFeed streaming with both 26 and 27 on a remote server. We'll investigate, but it might help to know the environments you're running on - please post it here.
fwiw, I'm using IQFeed 6.2.0.25 on the machine that works. It shouldn't matter though as our IQFeed provider is compatible with 6.1 and higher.
fwiw, I'm using IQFeed 6.2.0.25 on the machine that works. It shouldn't matter though as our IQFeed provider is compatible with 6.1 and higher.
QUOTE:
File > Offline Mode?
I tried toggling Offline Mode on and off. That didn't help. I'm running IQFeed Build 27 under Windows 10 Pro. I have a workstation.
But my problem may be unrelated to IQFeed because I can't get streaming on the Quotes window to work with any provider, not just IQFeed. Again, streaming works fine with IQFeed on the Chart.
QUOTE:
... so far cannot replicate!
Try replicating it with the Dummy Broker with IQFeed streaming. Oh wait, I discovered something. The Broker pull-down menu is frozen, so this is a WPF problem when the Dummy Broker is the only installed choice. Interesting.
Not frozen, it's disabled.
We don't allow you to change the broker while Streaming is enabled.
We don't allow you to change the broker while Streaming is enabled.
QUOTE:
We don't allow you to change the broker while Streaming is enabled.
Confirmed. I didn't know that.
I have more news. If I add AAPL with the Add Symbol(s) box, streaming fires up for a split second, then it freezes again. See screenshot below. It looks to me like this is a WPF problem with the Quotes window.
I only have the Dummy Broker installed in WL8. Do you think that's an issue? I don't think it has anything to do with IQFeed because the Quotes window doesn't stream with the other streaming providers either.
QUOTE:Thank you. Good clue. That's consistent with our remote server too.
doesn't stream with the other streaming providers either.
QUOTE:
That's consistent with our remote server too.
Thanks for that update. So you're saying this has something to do with Local Group policy on the Pro (my version) and Server versions of Windows?
Have you been able to reproduce it with other Windows 10 Pro versions with similar Local Group policy? Which Group policy settings are we talking about? This might be a Microsoft support question.
Let me add that the WL6 Quotes window streams just fine, but that uses Windows.Forms, not WPF, so its Local Group policy affects will be different.
It does not stream here on Win 11 or my remote Win 2022 Server neither.
The only way to see the current (frozen) price is to add a new symbol (type it into the input field and press enter).
The only way to see the current (frozen) price is to add a new symbol (type it into the input field and press enter).
This is my Win 2022 machine. Prices are frozen independent of the selected streaming provider (tried IQFeed and IBKR):
Works perfectly fine in the chart window.
Works perfectly fine in the chart window.
QUOTE:
The only way to see the current (frozen) price is to add a new symbol (type it into the input field
Yes, that's what I was talking about in Post #18.
So you see this problem on Windows 11 as well. I wonder if that's the Pro or Home version?
I wonder if a Windows Update security patch may have started it? What version of WL did it start happening?
Windows 11 Pro.
I don't remember it ever working for me, however I started using WL only with build 100 ;-) - I did try it in build 100 or 101 but just shrugged my shoulders and moved on to other features as I was not focused on the Quotes window.
I don't remember it ever working for me, however I started using WL only with build 100 ;-) - I did try it in build 100 or 101 but just shrugged my shoulders and moved on to other features as I was not focused on the Quotes window.
Are these virtual machines, VPNs, or actual hardware? We're trying to pin something down here, so far have not been able to ascertain exactly what situation is causing this, like I said it's good on all of our hardware but failing on one older Windows server we access over RDP.
My Win 11 Pro machine is bare-metal (no virtualization) - modern machine with Z790 chipset. The Windows 2022 Server is a Hetzner Cloud virtual machine.
Happy to jump on Zoom or let you play around with it in case it would help.
Happy to jump on Zoom or let you play around with it in case it would help.
I'm using Alienware M16 with windows 11.
QUOTE:
... or actual hardware?
I'm on a real workstation (older GIGI Byte motherboard) running Windows 10 Pro.
I don't think it's the hardware, but rather the Local Group Policy of the OS. The "Pro" versions (and server) have a somewhat different Group Policy than the "Home" versions. I would call Microsoft support and ask how you can compare the Group Policy configuration of one machine against the other.
What you really need to do is break one of your machines by installing my Group Policy into it. But I don't know how you do that.
The problem is Windows Update manipulates Group Policy to adjust security settings and that creates different Group Policy settings across machines.
Is the WL installer messing with Group Policy at all?
Did you ever create a command line switch(es) to not load some of the extensions? If so, we could try that switch to see if it fixes the problem.
If you did a remote debugging session on my machine, would that tell you something?
One of my 4 machines still has the soon-to-be-end-of-life Win 10 Pro on it.
Default Group Policies (i.e. Not configured)
Everything works fine.
Default Group Policies (i.e. Not configured)
Everything works fine.
Streaming Last Price Updates doesn't work in Accounts either.
QUOTE:
... my ... machine still has ... Win 10 Pro on it.
Default Group Policies ... Everything works fine.
My Win 10 Pro has default Group Policies and Quotes window streaming doesn't work.
So the conclusion is it isn't Group Policy. But it is OS and installation dependent somehow. It sounds like you'll need to do a remote debugging session on one of our machines to find the source of the problem.
QUOTE:
Streaming Last Price Updates doesn't work in Accounts either.
Streaming Accounts window updates are spotty. It's like the Quotes window. If you force a change, it updates for a split second, then freezes again. Something isn't right. But the Accounts window works a little better than the Quotes window, which is totally frozen.
UPDATE: Let me add, both Fidelity Active Trader Pro and ATP Beta work just fine as far as WPF real-time streaming updates on my machine, so the problem is somewhere in the WPF streaming updates of WL8 itself that's the problem. And it's not dependent on the WL streaming provider. At least we have it narrowed down to that.
It suddenly occurred to me what might be causing the Quotes window streaming/updating problem on some systems and not others. It a threads scheduling problem. The thread(s) that communicate between the streaming provider and the WPF system need more thread execution priority.
And those systems with "extra" parallel-core execution time won't see a thread priority problem. But older systems, or systems with many background tasks going, will struggle if the thread priority for real-time streams isn't set just right.
This also explains why the Quotes window briefly unfreezes when a change is published to it. The thread that needs execution time briefly gets it. So what you have is thread execution starvation or live lock.
Good luck debugging the thread execution priority problem. But at least you know it's the threads that move the data from the streaming provider to the WPF dispatcher that have the priority problem, so you know where to look. But you really need an overloaded system (say an old, slow, over burdened computer) to tune the thread priorities up. The Visual Studio execution profiler may help if you can find an old, overburdened computer (say with 4 or less processor cores) to model the problem on.
And those systems with "extra" parallel-core execution time won't see a thread priority problem. But older systems, or systems with many background tasks going, will struggle if the thread priority for real-time streams isn't set just right.
This also explains why the Quotes window briefly unfreezes when a change is published to it. The thread that needs execution time briefly gets it. So what you have is thread execution starvation or live lock.
Good luck debugging the thread execution priority problem. But at least you know it's the threads that move the data from the streaming provider to the WPF dispatcher that have the priority problem, so you know where to look. But you really need an overloaded system (say an old, slow, over burdened computer) to tune the thread priorities up. The Visual Studio execution profiler may help if you can find an old, overburdened computer (say with 4 or less processor cores) to model the problem on.
Who knows? But I'd point you to Post #26.
We're working on it. Fortunately one of our servers exhibits the problem.
We're working on it. Fortunately one of our servers exhibits the problem.
QUOTE:
Fortunately one of our servers exhibits the problem.
That would be your best bet for tuning the thread priorities correctly. It would be pointless to try to tune them on a system that isn't exhibiting the problem.
Another option would be to take a Windows 11 machine and disable some of the processor cores until you see the thread scheduling problem. But I don't like this "contrived" approach as much. The modern system is missing the hardware and buffering choke points the older system has, and you need those choke points for proper tuning.
Normally a Windows application wouldn't have a thread scheduling problem. But WL is performing streaming with real-time updates to its windows (like Quotes) that requires real-time execution (like sorting) on the application side. So that sorting activity requires more thread priority. It's a weird real-time requirement for a Windows app.
The problem is the IQFeed client, and we weren't catching the protocol error message. Our server was running the 6.1 client, which is the protocol we use for everything except quotes. For quotes our IQFeed Provider specifies 6.2.
Anyone having trouble with IQFeed streaming should download and install the 6.2.0.25 client from IQFeed's website:
https://iqfeed.net/index.cfm?displayaction=support§ion=download
Anyone having trouble with IQFeed streaming should download and install the 6.2.0.25 client from IQFeed's website:
https://iqfeed.net/index.cfm?displayaction=support§ion=download
Incidentally, our IQFeed page specifies that the IQFeed 6.2 client (minimum) is required - since 2/10/2023, Build 11.
QUOTE:
The problem is the IQFeed client,... For quotes our IQFeed Provider specifies 6.2.
Anyone having trouble with IQFeed streaming should download and install the 6.2.0.25 client from IQFeed
As my screenshot shows in Post #9, I'm running the 6.2.0.25 IQFeed client and I still have the problem with the Quotes window freezing.
Sounds like you don't have a machine to reproduce the problem. If you want to perform a remote debugging session on my machine, let me know.
I have the issue using client 6.2.1.20 - however, it's not limited to IQFeed, Interactive Brokers also does not stream and numbers remain frozen.
Sounds like a difficult issue to debug..
Sounds like a difficult issue to debug..
Try again with Build 106 when released. We backed out a Quotes window optimization from a few builds ago that is probably the culprit.
Build 106 is ready. Let us know the verdict.
@superticker, @mattsea
All good with Build 106?
The IQFeed build doesn't matter, but it would be good for some customers to put some hours in with Build 28.
All good with Build 106?
The IQFeed build doesn't matter, but it would be good for some customers to put some hours in with Build 28.
Quotes are streaming again with build 106. Just loaded it last night.
Thanks.
Thanks.
The Quotes window is streaming as expected for IQFeed. I'm running WL Build 106 and IQFeed 28.
However, for Yahoo streaming, it seems to stream, but the Size column is all zeros. Is that expected? See screenshot.
Morningstar streaming for the Quotes window doesn't seem to work at all. So Morningstar streaming has a problem. I think it's streaming is very restricted.
However, for Yahoo streaming, it seems to stream, but the Size column is all zeros. Is that expected? See screenshot.
Morningstar streaming for the Quotes window doesn't seem to work at all. So Morningstar streaming has a problem. I think it's streaming is very restricted.
idk about Y!, but Size isn't really useful in the Quotes tool. Anything that makes it there should be a full lot trade (100 shrs min), which are the only trades that contribute to charting, by industry standard.
It looks like Yahoo! streaming volume needs some work. Even if it were working correctly/accurately, the "size" would be a conflated volume calculation over a period of several seconds. So it's not really a trade size at all, like it would be for IQFeed - which is also somewhat meaningless in the Quotes tool since all "ticks" could not possibly be displayed sequentially.
Just to confirm from my side as well - streaming in the Quotes window works again. Thank you for the fix!
Thanks for the reports. We can finally put this one to bed.
(Yahoo! volume will be better in Build 107 too.)
(Yahoo! volume will be better in Build 107 too.)
Streaming appears to work for most of the Quotes window, but the Trigger% column appears to freeze up sometimes as shown in the screenshot below. What's weird is that Trigger% column initially followed the streaming prices, but then it locked up latter in the trading day. (It still looks like a real-time thread execution priority problem to me.)
The last row of the Quotes window continued to follow streaming price changes as expected. I'm streaming with IQFeed, but I don't think the provider has anything to do with it. I'm running Windows 10 Pro and WL Build 106.
The last row of the Quotes window continued to follow streaming price changes as expected. I'm streaming with IQFeed, but I don't think the provider has anything to do with it. I'm running Windows 10 Pro and WL Build 106.
It looks to me like the scenario hit some logic that locked it at 100%. I don't remember what all those scenarios are, but if you create price triggers in the middle of the day, the reference price may not be yesterday's close and that changes the logic. Anyway, once the order is triggered, the job is done.
QUOTE:
It looks to me like the scenario hit some logic that locked it at 100%.
You "might" be right about the locking at 100%. I would need more cases to verify that.
However, all three cases (rows) were started before the market opened. Why the third (last) case behaves differently than the other two confuses me. My thinking is that there's some kind of race condition involved, but I'm only guessing.
The race condition theory might explain why some users see the problem and other do not. Perhaps those with more processor cores are less likely to encounter the race condition than those with less cores.
All the prices do appear to stream okay with IQFeed.
You can look for the most complex explanation you can find, but Trigger % is a calculation and usually it's related to the previous close, but sometimes it's not and we set it at 100% intentionally.
Maybe we're both right, but I'm failing to see it as any kind of an issue. Did the Trigger occur when it should have? If so, we're done.
Maybe we're both right, but I'm failing to see it as any kind of an issue. Did the Trigger occur when it should have? If so, we're done.
QUOTE:
Did the Trigger occur when it should have?
Yes, all three quotes triggered as expected. But two got stuck at 100% as their price went down and the third one didn't.
WL6 works correctly. The triggering follows the slippage down. That's important because I formulate (and re-formulate) a watch list from this triggering behavior. And I want stocks with slippage to fall off of this watch list throughout the day. So the trigger% should remain dynamic, and it does with WL6. When I Auto-Sort the triggers on WL6, I get my dynamic watch list--which is highly desirable.
If you can think of another way for me to formulate (and re-formulate) my watch list, please suggest it. Is there a way to bring in the Quotes window data and process it with C# over the trading day?
---
I haven't seen any stuck triggers at 100% today. Perhaps we should wait until a can report more examples of when it sticks and when it doesn't. But it would be nice if it worked like WL6 where the trigger column follows the streaming price. Do I need to make that a feature request?
Trigger% follows the price in almost all cases.
I looked at the code, and the case when it doesn't (and returns 100%) is when the Reference Price is calculated to be almost equal to the Transaction price. This indicates (to me) that you initialized those price triggers midday, and, as I've mentioned at least once the reference price may calculated (and recalculated) to make the Trigger % act in a reasonable manner.
If you make your own Quotes window, you can do anything you want with it. Since you don't need all the same features, it should be a relatively simple project, and you can give yourself whatever access you need.
I looked at the code, and the case when it doesn't (and returns 100%) is when the Reference Price is calculated to be almost equal to the Transaction price. This indicates (to me) that you initialized those price triggers midday, and, as I've mentioned at least once the reference price may calculated (and recalculated) to make the Trigger % act in a reasonable manner.
If you make your own Quotes window, you can do anything you want with it. Since you don't need all the same features, it should be a relatively simple project, and you can give yourself whatever access you need.
QUOTE:
Trigger% follows the price in almost all cases.
And why would anyone want some kind of rare exception? I've never seen any exceptions in WL6, and I'm been using it a long time.
I typically setup up the Quotes window before the market opens. After the market opens, I'm too busy evaluating trades to mess with the Quotes window.
Let me continue to evaluate the issue. Perhaps the rare exception is very rare and won't interfere with my workflow. But thank you for looking at it.
It might be nice to create some kind of running watch-list Quotes window, but you kind of have that now with Auto-Sort enabled if the trigger% follows the streaming price. I suppose that's a new topic and feature request.
The discussion has derailed and is off-topic. Start a new one if you feel the need.
---
A little more investigation... here's more explanation of what happened:
Those BuyAtStop orders were "below" the previous Close. We're using double precision, so even though the order was intended to be "at" the previous Close, it was found to be below it, and, it triggered immediately because the Price opened above the Stop. That's one of the "where-are-we-supposed-to-set-a-reference price" scenarios and thus where you'll get the 100% trigger lock.
I'm also recalling that the main reason we're dealing with such high precision was the implementation of crypto broker providers where prices are often 6 or more decimal digits, i.e., we have to display percentages that make sense when going from, say, 0.0000567 to 0.000060.
It wasn't easy making this work as well as it does!
---
A little more investigation... here's more explanation of what happened:
Those BuyAtStop orders were "below" the previous Close. We're using double precision, so even though the order was intended to be "at" the previous Close, it was found to be below it, and, it triggered immediately because the Price opened above the Stop. That's one of the "where-are-we-supposed-to-set-a-reference price" scenarios and thus where you'll get the 100% trigger lock.
I'm also recalling that the main reason we're dealing with such high precision was the implementation of crypto broker providers where prices are often 6 or more decimal digits, i.e., we have to display percentages that make sense when going from, say, 0.0000567 to 0.000060.
It wasn't easy making this work as well as it does!
Your Response
Post
Edit Post
Login is required