[Linrad] Re: Priority and IP addresses

[Leif Asbrink <sm5bsz.com; leif@xxxxxxxxxxxxxxxx>]

Hi Joe and All,

> It's very likely that you or others on this reflector know a great deal 
> more about this than I do.
Hmmm, I know next to nothing about networks. I also know
next to nothing about priorities in Windows.

What I do know are some practical observations I made......

> Some relevant facts I've determined empirically by running Linrad 
> together with MAP65 include the following:
> 
> 1. On the three Windows machines I've tested, if both Linrad and 
> MAP65-IQ are run on the same machine it is necessary to run Linrad at 
> "Above Normal" priority.
OK. What I found was that using something other than 127.0.0.1 would
allow high priority also for Linrad. 

> 2. There is no need (and I think no incentive) to run MAP65 at an 
> elevated priority.  MAP65 is not a real-time program in the same sense 
> that Linrad is; it has no tight tolerances to maintain in order to avoid 
>   glitches in audio output, etc.  When running in Windows, the MAP65 
> process sets itself to NORMAL_PRIORITY_CLASS.  The two threads that 
> handle UDP packet input (from Linrad) and audio output (to the SSB 
> transmitter) are set to THREAD_PRIORITY_ABOVE_NORMAL; the thread that 
> does decoding is set to THREAD_PRIORITY_BELOW_NORMAL.
OK.

> 3. With this setup, Windows is still perfectly usable for email, web 
> browsing, compiling programs, etc., while Linrad and MAP65 continue to 
> run without problems.
Hmmm, on a less powerful computer there might be problems if you do not
set the priority of MAP65 above the priority of other things.

> 4. MAP65-IQ can be configured to "listen" on IP address 127.0.0.1 while 
> Linrad (running on the same machine, call it computer A) sends timf2 
> packets to either 127.0.0.1 or the machine's own IP address (e.g., 
> 172.16.28.32).  No changes are required to MAP65-IQ for both addresses 
> to work in Linrad.  I took it that this means the "localhost" address 
> 127.0.0.1 is little more than a placeholder for the real IP address.
Now, these are things I do not understand. By default Linrad
sends UDP to 239.255.0.xxx but there might be no listener there.
Linrad can then run at priority high without problems.

Another instance of Linrad in the same computer may listen at 
239.255.0.xxx also at priority high without problems. 

When I change the transmit address to 127.0.0.1, high priority
no longer works. It does not matter what receive address I set
any more. The different values of xxx all pick up the data from 
127.0.0.1.

> 5. If Linrad runs on computer B, and MAP65 or MAP65-IQ on computer A, 
> Linrad should send its timf2 data explicitly to the IP address of 
> computer A.  Computer A can still "listen" on 127.0.0.1, however.
> 
> Perhaps there would be a difference in CPU loading if I had MAP65 listen 
> on its own IP address instead of 127.0.0.1.  I have made no tests to try 
> to determine this.  Unless it is true (at a level that really matters 
> when receiving timf2 data sampled at about 96 kHz, I can see no 
> advantage to making MAP65's input IP address anything other than 
> 127.0.0.1.  Have I missed something important?
Probably not.It seems that whatever packages sent to 127.0.0.1 are 
distributed to all listeners on the network within that computer 
while data sent to a specific address will not load any other 
process than the intended one. No reason to bother in case there 
are no problems.

I just had a problem with statements that one should never use
realtime priority for any process. Linrad can do that, but only with
soundcard input. This is good for really slow computers. With
USB it is no longer possible because the USB system routines would
not get the CPU time they need in time. Priority high is maximum with USB.
Now it is clear that when the network address 127.0.0.1 is used one
can not use priority high so the maximum priority for Linrad would
be above normal. If that is enough to avoid loss of data when resizing
windows etc while other applications are active on the network I see 
no reason to change anything. A very fast computer would of course
solve all potential problems also.....

   73


   Leif / SM5BSZ


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Linrad" group.
To post to this group, send email to linrad@xxxxxxxxxxxxxxxx
To unsubscribe from this group, send email to linrad+unsubscribe@xxxxxxxxxxxxxxxx
For more options, visit this group at http://groups.google.com/group/linrad?hl=en
-~----------~----~----~----~------~----~------~--~---


LINRADDARNIL