[Linrad] Re: Linrad-03.06

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

Hi Ermanno,

> This weekend I used Linrad-03.06 with Linux and Windows.
> Let me askone thing that does not expressly for this 
> version.
> Pressing the "T" key and looking to delay of the process, 
> I noticed that using the same hardware, 
> the value A/D change between windows and linux.
> I try to explain better; the value in windows A/D is far 
> from 96,000 (Delta 44 as input) is usually around 
> to A/D: 95800 or A/D: 95500.
This is an error. Your Windows system is overloaded one way
or another and as a result some of the interrupts from
the Delta 44 are silently ignored and data is lost.

> With Linux the value is very close to 96000  A/D: 
> 96011 or A/D: 96014.
It seems Linux can handle things better.

>  I noticed that this difference affects the performance of 
> MAP65  that works well if A/D is close to 96000.
Yes. Loosing some of the data will give an incorrect average
sampling speed. In case very strong signals are present there would
also be "keying clicks" due to abrupt phase changes.

> May depend on what (drivers?) 
It is something with the network. I can not reproduce this
problem on my stationary P4 which is connected to my local
network wia a switch.

On the the dual core laptop Windows works differently. If I have
the Ethernet cable connected I see a sampling rate of about 36 kHz
while the nominal rate is 48 kHz. By removing the Ethernet cable to
use only the internal loopback I can make the computer work properly.

The laptop runs Windows XP while the stationary computer runs 
Windows 2000.

> Can compensate in Linrad this value so that A/D = 96000 ?
I think there is a problem with latency due to the Network routines.
The operating system is waiting for something from the other end
of the Ethernet cable and in the meantime the Delta44 is not serviced.
I can not say that I know that this is the correct explanation, but
that is what it looks like to me.

Linrad is sending UDP packages and I the idea I had was that those
packages might be lost occasionally. That would not hurt - at least not
when packages are received by Linrad or Watzo because missing data
would become zero-padded. I think Joe did the same for MAP65.

There might be things that could be changed in the Windows network
configuration.

Another solution is to reconfigure your hardware. When I connect the
Ethernet port of my laptop directly to another "Gigabit ethernet" 
computer the problems disappear and I get the correct sampling rate 
on both computers. Even at 2MHz with the Perseus. When I try to run
through the network switch, Linrad does not work at all with the 
Perseus when the network is enabled. Not even at 125 kHz.

I have no idea what the "proper solution" would be. Somehow the
operating system should be informed that the Delta44 or whatever 
input has priority and that loosing packets on the network is ok. 
I tried different priorities on Linrad, but maybe network 
activities on behalf of Linrad inherits Linrads priority or
perhaps has maximum priority by default.

To solve the problem within Linrad it might be necessary to place
network activities in a separate thread and to arrange for Linrad
to throw away data now and then in case the buffers become full. 
By not using blocking writes it might be possible for Linrad
to take responsibility for the network.

On the other hand, proper hardware arrangements should be a much
better solution. Or running Linrad under Linux;-)


   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