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 <pierre.vanhoucke@xxxxxxxxx>
To: "Linrad mailinglist" <linrad@xxxxxxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxxx>.
To unsubscribe, E-mail to: <linrad-off@xxxxxxxxxxxxxxxxxxxxx>
To switch to the DIGEST mode, E-mail to <linrad-digest@xxxxxxxxxxxxxxxxxxxxx>
To switch to the INDEX mode, E-mail to <linrad-index@xxxxxxxxxxxxxxxxxxxxx>
Send administrative queries to <linrad-request@xxxxxxxxxxxxxxxxxxxxx>
-------------------------------------------------------