FWIW: The bigger picture... Or why I have been asking a lot of questions lately...

[bruce.labitt at autoliv.com]

Jim Kuzdrall <gnhlug at intrel.com> wrote on 10/13/2009 02:04:36 PM:

> On Tuesday 13 October 2009 10:54, bruce.labitt at autoliv.com wrote:
> > gnhlug-discuss-bounces at mail.gnhlug.org wrote on 10/13/2009 08:13:12 
> AM:
> > > Greetings Bruce,
> > >
> > >     Still thinking about your problem...
> >
> > Well, thank you for that!
> >
> 
> > Data is converted to string prior to transmit.  This is an area for
> > improvement.  However, the timing numbers I've indicated 'should' be
> > just the transmission of the string buffer.
> 
>     If I can remember my C programming, you do something non-portable 
> like:
> ...
> /* number of pairs (initialize to the correct number) */
> int npair=128;
> /* the double does a boundary alignment */
> union {
>     double align;
>     float  ansf[npair][2];
>     char   ansc[npair*2*4]
>     } answer;
> 
> /* check that they are the same size (this does not guarantee
>    that they are aligned right; check the received data for that) */
> printf("float array size is %d and text array size is %d\n",
>         sizeof(answer.ansf), sizeof(answer.ansc));
> 
> cnt= fwrite( (char *)&answer.ansc, 4*2, npair, &output_dev);
> printf("The count was %d and it should be %d",cnt,npair);
> exit(0);
> ...
> 

The transfer is complete, the numbers do get across, and they are even 
correct.  I separated the problem into two parts - packing into strings, 
and sending the string over the socket.  The packing works well enough for 
now.  It is just the network transfer rate that isn't fast enough. 

>     Wow, C seems so unfamiliar after a few years away from it.  I hope 
> that gives you the gist of what I am suggesting to try.  There may be a 
> better choice of functions, but I thought a for-loop on fputc() would 
> cost a lot more cpu cycles.
> 

fputc is REALLY slow.  fwrite using big blocks is MUCH faster, orders of 
magnitude faster.

>     To get this to work, you may have to get the FFT program and the I/O 

> program to be separate processes - pipe or socket or something does 
> that.
> 
>     Maybe somebody more experience will make a suggestion.
> 
>     I got the speed increase more optimistic than justified, but you can 

> get about 4x by adding another data link.  Send the odd chunks to one 
> and the even chunks to the other.
> 

I have been toying with sending the real and imaginary parts on separate 
sockets in their own threads.  That is what psockets was supposed to do. 
(Striped network transfer).  It still bugs me that the utilization of the 
network is so bad.  A striped transfer, even if it is just two stripes, 
will be better than just one socket.  That is if I can get it to work... 
If I were to go to multiple sockets, I might as well use someone else's 
library, after all, why reinvent the wheel.

I'm still think it is a misconfigured/mistuned system.  I hope it is just 
a mismatch of parameters between the two computers.  Still, the most 
likely answer is that the problem lies in my code.  Time to dive in 
again...

Thanks!
Bruce


******************************
Neither the footer nor anything else in this E-mail is intended to or constitutes an <br>electronic signature and/or legally binding agreement in the absence of an <br>express statement or Autoliv policy and/or procedure to the contrary.<br>This E-mail and any attachments hereto are Autoliv property and may contain legally <br>privileged, confidential and/or proprietary information.<br>The recipient of this E-mail is prohibited from distributing, copying, forwarding or in any way <br>disseminating any material contained within this E-mail without prior written <br>permission from the author. If you receive this E-mail in error, please <br>immediately notify the author and delete this E-mail.  Autoliv disclaims all <br>responsibility and liability for the consequences of any person who fails to <br>abide by the terms herein. <br>
******************************