|
PureBytes Links
Trading Reference Links
|
This is getting interesting :)
Replies between lines below,
--- Gary Fritz <fritz@xxxxxxxx> wrote:
> > The issue is 100% cpu time usage and Windows.
> > When Windows is forced to operate in 100% CPU
> usages,
> > it will start to drop windows messages - the
> default
> > way for most programs to operate within Windows,
> > like getting mouse move, click, whether to scroll,
> > etc.
>
> Given the typical (unbelievably bad) design of
> Microsoft software,
> this wouldn't surprise me too much. Though I would
> be a bit
> surprised if it happened in NT and W2k.
Actually it is a FEATURE in NT/W2K.
e.g. at heavy load, it is not "important" to
send messages of mouse events to the applications
by ms standard :)
thus the OS can be more stable ... at the cost of
the applications running on them :)
>
> > For TSPro, its server is a cpu intensive task,
> thus
> > during heavy market hours, it will take more CPU
> > usage by design. Then to double the damage, TSPro
> > need to talk to this server, and more busy the
> > market, more talking is needed. Once cpu usage hit
> > 100%, the talking between the 2 apps will no
> longer
> > be guaranteed.
>
> I don't buy this. TS4 is a CPU-intensive task too.
> The TS4 server
> runs at 100% all the time. TS4 has the same
> architecture of charting
> talking to the server.
TS4 is not really cpu-intensive, the reason why
TS4 always have 100% cpu usage is that the
TS4 server is time polling the data feed. Thus
the OS looks very busy 90% of the time due to its
services are called to deliver data from whatever
port is needed by TS4 server to get the data.
TS4 is based on DDE 16 bit communication to the
server. old architecture - BUT, the protocol is
safe.
TS2k and other newer apps are forced to use
DDE32 (if you ignore the MS warning of not to
use it), OLE1, OLE2, ActiveX, etc. which are all
unsafe communication (the protocol can drop the
communication ANYTIME during the talk) and the
applications are expected to handle the unexpected.
This unsafe communication design is under the same
principle of dropping messages to applications -
the make the OS more stable.
>
> If 100% CPU usage caused TSPro's problems, TS4
> should suffer from it
> too. Obviously it doesn't. Neither do hundreds of
> other complex
> realtime Windows-based applications that also run
> just fine in 100%-
> CPU-usage situations.
The explanation above is enough :)
For applications that are designed and coded to
correctly take into account of communications that
will
be dropped anytime during say retrieving data, etc.
then that application will run rock solid.
>
> I'd bet -- a lot -- that the problem lies not in
> poor Windows design,
> but in poor TSPro design.
Totally agree.
-Lawrence Chan
>
> > --- "david b. stanley" <davestan@xxxxxxxxxx>
> wrote:
> > > Is it possible for
> > > stack overflow to occur thus pushing out surges
> of
> > > processed data in the wrong order?
>
> I very much doubt it would respond like that. More
> likely the data
> would be lost or corrupted. But it's impossible to
> tell without
> knowing how the code is written.
>
> Gary
>
=====
Lawrence Chan http://www.tickquest.com
Home of trading tools NeoBreadth and NeoTicker series
|