Hello,

here is what we found when we had some network performance problems in the 
office:

se a "well known search engine" and look for the phrase "net.core.rmem_default"
for example described in  
http://wwwx.cs.unc.edu/~sparkst/howto/network_tuning.php

Please do not ask me any special details, I only read it and took it.

During some earlier network optimizations we also found that just looking at 
the raw amount of data beeing transfered is only partly correct. Some network 
stacks reach the limit first by the number of packets, not the amount of data. 
So it might be useful to make transport blocks as large as possible. Just like 
a Layer4, just inverse.

73, G√ľnter, DL4MEA


-----Urspr√ľngliche Nachricht-----
Von: Linrad mailinglist [mailto:[EMAIL PROTECTED] Im Auftrag von Leif Asbrink
Gesendet: 07 January 2007 00:28
An: Linrad mailinglist
Betreff: [linrad] Network speed problems.

Hi all,

Having been sucessful with raw data at speeds up to
96000*4*(16+18+24)=22 Mb/s I sort of believed 
it was possible to run at rates reasonably near
100 Mb/s when only sendind data in one direction
since the machine says: "Link is up at 100Mbps, full duplex"

Now, as it turns out I did the above test with only
one RF channel so the speed was only 11 Mb/s.
What is more of a problem is that the maximum
throughput through one socket is actually just a little
below 96000*4*16 = 6.1 MB/s. It is perfectly ok
to send 5MB/s through four sockets simultaneously
but sending fft1 transforms through a single
socket is impossible.

Presumably this is well known, I an just a newcomer
to networking and I could not guess it would behave
this way.

Is there some settings I should change? One possibillity
seems to be to open several sockets on different ports
simultaneously to increase the throughput.

I can not send even 16 bit noise-blanked time domain data
from Linrad to MAP65 over the network on a single socket.
14 bit data will be fine however because the Linrad 
processing removes all strong signals when the MMX routines
are selected.  

Is there something wrong in what I do? Does Windows behave
the same way? 

To be able to run at 96 khz with fft1 transfer it seems
I will have to use at least 6 sockets in parallel with
different port numbers.

It is interesting to note that the old Pentium MMX at 200 MHz
uses very much more CPU (under an old kernel) but that the
throughput through one socket does not differ much. It can
not send more than a 16 bit channel because there is not
enough CPU time available.

Trying to find some hints on the Internet I came across this:
http://www.ncsa.uiuc.edu/UserInfo/Resources/Hardware/IBMp690/IBM/usr/share/man/info/en_US/a_doc_lib/aixbman/prftungd/2365c93.htm

    * Do not change the default (and maximum) MTU of 1500 bytes.
    * Set the application block size in multiples of 4096 bytes.
    * Keep socket space settings at the default values.
    * If the workload includes extensive use of services that use UDP, such as 
NFS or RPC, increase sb_max to allow for the fact that each 1500-byte MTU uses 
a 4096-byte buffer. 

It seems to indicate that I should send much larger packets???
(a multiple of 4096 bytes 'header' included)


  73

  Leif / SM5BSZ


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>


#############################################################
This message is sent to you because you are subscribed to
  the mailing list <linrad@antennspecialisten.se>.
To unsubscribe, E-mail to: <[EMAIL PROTECTED]>
To switch to the DIGEST mode, E-mail to <[EMAIL PROTECTED]>
To switch to the INDEX mode, E-mail to <[EMAIL PROTECTED]>
Send administrative queries to  <[EMAIL PROTECTED]>

Reply via email to