Support Board
Date/Time: Thu, 08 Jan 2026 01:50:13 +0000
Post From: OS Timers vs SC Timers discussion again... SC Timers chart update limitations
| [2026-01-05 11:42:58] |
| User677437 - Posts: 95 |
|
Global Crosshair Cursor and OS Timer -ON- Recommendation In this thread I posted a 8 minute video going over similar things. OS timer ON - gives smooth chart scrolling and global cursor crosshair - However all price updates freeze on chart and DOM with cursor movement, and price and order depth instantly gets filled when cusor movement stops. CAVEAT ---- In the same installation, in a different instance with just 1 chart and 1 DOM - There was NO price freezing with OS TIMER ON. It appears that the price freezing happens in built out chartbooks ONLY.. This freezing has never happened before the timers. If the chartbook was not optimized, DOM would just run slow, and that would be noticeable comparing across instances. When OS timer is OFF - you get a .5 second to 1 second glitch in chart / cursor movement every 5 seconds with continuous cursor movement and price does NOT freeze. My conclusion was that it was better to have OS TIMER OFF so that DOM, footprint, or 1 second chart does not freeze with cursor movement. I don't know what the breaking point is between 1 chart and 1 dom, and a chartbook with like over 75 charts in it, and half of them detached and alot of multi timeframe, and charts optimized to 5second, 1 second update intervals. The global cursor crosshair / chart values tool is obviously being calculated across all those charts, at Millisecond drawing speed. Something has to have changed. There has to be something in the OS Timer Feature that allows that type of synchronous drawing, that the SC timers don't have. And yet because of that operation it bottlenecks the actual updating of Sierra - in a built out chartbook, not in a barebones instance. This is not a datafeed problem. This is a OS, CPU, Software problem. My best analogy is that maybe you guys turned something that was only ever meant to be 'single channel' - Microsoft OS Timer - and you try to turn it 'dual channel' but the dual channel is mainly for server timing latency, and not application - user level latency. If you guys designed the timers to work on windows 7, and everyone is mostly on windows 11 - That's a you problem and not an US problem. Maybe there needs to be a user local timer, in addition to the server timer and the server timer has the limits that yall want for processes that are shared over the server, but the user timer can handle no limits because the application latency of showing global cursor crosshair - that simply is not being transmitted to the server. Maybe it needs to have something like a 1. User level latency timer for non server operations - 2. Server level latency timer for all transmitted operations. and then Finally 3! - All timer events unified together. Like a Tri-modal thing if that's a word for it. It's just clear as day that when the OS timer is turned ON, chart values tool / global crosshair with rapid cursor movement- price freezes until movement stops - it literally is bottlenecking the updating of the program. All data and order depth gets filled in 100% correct when cursor stops. Date Time Of Last Edit: 2026-01-05 12:27:05
|