From: John Morrison (jmorrison_at_ahc.net.au)
Date: 2002-03-29 00:18:26
I'll give a better answer next time as I'm just about out the door for a
break away a few days.
I'd like to see Buffers in the system in case of "variable" processing
times. A process may take a long time (Graphics) on one call and no time on
the next so could "Catch up" if necessary.
Processing power is probably enough to handle it BUT!
Tests of a scaled up system is the ONLY real way to check........
Even with context switching I'd prefer to see A high priority thread running
device Input then dropping it into a buffer.
>From then on the processing model would be FINE as we can't loose data or
each process could "decide" to loose data if the buffer is building.
Anyway see you all in a few days. :-)
John
> -----Original Message-----
> From: Jim Peters [mailto:jim_at_uazu.net]
> Sent: Friday, 29 March 2002 7:10 AM
> To: buildcheapeeg_at_yahoogroups.com
> Subject: Re: [buildcheapeeg] Managing a network of nodes and data
> streams in one thread
>
>
> John Morrison wrote:
> > I've been having a think about the idea since it was put up and
> I do like it
> > as we should reduce contact switching as much as possible.
> Though I "think"
> > there "maybe" problems too.
> >
> > MY ANALYSIS
> > So as I understand it a data byte arrives at the device which
> in some way
> > triggers the "network" which executes the following actions.
> > > dev->process();
> > > fb1->process();
> > > fb2->process();
> > > xmas->process();
> > Sounds great (I do like the idea) until we realise it's a REAL
> TIME system
> > we are working toward.
> >
> > So lets plug some (Made UP) figures into this system and apply some
> > restrictions and assumptions to the system.
> >
> > Assumptions
> > ALL inputs and outputs aren't buffered and can only hold 1
> byte of data at
> > a time.
> > TI = Time Interval
> >
> > Timings (No basis in reality just for demonstration)
> > DEV
> > Input arrives every 1 TI
> > stay valid for .5 TI
> > Process takes .5 TI
> >
> > FD1/2
> > Process takes .5 TI
> >
> > xmas
> > Process takes .5 TI
>
> If the processing for every sample takes longer than the interval
> between samples, then we are stuffed in any case -- even if we had a
> different networking model, or huge buffers, the processing would just
> get farther and farther behind the input.
>
> So, in your model, the total processing must be less than 1 TI,
> whichever way we arrange the networking code. If it doesn't, then
> your computer simply isn't fast enough to do what you want to do.
>
> The only way around this is to do what you do when you are handing
> audio, and that is to optimise the processing code by breaking up the
> audio into 64-sample (or larger) chunks, which are faster to process
> and pass around. However, in our situation, dealing with data at
> 256Hz, say, working in 64-sample chunks results in a 250ms delay.
>
> For the kind of data rates we're using (e.g. 256Hz, rather than audio
> rates of 44100Hz), I think processing one sample at a time would be
> quite feasible. Working in chunks of 4 or 8 samples might also be
> do-able, which could give a small increase in speed, but I don't think
> it is worth the extra coding complexity and signal delays. Also, it
> really would start getting messy if we tried to handle signals with
> different sampling rates in 4-sample chunks (e.g. 16Hz and 256Hz).
>
> As a guide to the processing power required, imagine what kind of spec
> machine you would need to run a network in one of those audio plugin
> platforms like Buzz or Cubase, and then remember that we're dealing
> with data at roughly 1/100th of the sampling rate. So we don't need
> *that* powerful a machine to do what we want to do.
>
> I hope this helps --
>
> Jim
>
> --
> Jim Peters (_)/=\~/_(_) jim_at_uazu.net
> (_) /=\ ~/_ (_)
> Uazú (_) /=\ ~/_ (_) http://
> B'ham, UK (_) ____ /=\ ____ ~/_ ____ (_) uazu.net
>
>
> To unsubscribe from this group, send an email to:
> buildcheapeeg-unsubscribe_at_egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
This archive was generated by hypermail 2.1.4 : 2002-07-27 12:28:43 BST