[linrad] Disappearing dirctories with Knoppix

[w3sz@xxxxxxxxxxx]

This has been a very full day.  I can't remember if it was posted that Leif has graciously found room for the Knoppix CD iso file on the sm5bsz.com server.

I am busy reworking / shrinking / 'fixing' the  iso before uploading it to sm5bsz.com.

I think I found the answer I think to Zaba's 'disappearing directory' problem, and why I see files and directories in the root directory here that Zaba says he doesn't see.  A quote from somewhere in 'Knoppix-ville' that I ran across this evening:

"Knoppix automatically overwrites the directory /home/knoppix with /etc/skel during boot".

So I think that the files that I had carefully placed in /root for users-san ended up in /home/knoppix/root with the Knoppix-Live CD boot process, and then got overwritten.  

The delay in upload for the iso file is caused by my trying an alternate strategy, making an iso file and then a CD with it, trying it, and then going back for round 2 etc to correct my mistakes.  It takes about an hour per cycle, and I just broke free to start this after 10 pm, so the uploaded iso may not appear before sometime late tomorrow.  I will announce when it is uploaded.

I have decided I need yet another computer, to contain ONLY an experimental, deletable Knoppix hard-disk installed system, to look for these bugs which don't appear if the testing is on the system with the permanent reference install.  I will see if any of wife/children can give up their computer for this noble purpose [only kidding, I am not that stupid ;)  ].

73, all with my apologies for the delay...

Roger
W3SZ


> 
> Leif-san,
> 
> Multi-threading keeps you busy and hopefully you have
> received expert advice for some of your questions....
> 
> I have now understood that the CPU is not determining
> the delay in 'Linrad', but rather: the slower the CPU,
> the higher its relative usage, until it reaches 100%..
> Then the application probably "collapses"... a rare
> occurrence with today's fast processors.
> 
> All of the integrated audio on several motherboards
> "propose" a sample rate choice up to 48000, except the
> Abit IC7 (proposing choices up to 192000). It does not
> mean that one can build an I/Q-receiver with successful
> utilization of the full bandwidth. Actually the IC7 is
> the worst quality board (compared to all others here)
> regarding the operation of the integrated audio circuit
> (at least as far as the microphone input is concerned).
> 
> For example under Skype VoIP-communications there is a
> strong tapping noise on the outgoing audio, and under
> 'Linrad' the input spectrum shows wide noise bands at
> 7 kHz and 41 kHz on the frequency spectrum when using
> 48000 sampling rate (when no input signals are fed).
> All of this may be better on the line input (however
> not tested). Also another main power supply should be
> tried to ensure that all MB-voltages have been clean.
> 
> As Leif/SM5BSZ suggested, some audio cards can be set
> beyond their specs to give the CPU some more samples
> and a bigger work load. So the sampling rate of the
> integrated audio of the Abit IC7 was set to 192000
> and the output rate to 8000 Hz. With a 2400 MHz P4
> this resulted in about 26% CPU-load, and with the
> inefficient Lagrange-interpolation under 192000 Hz
> output sampling, the load was 36%. I do not know what
> the extra load is for 4-channel operation, but probably
> this setup could process future 8-channel 192 kHz input
> sampling if the output rate is limited to the low rates.
> 
> When feeding audio to the IC7 input, it was clearly seen
> that the circuitry was not designed for these high rates
> as the input spectrum showed multiple aliased responses,
> and the baseline level dropped off above 24 kHz separation
> form the center frequency. Also I noticed that the 'Linrad'
> frequency scale of the waterfall behaves like an old car's
> mileage meter, showing 100 000 as 00 000 (actually just 0).
> So the parameter needs an allocation for one more figure
> on the right end of the scale: e.g. 140000 Hz now 40000 Hz.
> Initially this was a little confusing, but the experiment
> yielded this improvement suggestion for the user-interface.
> 
> As such all these experiments have again derailed me from
> the goal to get some form of real world reception ability.
> Thus it is about time to link up some of the analog stuff
> in front of the sound inputs. That is actually the best
> incentive to learn about the use and optimization of the
> various parameters. The impulse generator for the quick
> calibration of the I/Q-channels (and the smart blanker)
> is actually not too complicated, but here its construction
> has been delayed already for years, due to all the other
> "interesting" 'Linrad' experiments and software challenges.
> 
> A key for quick successful results would be an "approach
> guidebook" that should be fairly strictly followed. The
> ongoing Live_CD development by Roger/W3SZ will certainly
> speed up the start-up time of new candidates (by 10 dB).
> 
>            73, "Zaba" OH1ZAA/2  [The sky is no limit]
> 
> 
> At 19:28 26.4.2005 +0200, SM5BSZ wrote:
> 
> >Hi All,
> >
> >In the current Linrad package, the CPU spends its
> >surplus time in an "idle loop" which is just doing
> >nothing or sending the process to sleep with usleep();
> >depending on the parameters selected by the user in
> >the initial setup.
> >
> >Just by comparing the time spent in the idle loop
> >to the total time one gets a good number for how much
> >of the time available to Linrad that could be used for
> >heavier processing.
> >
> >In the multi-threaded version the above strategy is
> >not possible. Any time not needed by Linrad is consumed
> >by the kernel or another task. Instead a system call
> >getrusage() is used to get the total amount of time
> >that the CPU spent with the task. This works fine
> >with the 2.6 core and is how getrusage is defined
> >according to POSIX (whatever that is) but in the 2.4
> >and older kernels getrusage works differently. It
> >just gives the time consumed by the calling thread
> >and therefore all threads have to be interrogated.
> >This is fine in the development phase because it
> >allows me to see where the time is spent, but summing
> >over the fifteen threads which gives the correct load
> >under 2.4 kernels gives a value that is too big by 15
> >times under 2.6.
> >
> >By setting a global define GETRUSAGE_OLD to 0 or 1
> >Linrad works fine under both kernels. Currently
> >a header file has to be edited manually, but I am sure
> >it is possibe to use the configure script to find out
> >which of the behaviours to implement at compile time.
> >Presumably it amounts to find the GCC version and make
> >a test on it to get a yes or no answer.
> >
> >I just do not know how to do it. Is there anyone on the
> >list who knows? I do not understand anything about how
> >the configure script really works - someone made it for
> >me - so I really need a few lines to add to the Linrad
> >configure.in file to get an input to AC_SUBST.
> >
> >73
> >
> >Leif / SM5BSZ
> 
> 
> #############################################################
> 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>
> 

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


LINRADDARNIL