I've played a bit with
vector length
, and seen the effect on latency and dsp usage, but somebody asked me to explain it.
This made me realise that I didn't really (or even vaguely) understand. After a bit of Googling and Wikipedia searching, I still don't have a definition of Vector Length in this context.
I did see terms that I vaguely recalled from Uni maths, but that's way too long ago.
Does anybody have a working explanation?
While we're at it, is there any info on
Control Frame Rate
and
GUI Poll Rate
, and particularly why/when/how you'd want to change from defaults?
I reread a couple of posts from 2008 (thanks James and Scott), but still not sure.
Over!
Roger?

The audio in a NION is really data. The data is processed by the DSP in chunks, or groups of digital samples. These chunks are called vectors or, in the vernacualr, are also known as 'bricks'.  There are 'n' number of samples per vector. The samples arrive serially and are buffered until 'n' number have arrived. They are then handed off to be processed by the DSP.  So a larger vector size will result in longer latency (more buffer wait time) but more efficient use of DSP cycles. Smaller vectors result in lower latency but will exercise the DSP processor much harder.    RULE OF THUMB:   Don't change the vector length. The default provides a very good balance between latency and processing horsepower. Leave it alone.
NWare will update the NION's CONTROL VALUES on a regular basis to insure that when you make a change in NWare, Kiosk or nTouch that the DSP function is changed in a responsive manner.
The control frame rate is how many times per second that the control values are sent to the NIONs.  AGAIN, as above, Leave this value alone. Any slower and the response time will lag. Any faster and you are just adding unnecessary overhead to the network and the processor.
The GUI poll rate is the rate at which NWare will update the GUI to reflect the actual values in the NIONs. And of course, once again, leave this value as it is also. The default value is optimum.

Thanks Steve. Exactly what I was after.
Perhaps Andy could add something like this to the docs.

Geez cobraguy, you are just no fun whatsoever. Don't touch this, leave that alone, never change this..... Since you have nicely explained the control frame rate value, I would argue that there are applications where its default value is far from optimum. I can think of several times where 'experts' have arrived to make golden-eared, or other monstrously expensive, yet imperceptible adjustments; the optimal control frame rate value for their computers would be 0.

I agree with Jason on this one... if these thing were not meant to be touched, why are they editable fields anyway?
Here are some tidbits...
If the vector length is lowered, the NION will appear to have less processing power but the latency will improve.
If the GUI poll rate is increased, the NION will update GUI controls more frequently but use more CPU cycles to do it.
Maybe these can be more readily applied to 'real world' scenarios.