Although Windows XP is only "soft" on the realtime front, the multi-tasking or context switching can be significantly improved by the following setting in the registry. On Windows XP systems, where there is client-server interprocess communication, adjust Win32PrioritySeparation to be Hex 28, which is Decimal 40. Windows Registry Editor Version 5.00 (HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\PriorityControl) "Win32PrioritySeparation"=dword:00000028 Brackets changed to parens for this editor. This specifies the following scheduling characteristics: 1) short quanta in the scheduler 2) equal foreground and background priorities 3) fixed quanta (not variable) This significantly improves interprocess context switching. For example, I run a custom front-end socket client locally connecting to IB's TWS. I run the Java "server vm" for TWS and for my custom trading front-end code. Adjusting Win32PrioritySeparation, as described above provides me with the fastest possible context switching between the two intercommunicating processes. FS
I no longer agree in today's day and age -- I've implemented server side J2EE code that handles tens of thousands of thousands of messages per second communicating with thousands of users simultaneously. And this was on Intel servers less powerful than my new (as of June) desktop home PC.
FutureScalper Have you done any work on Vista by comparison? There are meant to be significant kernel improvements but I have not had a chance to benchmark it yet. Linux seems to do abetter job of scheduling with latencies in hundreds of microseconds readily acheivable. squeeze
Don't have Vista yet, so no idea. Linux nearly always more efficient, but then maybe the GUI layer not quite as fast as Windows since more of a separated layered architecture than on Windoze. I thought the GUI was long ago pulled into the kernel so Windows could have a faster more integrated GUI. I'm just happy Java has finally attained such a high level of performance. My Java code runs nearly 100 threads per OS process, and the most time-consuming part of the code is the Swing GUI which is now acceptably fast, although I'd always like MORE ! FS
Vista uses CPU cycle counting to try to more evenly distribute resources. However, scheduling still uses the 10-15ms interupt so if the CPU is busy then that pretty much defines the wait to get some CPU resource. A hundred threads is a lot. Does this really offer any advantage over half a dozen given the overhead of context switching between them all? Unless there are hardware resources to execute multiple threads in parallel then whats the benefit of having huge numbers of threads?
Well, these OS's are "soft realtime" anyway. Of course not all of those Java threads are screaming at the same time. So you don't have constant contention among all of those threads, not at all. But these are all separate activities which trigger when needed, and most of them do show up as process-level OS threads. In such a design, nothing "loops" on the cpu, that's for sure; all threads "wait" and are notified when necessary or when a certain amount of time passes; otherwise they are dormant. Some are watchdogs, stats calculators, displays periodically updating themselves. There's plenty of "producer/consumer" type arrangements where input data is buffered, timestamped and then another thead processes the data, etc. It's "soft realtime" trading, where orders can be placed, or bumped in price live, in around 100 msec so any lags or delays are a problem. Threads have to be prioritized correctly, etc. For those who program in Java, and for whom threads are "natural", it's the way to build a system with concurrent activities. In other computer languages where threads are "hard to use", of course, it seems "strange". The only thing you really do have to worry about is thread synchronization and the nightmare scenario of "deadlock". But by following simple rules, it's a piece of cake in Java.
Dead-lock is quite rare and easily avoided by design. I have only ever had problems with it once with a GUI call. I have never really used more than a few threads, typically one for data, one for returning execution messages and others created for history fetches and analytics as needed. I also create threads for basket sweeps and the algos running on each name tend to have a timer running on a seperate thread. Once, a large basket is fired off there can be hundreds of threads running at the same time.
Well, it's all about good design while, at the same time thinking about the load on the system. For example, I have hundreds of analyzer objects, each of which absorbs data, but when data expires, each analyzer will need to "trim" the old data. So I have design choices: 1) trimming or "aging" of data can occur each time the analyzer is accessed, but what if it keeps receiving data but is not "read" to trigger the trimming? 2) each analyzer can keep a "trimmer thread" which occasionally performs housekeeping, or 3) each analyzer can register with a master "singleton" trimmer signal, and periodically receive requests to perform housekeeping. Well, I settled on a "singleton" notifier, with which each analyzer registers. So rather than having hundreds of threads whose job was simply to perform housekeeping, I have only a single notifier which operates on many hundreds of analyzer objects. So, it's important to think about the design implications on the implementation. Each live order is managed by a separate thread on my system, as well. Because the number of simultaneously active live orders probably won't exceed a dozen or so at any given time, that's OK for design. It all comes with experience, and using good judgment, and usually after reworking a bad design !!
I've been running Windows Server 2008 in workstation cladding for a couple of weeks and discovered a new level of responsiveness from TWS and other apps. What WS does is leave a lot more in memory than XP or Vista -- When closed TWS's javaw.exe uses 180M of memory instead of 40 or 50M with the other OS's. WS uses 1.2G of memory when running instead of under 0.8 for XP. As a result, TWS doesn't get those occasional lags to restore tws from minimized that you see with the xp/vista. So in this case, using more memory is a good thing. So I tried to figure out if I could improve XP and my current change is System Properties/Advanced/Performance/Advanced/ Memory Usage = System Cache. What this does is tell windows to load more into memory and keep it there. That way it doesn't get swapped into the page file where loading it back can be slow. MS have a warning about it but I think it really applies to older ram strapped environments and older graphics cards and drivers. http://support.microsoft.com/kb/895932 Any thoughts?
kiwi, would you care to provide an update on your Windows XP "System Cache" performance-enhancing experiment? Thanks.