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]>
