|
PureBytes Links
Trading Reference Links
|
Carroll Slemaker wrote:
> The only assertion I would disagree with is that this
> 100% CPU utilization by the Server is a recent problem
> - it isn't. I noticed this when I first switched to
> Windows NT, maybe two years or so ago, and complained
> to Omega at that time.
It isn't a new "problem."
> It obviously relates to the form of IPC (inter-process
> communication) being used between the 16-bit Server and
> the charting module.
It has nothing to due with communication between the server and the charting
program or that 16-bit software is being used.
> It might be inherent in DDE (Dynamic Data Exchange,
It isn't inherent in DDE.
> an obsolete protocol which Omega is using), or it may be
> just in how they've implemented their DDE interface.
DDE is not obsolete. Only the DDE designation is obsolete. Microsoft has
encapsulated DDE in a shell of additional code to make it easier to use and
called it OLE. OLE uses DDE to communicate between applications. When you
use OLE in the latest Windows application programs, you are using DDE.
There is nothing wrong with DDE. In fact, pure DDE is considerably more
efficient than OLE, because it avoids layers of additional processing.
Omega uses a non-standard DDE method, but that has nothing to do with the
CPU workload issue.
> I have been told that the 32-bit Server will not have
> this problem.
That may be true, but it will have nothing to do with the fact that 32-bit
code will be used, with the following exception. Windows NT prevents
individual 32-bit application programs from "hogging" the CPU like the
current 16-bit Omega Server does. Therefore, a 32-bit version of the Omega
Server would not be allowed to use the CPU almost constantly under Windows
NT, even if Omega made no design change. However, that would not be true
running under Windows 95.
The 100% processor workload "problem" results from using incoming serial
data polling, rather than a method based on interrupts from a serial data
input buffer. Both methods have advantages and disadvantages. Polling
results in less average latency (incoming price quotes are received more
quickly, on average), but a high CPU workload. The interrupt method
significantly reduces the CPU workload, but results in greater average data
latency, because incoming data isn't processed until several bytes have been
received.
This is another case where Omega designers may be persuaded by user
complaints to make a design change that may not be best overall. Design is
primary a process of compromise. Tradeoffs are associated with almost every
choice. It is important to know what they are before demanding changes.
Changing to an interrupt method will improve the performance of other
software running on the same computer. That may be very important to some
users. However, incoming trading data will be processed with greater
average latency. That also will be important to users. Designers should
not be pressed into making design decisions by people who do not understand
all the issues.
Contrary to concerns expressed on this list in the past, a high CPU workload
does not harm a CPU. Computer CPU's are processing constantly whenever
computers are running. If they are not processing program code, they are
processing code in an idle loop. CPU workload percentage displays are based
on the ratio of time spent processing program code versus idle-loop code.
CPU's are always processing. The only issue is which code?
If you were designing trading software, would you give high priority to
processing incomming price quotes a quickly as possible or would you give
high priority to making other software on the same computer run as fast as
possible, even if incoming data processing must wait?
-Bob Brickey
Scientific Approaches
sci@xxxxxxxxxx
|