nanogui: Thread: Overloading the nano-X server

Hello,

I have a situation where a scientific instrument is capable of generating a new dataset as fast as every 10 milliseconds (although not always that fast), and my Nano-X code has to create an XY plot (graph) of the data and display it on a 320 x 240 display.  I do not need to display every dataset the instrument generates (i.e. it is OK if some of the datasets are "dropped"), but I want the system to display as many as it can, up to the limitations of the processor and display hardware.

Currently, the way my code works is my Nano-X client uses the dataset from the instrument to calculate one GR_POINT for each pixel along the x-axis of the plot window.  Then I call the "GrPoly" function, passing in that array of GR_POINTs, to "connect the dots" and create the plot on the screen.

This method works great until I set the instrument to the faster speeds.  Then the Nano-X client starts sending the server "GrPoly" commands faster than the server can process them and the display can display them.  The Nano-X server starts to fall behind, the "GrPoly" commands start stacking up in the queue, and the system becomes unresponsive because the nano-X server is working so hard and the client rarely is getting any time to run.  (If I use the "GrPoints" function instead of "GrPoly", the system can keep up much better, but the plots don't look good enough.)

I am relatively new to Nano-X development, so I am hoping someone can help me with a solution to this.

* Is there a way for the client to find out somehow if the server is still working on a previous GrPoly command?  If so, then the client could just "drop" any datasets that come in until the server and display had completed the one they were working on, preventing the server from becoming overloaded.

* Is there some other approach I could use to plot the data that would be faster?

Thanks for any ideas or suggestions.

Steven Vahl


________________________________
NOTICE: This message (with any attachments) is confidential and may constitute privileged communication, and is intended only for the recipient(s) named herein. If you are not the intended recipient, or a person responsible for delivering this message to the intended recipient, you are hereby notified that any distribution, copying or dissemination of the information herein is strictly prohibited. If you have received this e-mail in error, please contact us immediately by telephone, facsimile, or email, and delete this e-mail from your computer system without retaining a copy.

On Mon, Nov 09, 2009 at 04:53:55PM -0700, Steven Vahl wrote:
> * Is there a way for the client to find out somehow if the server is
> still working on a previous GrPoly command?  If so, then the client
> could just "drop" any datasets that come in until the server and
> display had completed the one they were working on, preventing the
> server from becoming overloaded.

try adding a call to GrFlush() after the call to GrPoly().  that will
keep the commands from stacking up.

> * Is there some other approach I could use to plot the data that would
> be faster?

the line draw routines in nano-X have a large potential for optimization
by moving line draw to the driver level.  how much work do you want to
do to speed this up?

-- 
  Aaron J. Grier | "Not your ordinary poofy goof." | ####@####.####

Hi Steven,

I would try to collect the data in an additional thread.
The drawing can be done later with the normal gui thread.

Bye
Uwe

if you don't really need a client/server arch you can try cutting off a lot o socket traffic compiling with LINK_APP_INTO_SERVER. On my hardware (arm or sh) this leads to general performance improvement. You'll have not more need to run the nano-x server.

Steven Vahl ha scritto:
> Hello,
> 
> I have a situation where a scientific instrument is capable of generating a new dataset as fast as every 10 milliseconds (although not always that fast), and my Nano-X code has to create an XY plot (graph) of the data and display it on a 320 x 240 display.  I do not need to display every dataset the instrument generates (i.e. it is OK if some of the datasets are "dropped"), but I want the system to display as many as it can, up to the limitations of the processor and display hardware.
> 
> Currently, the way my code works is my Nano-X client uses the dataset from the instrument to calculate one GR_POINT for each pixel along the x-axis of the plot window.  Then I call the "GrPoly" function, passing in that array of GR_POINTs, to "connect the dots" and create the plot on the screen.
> 
> This method works great until I set the instrument to the faster speeds.  Then the Nano-X client starts sending the server "GrPoly" commands faster than the server can process them and the display can display them.  The Nano-X server starts to fall behind, the "GrPoly" commands start stacking up in the queue, and the system becomes unresponsive because the nano-X server is working so hard and the client rarely is getting any time to run.  (If I use the "GrPoints" function instead of "GrPoly", the system can keep up much better, but the plots don't look good enough.)
> 
> I am relatively new to Nano-X development, so I am hoping someone can help me with a solution to this.
> 
> * Is there a way for the client to find out somehow if the server is still working on a previous GrPoly command?  If so, then the client could just "drop" any datasets that come in until the server and display had completed the one they were working on, preventing the server from becoming overloaded.
> 
> * Is there some other approach I could use to plot the data that would be faster?
> 
> Thanks for any ideas or suggestions.
> 
> Steven Vahl
> 
> 
> ________________________________
> NOTICE: This message (with any attachments) is confidential and may constitute privileged communication, and is intended only for the recipient(s) named herein. If you are not the intended recipient, or a person responsible for delivering this message to the intended recipient, you are hereby notified that any distribution, copying or dissemination of the information herein is strictly prohibited. If you have received this e-mail in error, please contact us immediately by telephone, facsimile, or email, and delete this e-mail from your computer system without retaining a copy.
> 


-- 
*Luca  Santini*
//Elettronica di Sistema//

*SPES. S.c.p.a*
Via  Lamberto Corsi, 43   
60044 Fabriano (AN)
tel. +39 0732 25291 diretto 0732 25451
fax +39 0732 2529441
####@####.#### ####@####.####
www.spesonline.com <http://www.spesonline.com>

I work with a similar situation. We handle this by collecting the data 
into a data structure and then plotting our data at whatever rate we can 
support. This way you can plot all the points but there may be multiple 
points added since the last time you drew the graph.

Steven Vahl wrote:
> Hello,
>
> I have a situation where a scientific instrument is capable of generating a new dataset as fast as every 10 milliseconds (although not always that fast), and my Nano-X code has to create an XY plot (graph) of the data and display it on a 320 x 240 display.  I do not need to display every dataset the instrument generates (i.e. it is OK if some of the datasets are "dropped"), but I want the system to display as many as it can, up to the limitations of the processor and display hardware.
>
> Currently, the way my code works is my Nano-X client uses the dataset from the instrument to calculate one GR_POINT for each pixel along the x-axis of the plot window.  Then I call the "GrPoly" function, passing in that array of GR_POINTs, to "connect the dots" and create the plot on the screen.
>
> This method works great until I set the instrument to the faster speeds.  Then the Nano-X client starts sending the server "GrPoly" commands faster than the server can process them and the display can display them.  The Nano-X server starts to fall behind, the "GrPoly" commands start stacking up in the queue, and the system becomes unresponsive because the nano-X server is working so hard and the client rarely is getting any time to run.  (If I use the "GrPoints" function instead of "GrPoly", the system can keep up much better, but the plots don't look good enough.)
>
> I am relatively new to Nano-X development, so I am hoping someone can help me with a solution to this.
>
> * Is there a way for the client to find out somehow if the server is still working on a previous GrPoly command?  If so, then the client could just "drop" any datasets that come in until the server and display had completed the one they were working on, preventing the server from becoming overloaded..
>
> * Is there some other approach I could use to plot the data that would be faster?
>
> Thanks for any ideas or suggestions.
>
> Steven Vahl
>
>
> ________________________________
> NOTICE: This message (with any attachments) is confidential and may constitute privileged communication, and is intended only for the recipient(s) named herein. If you are not the intended recipient, or a person responsible for delivering this message to the intended recipient, you are hereby notified that any distribution, copying or dissemination of the information herein is strictly prohibited. If you have received this e-mail in error, please contact us immediately by telephone, facsimile, or email, and delete this e-mail from your computer system without retaining a copy.
>
>   

: try adding a call to GrFlush() after the call to GrPoly().  that will
: keep the commands from stacking up.

This a good idea, but could also cause a context switch between
processes, depending on the scheduler.  What might help would
be GrFlush() after so many points sent, rather than each batch.

If the pipe between the client and server has unread data, and
there's only one application connected to the server, then
that method could be used to determine whether the server
is backed up reading commands from the client.  It won't tell
how much time is required to finish the current [graphics]
operation.


Regards,

Greg

> I would try to collect the data in an additional thread.
> The drawing can be done later with the normal gui thread.

If this method were used to collect data, and GrFlush(),
follwed by a Gr operation requiring a client read (like
GrGetWindowInfo) were done in the gui thread, then
the ratio of time spent collect versus plotting might be
roughly approximated.  This could then be used to 
schedule how much data was sent to the server.
It could then be optimized be sending more graphics
commands per collect/GrFlush() cycle, and elimnating
the read operation, in the event it was more important 
to stay with the most recently collected data.

Regards,

Greg

Hello,

I wanted to say thanks to everyone for taking the time to help me with my problem.  I thought I'd let you know how it worked out, in case you're interested.  (If you're not, feel free to skip all the following...)

To clarify my situation, I was already collecting the data in a different process than the GUI process.

In my GUI, based on Mr. Grier's suggestion, I first I tried the GrFlush() command after my GrPoly() command.  By itself, the GrFlush() did not help things much.  But, by trial and error when I was debugging, I found that when I called a GrGetGCTextSize() command after the GrFlush(), then the problem with my GUI process "locking up" (not getting any processor time) went away.  I had no idea why this worked until Mr. Haerr mentioned the need to call a Gr operation that requires a client read.  I must have stumbled upon this by accident.  So far I haven't noticed any problems caused by calling GrFlush() after every GrPoly().

In parallel to this, Mr. Santini was trying to help me to squeeze a little more performance out of my system by using the LINK_APP_INTO_SERVER option to eliminate the separate nano-X server process.  Unfortunately, I don't know much about Makefiles and I haven't been able to figure out how to modify the Makefile I'm using to properly link all the required nano-X libraries to get my application to build when this option is enabled.  Since I'm not expecting a really big performance boost from this, and since most of my problems went away (for now) by adding the GrFlush() and GrGetGCTextSize() commands, I'll be leaving things as they are for now.  I expect to revisit this performance issue later in my project when my real hardware platform is further along.  (Right now I'm working on a development board.)

Anyway, thank you all again.

Steven V.

-----Original Message-----
From: Greg Haerr ####@####.####
Sent: Wednesday, November 11, 2009 3:21 PM
To: Klatt Uwe; Steven Vahl; ####@####.####
Subject: Re: [nanogui] AW: Overloading the nano-X server

> I would try to collect the data in an additional thread.
> The drawing can be done later with the normal gui thread.

If this method were used to collect data, and GrFlush(), follwed by a Gr operation requiring a client read (like
GrGetWindowInfo) were done in the gui thread, then the ratio of time spent collect versus plotting might be roughly approximated.  This could then be used to schedule how much data was sent to the server.
It could then be optimized be sending more graphics commands per collect/GrFlush() cycle, and elimnating the read operation, in the event it was more important to stay with the most recently collected data.

Regards,

Greg

======================

Hello,

I have a situation where a scientific instrument is capable of generating a new dataset as fast as every 10 milliseconds (although not always that fast), and my Nano-X code has to create an XY plot (graph) of the data and display it on a 320 x 240 display.  I do not need to display every dataset the instrument generates (i.e. it is OK if some of the datasets are "dropped"), but I want the system to display as many as it can, up to the limitations of the processor and display hardware.

Currently, the way my code works is my Nano-X client uses the dataset from the instrument to calculate one GR_POINT for each pixel along the x-axis of the plot window.  Then I call the "GrPoly" function, passing in that array of GR_POINTs, to "connect the dots" and create the plot on the screen.

This method works great until I set the instrument to the faster speeds.  Then the Nano-X client starts sending the server "GrPoly" commands faster than the server can process them and the display can display them.  The Nano-X server starts to fall behind, the "GrPoly" commands start stacking up in the queue, and the system becomes unresponsive because the nano-X server is working so hard and the client rarely is getting any time to run.  (If I use the "GrPoints" function instead of "GrPoly", the system can keep up much better, but the plots don't look good enough.)

I am relatively new to Nano-X development, so I am hoping someone can help me with a solution to this.

* Is there a way for the client to find out somehow if the server is still working on a previous GrPoly command?  If so, then the client could just "drop" any datasets that come in until the server and display had completed the one they were working on, preventing the server from becoming overloaded.

* Is there some other approach I could use to plot the data that would be faster?

Thanks for any ideas or suggestions.

Steven V.




NOTICE: This message (with any attachments) is confidential and may constitute privileged communication, and is intended only for the recipient(s) named herein. If you are not the intended recipient, or a person responsible for delivering this message to the intended recipient, you are hereby notified that any distribution, copying or dissemination of the information herein is strictly prohibited. If you have received this e-mail in error, please contact us immediately by telephone, facsimile, or email, and delete this e-mail from your computer system without retaining a copy.