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" <linrad@antennspecialisten.se>

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