Re: not yet perfect, but...

Ulrich G. Kliegis

Hi David,

nice to know you are around all the time:)

I'll readjust the dish today (hopefully). Should help with the
missed packets. Or?

Judging by your graphs, Ulrich, it seems you may have made an
adjustment around 13:00 UTC.
That was the first attempt, yes. A bit tricky here, the rec PC lives in the
basement, and since I don't have a helper here right now, I have to transfer
the audio signal from server4pc to the dish on the balcony (now ice-free) by
means of the house-phone.

I losened and refastened the screws keeping the stand together, since it
looked like the parts had shifted a bit there - this led to a 2 % higher signal
strength, a just visible increase in the SNR, and about 8% in signal quality.

The two quad-LNBs for Astra and Hotbird 6 sit on the same rail like the
single LNB for EB9. I had optimized the dish position and adjustments for
the latter, since it carries the weakest signal.

The TV channels ar still beyond their previous quality (but totally dead
before the first adjustment today), although they still sit in the same position
on the rail. It would be interesting to hear from Arne who has the same dish,
if it can deform in vfa (very fast air).
Being not yet happy with the result, I loosened the screws that hold the
whole tilting mechanics on the pole and gave the mirror a light push - again
listening to the audio-feedback. Re-fastened it, again, a very slight increase
in strength, but nothing else.

Missed packets are usually caused by too high a load on your system,
in particular:

- network IO
- CPU load
- disk I/O

For most systems, adding a RAMdisk on which to store the FSY files
reduces the susceptibility to these overloads down to a level where
there are but a few missed packets a day, as you can see here:
I have a 349 MB sized RAM disk (some commercial solution), you see the
fsy file size - totally constant - on my eumetmon - page.

Note that we are in the solar outage period right now, so the peak in
missed packets on my system in the last day or two is due to solar
noise getting into the receiving chain, in my case around 11:30 UTC.
That's about 11:42 here (which is only intuitively paradox, gemetrically
correct, if my navigating intuition doesn't fail...)

See whether the graph of missed packets has peaks that correspond to
other activity on the PC. On your combined graph, for example, shift
the missed packet graph to be under the throughput graph, and I think
you will see a correlation.

The peaks at about 06:30 UTC and 12:55 UTC look to be due to a
different activity.
Yes, I'll trace that for another day or two. It can be the backup program, I
could run that with a reduced priority.

Speaking of priorities, I happened to look at the active processes in sysmon
on the receiver. First, I saw that server4 PC exists there twice, both
instances running with priority set to normal. tc-recv is there twice as well,
one running with prio set to 'high', the other 'higher than normal'. I never
changed anything there, so that's probably standard.

If you have a two-PC setup with a LAN connection, you might want to
check that the LAN on the receiver PC is set to 100Mb/s rather than
1Gb/s, as I've found that it can cause problems working at the
higher-speed, possibly due to "interrupt coalescing". Note that
changing the LAN speed /may/ cause the interface number to change, so
a power-down reboot after that would restore the old numbers.
All PCs run at 100 Mb/s here.

The LAN activities seem to be pretty low, just the peak after switching on the
viewing machine is prominent, the rest rather unspectacular, I think.

I'll re-check the recv.ini settings. The totally constant FSY size puzzles me.

I think, the front end (skystar) does not need much more attention, otherwise
the BER should be much higher.

It is really surprising how much analysis can be done from remote based on
that few pixels... :) Highly complex communication with lots of a priori
knowledge - and much more a posteriori to come... :)



Join to automatically receive all group messages.