How "real time" is FreeBSD?

[backyard]

--- Jerry McAllister <jerrymc at msu.edu> wrote:

> On Thu, Sep 21, 2006 at 08:21:10AM -0700, backyard
> wrote:
> 
> > --- RW <list-freebsd-2004 at morbius.sent.com> wrote:
> > 
> > > On Thursday 21 September 2006 06:12, Walt Pawley
> > > wrote:
> > > > At 11:47 PM -0500 9/20/06, W. D. wrote:
> > > > >Just reading this about Linux on ZDNet and
> was
> > > wondering:
> > > >
> >
>
><http://news.zdnet.com/2100-9593_22-6117479.html?part=rss&tag=feed&subj=zd
> > > > >nn>
> > > >
> > > > Cybernetic floobydust, IMHO.
> > > 
> > > If you read what the banker says: " for each
> > > thousandth of a second that its 
> > > trading software can act faster than
> competitors'
> > > software, the company would 
> > > see $100 million a year in new revenue."
> > 
> > and for every extra trade they do they change the
> > stock price faster and faster making them more
> money.
> > They're creating the money by manipulating the
> market
> > faster; the market doesn't create itself... How
> can
> > they even quantify this so called loss when their
> > trading is constantly changing the state of the
> > market.
> 
> Yes, Mr Heisenberg...
> 

if you buy the stock goes up if you sell the stock
goes down. how can one calculate how long your car
will last if it is based on how you drive and how many
red cars you see; considering how you drive is
dependant on how many red cars you see... I say my car
will last 10 years longer then the competition if I
see one more red car then them on my way to work...

the only thing that is certain is death, taxes, and
uncertainty.

> > > It seems to me that they are really
> misunderstanding
> > > the problem. What they 
> > > need is a system that's fast most of the time,
> > > rather than one that meets an 
> > > arbitary deadline all the time. In other words
> they
> > > need a fast system, not a 
> > > realtime system.
> > > 
> > 
> > I would imagine an extra 100 million would buy
> quite a
> > dusy of a system at that... processing data at a
> rate
> > of 1000 Hz doesn't seem to suggest a real-time
> system
> > is required when the average clock is 1 million
> times
> > faster then that. its not like they're doing FFT's
> on
> > a Radar signal, to determine if its a bogey and
> arming
> > the appropriate countermeasures so they can be
> > deployed the second the blip appears on the
> operators
> > screen.
> 
> They have all kinds of calculus and successive
> approximations
> in their models.   The more CPU they have, the more
> they add
> to the design.

you know, I forgot how trivial a fast fourier
transform is to compute on a 2-10 GHz signal... So
they add more to the design to process more calc and
propabilities based on past events in likely a
recursive fashion and get back to deadlocking the
systems with math and having real time processing is
going to fix this?

I think this is the managers solution to not listening
to IT telling them they need more powerful cores on
the cluster to handle processing thousands of tickers
at once, while crunching the nastiest of nastiest
probablities and executing trades. "Fixing" software
is always cheaper then buying hardware. 

of course I'm likely slightly jaded due to dealing
with architects all day; that and a pushy financial
advisor trying to sell me their services...

> 
> ////jerry
> 
> > 

-brian