[linrad] Re: Fwd: [linrad] Re: MAP65 Beta Testing
Hi Pierre, Many thanks for your messages. As it happens, after your first message I did almost exactly what is recommended in your second message. It helps a lot, reducing the number of dropped packets to a very small number. (Although not always exactly zero, the number is usually smaller than 0.3%, or 3 in 1000. That is not enough to worry about, I think.) Again, thanks for your help! ... and for trailing down the MAP65 code in the Berlios respoitory! -- 73, Joe, K1JT Pierre Vanhoucke wrote: Hello Joe, This afternoon I browsed in the map65 repository at berlios.de to find out more precisely what to do about the lost packets problem. If I am right (I can't test it out for the moment) the insertion in plrr_subs.c of the following instruction (stolen from Leif's network.c in watzo-01.01 ;-) ) should hopefully solve the problem: ** // Set a big buffer. Defaults: Linux=109568 and Windows=8192. i=131072; k=sizeof(int); setsockopt(fd,SOL_SOCKET,SO_RCVBUF,(char*)&i,k); *** 73 Pierre/ON5GN -- Forwarded Message -- Subject: [linrad] Re: MAP65 Beta Testing Date: Friday 06 July 2007 17:16 From: Pierre Vanhoucke <[EMAIL PROTECTED]> To: "Linrad mailinglist" Hi Joe, I am not an expert in networking either but enlarging the packet buffersize could solve your problem: After Leif increased the packet buffersize in the window version of watzo (win-wtz01-01) , I got rid of a lost packet problem that was present in win-wtz01-00. This change was based on the recommendation of Dirk Claessens who wrote: I heard from Pierre that Linrad for Windows is experiencing sporadic packet loss. It appears that there exists no magic registry key to enlarge the packet buffersize on a global basis. However, the buffersize can be set on a per socket basis: To get the current size: int skt, int sndsize; err = setsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sndsize, (int)sizeof(sndsize)); To set the new size: intsockbufsize = 0; intsize = sizeof(int); err = getsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sockbufsize, &size); ( to set the send buffer size: use SO_SNDBUF ) A word of caution: enlarging the buffer is not a magical solution. If - for whatever reason - a client cannot cope with the datarate of the server, the input buffers will overflow anyway, it will just take some more time. It will only help to cure occasional overload. ** From what you describe, it looks indeed that the bottleneck is not related to the speed of your network connection but rather to the processing of the incoming packets. Hope it helps 73, Pierre/ON5GN On Friday 06 July 2007 14:55, Joe Taylor wrote: I am anything but an expert in networking; in fact, I have some network-related questions of my own, as you will see below. For reasons I have not yet identified, my system works better with the network speed set at 10 Mb/s. If I set it to 100 Mb/s things still work, but the percentage of dropped packets increases to about 2.6% in steady state. Moreover, these numbers stay essentially the same (0.6% lost data at 10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both computers from the network hub and simply connect the two through a "crossover" cable. Probably I am doing something stupid in the "recvpkt()" routine in MAP65; or perhaps I need to set some parameter differently in the Linux and/or Windows computers. If anyone can shed light on the situation, or suggest some suitable diagnostics, I would be grateful. I use a completely different pair of computers for development work. One runs Debian Linux (installed from Knoppix) and the other runs Win XP/Pro. Between these machines the number of dropped packets is smaller but still not necessarily zero. With the network supposedly running at 100 Mb/s, I fairly often see a few (0-20, say) dropped packets (out of a total 33103) in a minute. Loss of 1% of the data is arguably not very important. It does not degrade JT65 decoding noticeably. Nevertheless, i would like to understand what I am doing wrong. # This message is sent to you because you are subscribed to the mailing list . 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 . To unsubscribe, E-
[linrad] Re: MAP65 Beta Testing
Hi Joe, I am not an expert in networking either but enlarging the packet buffersize could solve your problem: After Leif increased the packet buffersize in the window version of watzo (win-wtz01-01) , I got rid of a lost packet problem that was present in win-wtz01-00. This change was based on the recommendation of Dirk Claessens who wrote: I heard from Pierre that Linrad for Windows is experiencing sporadic packet loss. It appears that there exists no magic registry key to enlarge the packet buffersize on a global basis. However, the buffersize can be set on a per socket basis: To get the current size: int skt, int sndsize; err = setsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sndsize, (int)sizeof(sndsize)); To set the new size: int sockbufsize = 0; int size = sizeof(int); err = getsockopt(skt, SOL_SOCKET, SO_RCVBUF, (char *)&sockbufsize, &size); ( to set the send buffer size: use SO_SNDBUF ) A word of caution: enlarging the buffer is not a magical solution. If - for whatever reason - a client cannot cope with the datarate of the server, the input buffers will overflow anyway, it will just take some more time. It will only help to cure occasional overload. ** From what you describe, it looks indeed that the bottleneck is not related to the speed of your network connection but rather to the processing of the incoming packets. Hope it helps 73, Pierre/ON5GN On Friday 06 July 2007 14:55, Joe Taylor wrote: > I am anything but an expert in networking; in fact, I have > some network-related questions of my own, as you will see below. > For reasons I have not yet identified, my system works > better with the network speed set at 10 Mb/s. If I set it > to 100 Mb/s things still work, but the percentage of dropped > packets increases to about 2.6% in steady state. Moreover, > these numbers stay essentially the same (0.6% lost data at > 10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both > computers from the network hub and simply connect the two > through a "crossover" cable. Probably I am doing something > stupid in the "recvpkt()" routine in MAP65; or perhaps I > need to set some parameter differently in the Linux and/or > Windows computers. If anyone can shed light on the > situation, or suggest some suitable diagnostics, I would be > grateful. > > I use a completely different pair of computers for > development work. One runs Debian Linux (installed from > Knoppix) and the other runs Win XP/Pro. Between these > machines the number of dropped packets is smaller but still > not necessarily zero. With the network supposedly running > at 100 Mb/s, I fairly often see a few (0-20, say) dropped > packets (out of a total 33103) in a minute. > > Loss of 1% of the data is arguably not very important. It > does not degrade JT65 decoding noticeably. Nevertheless, i > would like to understand what I am doing wrong. # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] AW: [linrad] Re: MAP65 Beta Testing
Joe and All Fantastic, very simple, now my MAP65 computer is decoding the data comming from the Linrad via the network, one important point for the people running the MAP65 on Windows XP and Vista they need to introduce and exception on the firewall configuration otherwise packets are dropped. TNX Joe for your explanations, works fine Alex Artieda HB9DRI Ursprüngliche Nachricht Von: [EMAIL PROTECTED] Datum: 06.07.2007 14:55 An: "Linrad mailinglist" Betreff: [linrad] Re: MAP65 Beta Testing Alex and all, > I apreciate if some body tell me how integrate Linrad and MAP65 via > the network, I have no idea. I am anything but an expert in networking; in fact, I have some network-related questions of my own, as you will see below. Of course, the Linrad --> MAP65 network connection should(?) work without much effort on the user's part! I suppose my own setup is a more-or-less typical situation, so I will describe it first. At K1JT, MAP65 runs on Computer "A" under Windows 2000. Linrad runs on Computer "B" under Linux (currently, Kubuntu 6.06). Both computers are connected to a network hub through RJ45-style CAT-5 cables, and from there to the outside world through a dedicated ADSL line. My XYL's computer is also connected to the hub, and occasionally a laptop is connected as well. The Linrad - MAP65 combination works OK without changing anything in this normal network setup (but more on this later). Linrad 02.34 is set up to do its first forward FFT using "version 5" (SIMD /SSE instructions) and first backward FFT with version 1. This forces Linrad to multicast its TIMF2 in 16-bit format, the format expected by MAP65. To start the multicasting of TIMF2 data, hit "N" (Network setup) on Linrad's opening screen, and turn ON format 8. All other multicast options should be OFF. Then enter 0 to go back to the opening screen, hit "T" to toggle multicasting on, and then select mode "A" (weak-signal CW) for normal operation. Now start MAP65 on Computer A. It should immediately begin receiving the multicast packets from Linrad; at the end of each minute its waterfall displays should update and the JT65 decoder will be invoked. Now for the part where I am still scratching my head... MAP65 checks the serial block numbers of each incoming packet, so it can tell when any packet(s) have been missed. In my setup this happens all too often -- no doubt as a result of something I am doing wrong. MAP65 displays the percentage of dropped packets in the status bar at the bottom of its main window. In my present setup this number may be 3% or even larger for the first few minutes after starting MAP65; it then settles down to about 0.6% thereafter. For reasons I have not yet identified, my system works better with the network speed set at 10 Mb/s. If I set it to 100 Mb/s things still work, but the percentage of dropped packets increases to about 2.6% in steady state. Moreover, these numbers stay essentially the same (0.6% lost data at 10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both computers from the network hub and simply connect the two through a "crossover" cable. Probably I am doing something stupid in the "recvpkt()" routine in MAP65; or perhaps I need to set some parameter differently in the Linux and/or Windows computers. If anyone can shed light on the situation, or suggest some suitable diagnostics, I would be grateful. I use a completely different pair of computers for development work. One runs Debian Linux (installed from Knoppix) and the other runs Win XP/Pro. Between these machines the number of dropped packets is smaller but still not necessarily zero. With the network supposedly running at 100 Mb/s, I fairly often see a few (0-20, say) dropped packets (out of a total 33103) in a minute. Loss of 1% of the data is arguably not very important. It does not degrade JT65 decoding noticeably. Nevertheless, i would like to understand what I am doing wrong. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list . To unsubscribe, E-mail to: <[EMAIL PROTECTED]> To switch to the DIGEST mode, E-mail to To switch to the INDEX mode, E-mail to Send administrative queries to <[EMAIL PROTECTED] se> # This message is sent to you because you are subscribed to the mailing list . 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]>
[linrad] Re: MAP65 Beta Testing
Alex and all, I apreciate if some body tell me how integrate Linrad and MAP65 via the network, I have no idea. I am anything but an expert in networking; in fact, I have some network-related questions of my own, as you will see below. Of course, the Linrad --> MAP65 network connection should(?) work without much effort on the user's part! I suppose my own setup is a more-or-less typical situation, so I will describe it first. At K1JT, MAP65 runs on Computer "A" under Windows 2000. Linrad runs on Computer "B" under Linux (currently, Kubuntu 6.06). Both computers are connected to a network hub through RJ45-style CAT-5 cables, and from there to the outside world through a dedicated ADSL line. My XYL's computer is also connected to the hub, and occasionally a laptop is connected as well. The Linrad - MAP65 combination works OK without changing anything in this normal network setup (but more on this later). Linrad 02.34 is set up to do its first forward FFT using "version 5" (SIMD /SSE instructions) and first backward FFT with version 1. This forces Linrad to multicast its TIMF2 in 16-bit format, the format expected by MAP65. To start the multicasting of TIMF2 data, hit "N" (Network setup) on Linrad's opening screen, and turn ON format 8. All other multicast options should be OFF. Then enter 0 to go back to the opening screen, hit "T" to toggle multicasting on, and then select mode "A" (weak-signal CW) for normal operation. Now start MAP65 on Computer A. It should immediately begin receiving the multicast packets from Linrad; at the end of each minute its waterfall displays should update and the JT65 decoder will be invoked. Now for the part where I am still scratching my head... MAP65 checks the serial block numbers of each incoming packet, so it can tell when any packet(s) have been missed. In my setup this happens all too often -- no doubt as a result of something I am doing wrong. MAP65 displays the percentage of dropped packets in the status bar at the bottom of its main window. In my present setup this number may be 3% or even larger for the first few minutes after starting MAP65; it then settles down to about 0.6% thereafter. For reasons I have not yet identified, my system works better with the network speed set at 10 Mb/s. If I set it to 100 Mb/s things still work, but the percentage of dropped packets increases to about 2.6% in steady state. Moreover, these numbers stay essentially the same (0.6% lost data at 10 Mb/s, 2.6% lost data at 100 Mb/s) if I disconnect both computers from the network hub and simply connect the two through a "crossover" cable. Probably I am doing something stupid in the "recvpkt()" routine in MAP65; or perhaps I need to set some parameter differently in the Linux and/or Windows computers. If anyone can shed light on the situation, or suggest some suitable diagnostics, I would be grateful. I use a completely different pair of computers for development work. One runs Debian Linux (installed from Knoppix) and the other runs Win XP/Pro. Between these machines the number of dropped packets is smaller but still not necessarily zero. With the network supposedly running at 100 Mb/s, I fairly often see a few (0-20, say) dropped packets (out of a total 33103) in a minute. Loss of 1% of the data is arguably not very important. It does not degrade JT65 decoding noticeably. Nevertheless, i would like to understand what I am doing wrong. -- 73, Joe, K1JT # This message is sent to you because you are subscribed to the mailing list . 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]>
