Date   
Re: Help me AVHR pictures

David J Taylor
 

From: caucheteux.m@...

Hello be indulgent, be simple. I am a beginner, and I try to understand. but how do you visualize HVHR files images? example:
AVHR_AMV_2D_M01_20190308144003Z_20190308161903Z_N_O_20190308154458Z.nat

Thank you.

michel
===========================

Michel,

Welcome to the group!

"AMV" sounds like Air Motion Vector data, and Francis Breame had a BUFR Display program. However, ".NAT" sounds like Native format data rather than BUFR, so I don't know whether his program would handle it.

http://www.elnath.org.uk/

My own BUFR Viewer program would also work with BUFR format files.

https://www.satsignal.eu/software/bufr-viewer.html

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

Re: Help me AVHR pictures

caucheteux.m@...
 

Merci david 

bonne soirée.

Pinning IRQs to processor cores

Ernst Lobsiger
 

Dear All

In message #24395 Thorsten was talking about running the tc-cast-client(s)
on some specific processor core. Under GNU/Linux this can be achieved by
command taskset. I did some experiments without striking success. A more
promising approach is to assign some IRQs to specific processor cores. On
my 10 years old Fujitsu/Siemens PCs with Intel Core2 Duo processors this
seems to help considerably. Under GNU/Linux a cat /proc/interrupts tells
you the whole story. My TBS-6908 card uses interrupt 16 for the tbsecp3
bridge code and interrupt 28 for the NIC eth0. What I did is pin the TBS
card to CPU1 and the NIC to CPU0. This can be done at the command line by

echo 2 > /proc/irq/16/smp_affinity
echo 1 > /proc/irq/28/smp_affinity

But be sure to have no irqbalance service running on your GNU/Linux box.

Before I did so my TC receiver Ganymed always had some missed and (mostly)
recovered IP packets (especially HVS-2). This is a typical sign of lattency
and delay. By assigning the TBS interrupt to CPU1 chances are that the IRQ
code is still in some high level cache. Also the IRQ is assigned by hardware
and the Linux kernel is not involved. Now these lost and recovered IP packets
seem to be gone as well. RedHat has a lot of documentation about Linux tuning.

With modern multi core processors there should even be more possibilities.
I have also been pointed to a bash script, that does the job automagically.
I am still experimenting with that script and commenting the bash code.
This was done under Devuan ASCII GNU/Linux 2.0.0 with kernel 4.9.0-6-amd64.
People using EUMETCast routers might still benefit pinning their NIC IRQs.

Windows users should be able to do similar things by studying this URL

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority

As usual everything you do as root or admin is on your own risk and peril.

Ganymed is now running without RAM-Disk and is processing all S3A and S3B
OLCI EFR images. No missed and recovered packets since yesterday 18:000 UTC.
You should be able to reach Ganymed (and produce some eth0 traffic!) here:

http://185.74.120.175:83


Happy hacking
Ernst

Re: Pinning IRQs to processor cores

CrazyCat
 

Modern linux kernels have some problems with interrupt sheduling. 64-bit kernels most affected.

P.S. Some real-time kernels available, but possible problems with dvb driver rebuilding (because kernel headers patched).

20.03.2019, 11:34, "Ernst Lobsiger" <ernst.lobsiger@...>:

In message #24395 Thorsten was talking about running the tc-cast-client(s)
on some specific processor core. Under GNU/Linux this can be achieved by
command taskset. I did some experiments without striking success. A more
promising approach is to assign some IRQs to specific processor cores. On
my 10 years old Fujitsu/Siemens PCs with Intel Core2 Duo processors this
seems to help considerably. Under GNU/Linux a cat /proc/interrupts tells
you the whole story. My TBS-6908 card uses interrupt 16 for the tbsecp3
bridge code and interrupt 28 for the NIC eth0. What I did is pin the TBS
card to CPU1 and the NIC to CPU0. This can be done at the command line by

echo 2 > /proc/irq/16/smp_affinity
echo 1 > /proc/irq/28/smp_affinity

But be sure to have no irqbalance service running on your GNU/Linux box.

Re: Pinning IRQs to processor cores

Christian Peters
 

Ernst,

this sounds really interesting.
I think I cant' or have to check this running two USB TBS5925 boxes to improve the receiption!?

But my lost package ratio is suitable low now even without a Ramdisk on my system. Receiving problems mostly triggered by low SNR ratio and a 1m dish which I think at the low end for proper receiving both transponders with sufficient headroom.....
But every improvement is welcome.

Regards,

Christian

Am 20.03.19 um 10:33 schrieb Ernst Lobsiger:

Dear All

In message #24395 Thorsten was talking about running the tc-cast-client(s)
on some specific processor core. Under GNU/Linux this can be achieved by
command taskset. I did some experiments without striking success. A more
promising approach is to assign some IRQs to specific processor cores. On
my 10 years old Fujitsu/Siemens PCs with Intel Core2 Duo processors this
seems to help considerably. Under GNU/Linux a cat /proc/interrupts tells
you the whole story. My TBS-6908 card uses interrupt 16 for the tbsecp3
bridge code and interrupt 28 for the NIC eth0. What I did is pin the TBS
card to CPU1 and the NIC to CPU0. This can be done at the command line by

echo 2 > /proc/irq/16/smp_affinity
echo 1 > /proc/irq/28/smp_affinity

But be sure to have no irqbalance service running on your GNU/Linux box.

Before I did so my TC receiver Ganymed always had some missed and (mostly)
recovered IP packets (especially HVS-2). This is a typical sign of lattency
and delay. By assigning the TBS interrupt to CPU1 chances are that the IRQ
code is still in some high level cache. Also the IRQ is assigned by hardware
and the Linux kernel is not involved. Now these lost and recovered IP packets
seem to be gone as well. RedHat has a lot of documentation about Linux tuning.

With modern multi core processors there should even be more possibilities.
I have also been pointed to a bash script, that does the job automagically.
I am still experimenting with that script and commenting the bash code.
This was done under Devuan ASCII GNU/Linux 2.0.0 with kernel 4.9.0-6-amd64.
People using EUMETCast routers might still benefit pinning their NIC IRQs.

Windows users should be able to do similar things by studying this URL

https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority

As usual everything you do as root or admin is on your own risk and peril.

Ganymed is now running without RAM-Disk and is processing all S3A and S3B
OLCI EFR images. No missed and recovered packets since yesterday 18:000 UTC.
You should be able to reach Ganymed (and produce some eth0 traffic!) here:

http://185.74.120.175:83


Happy hacking
Ernst

Re: Pinning IRQs to processor cores

Ernst Lobsiger
 

Christian,

not sure this is any good for USB EUMETCast receiver systems like TBS5925/27. These AFAIK send the whole TS over the USB link. No idea how your /proc/interrupts looks like but you have a very good system Smaug indeed. My receiver Ganymed has not missed a single IP packet in all 3 EUMETCast services in the last 24 hours. See the improvement of HVS-2 below. For GNU/Linux users I attach the bash script I was talking about. It has been tested here for TBS6983, TBS6903, TBS6908 but it should also work for Digital Devices (DD) cards and most kinds of NICs. Feel free to use it at your own risk and peril.

Cheers,
Ernst

Re: Pinning IRQs to processor cores

Christian Peters
 

Ernst,

the graph is really very impressive as it shows clearly the IRQbalance could be the cause for reception problems!
Great you share the script here. For you info and others, my cat /proc/interrupts of a my Linux system with two USB5925 devices appended.

Regards,

Christian



Am 20.03.19 um 23:00 schrieb Ernst Lobsiger:

Christian,

not sure this is any good for USB EUMETCast receiver systems like TBS5925/27. These AFAIK send the whole TS over the USB link. No idea how your /proc/interrupts looks like but you have a very good system Smaug indeed. My receiver Ganymed has not missed a single IP packet in all 3 EUMETCast services in the last 24 hours. See the improvement of HVS-2 below. For GNU/Linux users I attach the bash script I was talking about. It has been tested here for TBS6983, TBS6903, TBS6908 but it should also work for Digital Devices (DD) cards and most kinds of NICs. Feel free to use it at your own risk and peril.

Cheers,
Ernst

Re: Pinning IRQs to processor cores

Ernst Lobsiger
 

Christian,

your /proc/interrupts looks very different from the one I had. It almost seems that CPU0 is dedicated to serve IR-PCI-MSI interrupts. What you clearly see is that the busiest interrupt is for xhci_hcd (most probably your USB 3.0 hub driver, try lsusb -v ¦ less or lsusb -t or even dmesg ¦ grep usb ¦ less). The second busiest is your NIC enp1s0. The script as distributed is harmless. It will just tell you what it intends to do. In the comments you see that you have to # uncomment one line at the bottom to let the script actually do what it wants. In your case the script will try to move and pin your NICs IRQ to CPU3. Whether this is a good idea or even possible I cannot know. In any case you should test first how the NICs smp_affinity is set right now by doing a cat /proc/irq/372/smp_affinity. This might give you a 1 or f (if the file exists!) and the script would try to set that to 8. You can always reset it with echo ? > to what it was before. You had a couple of lost HVS-2 IP packets with acceptable SNR recently. If this is not due to gusty winds (you had 2 days of fine reception before!) or if these losses systematically coincide with heavy NIC traffic you could give it a try. But it's up to you ("your risk and peril") and RTFM first.


Regards
Ernst

Re: Pinning IRQs to processor cores

Christian Peters
 

Ernst,

checking the affinity of enp1s0 gives an 'f'. I pinned enp1s0 to CPU3 now, let's see whether there is some positive effect.
There were no gusty winds in the night (checked with my weather station) so I think it could be caused by my increased network traffic as I changed my method of distributing (pushing as far as a file was closed on the HD of the receiver) the data to my processors/fileserver. And it will increase a little bit more as the change of the distributing method was not finished yet (still some data grabbed from the Win machine/MSG Data Manger straight from the receiver HD).

Btw.: irqbalance is not installed by default? here....so switching/binding the enp1s0 interrupts to another CPU I think is a good idea in any case.

Thanks for you advice and sharing it.

Regards,

Christian

Am 21.03.19 um 10:13 schrieb Ernst Lobsiger:

Christian,

your /proc/interrupts looks very different from the one I had. It almost seems that CPU0 is dedicated to serve IR-PCI-MSI interrupts. What you clearly see is that the busiest interrupt is for xhci_hcd (most probably your USB 3.0 hub driver, try lsusb -v ¦ less or lsusb -t or even dmesg ¦ grep usb ¦ less). The second busiest is your NIC enp1s0. The script as distributed is harmless. It will just tell you what it intends to do. In the comments you see that you have to # uncomment one line at the bottom to let the script actually do what it wants. In your case the script will try to move and pin your NICs IRQ to CPU3. Whether this is a good idea or even possible I cannot know. In any case you should test first how the NICs smp_affinity is set right now by doing a cat /proc/irq/372/smp_affinity. This might give you a 1 or f (if the file exists!) and the script would try to set that to 8. You can always reset it with echo ? > to what it was before. You had a couple of lost HVS-2 IP packets with acceptable SNR recently. If this is not due to gusty winds (you had 2 days of fine reception before!) or if these losses systematically coincide with heavy NIC traffic you could give it a try. But it's up to you ("your risk and peril") and RTFM first.


Regards
Ernst

Re: Pinning IRQs to processor cores

Ernst Lobsiger
 

Christian,

this was quick (... you are not known to be the faint of heart :-). Interesting you had smp_affinity (hex) f which means (dual) 1111 for your NICs IRQ. This means it was welcome on any core but still remained on CPU0. On my Core2 Duo I had smp_affinity (hex) 3 which means (dual) 11 and the NIC as well as the TBS card spread IRQs 50:50. Has your NIC interrupt really moved? A cat /proc/interrupts should now show a rising NIC IRQ counter under CPU3. Fingers crossed!

Cheers,
Ernst

Re: Pinning IRQs to processor cores

Christian Peters
 

Ernst,

yes, you are right...so let's do it....! :-D

Yes....it works and it moved-raising on CPU3.

            CPU0       CPU1       CPU2       CPU3
371:    1258902          0          0          0  IR-PCI-MSI 294912-edge      ahci[0000:00:12.0]
 372:  989304065          0          0    3748992  IR-PCI-MSI 524288-edge      enp1s0
 373:   10010936          0          0          0  IR-PCI-MSI 1572864-edge      ahci[0000:03:00.0]
 374: 2230357120          0          0          0  IR-PCI-MSI 344064-edge      xhci_hcd

Regards,

Christian

Am 21.03.19 um 11:29 schrieb Ernst Lobsiger:

Christian,

this was quick (... you are not known to be the faint of heart :-). Interesting you had smp_affinity (hex) f which means (dual) 1111 for your NICs IRQ. This means it was welcome on any core but still remained on CPU0. On my Core2 Duo I had smp_affinity (hex) 3 which means (dual) 11 and the NIC as well as the TBS card spread IRQs 50:50. Has your NIC interrupt really moved? A cat /proc/interrupts should now show a rising NIC IRQ counter under CPU3. Fingers crossed!

Cheers,
Ernst

Re: Pinning IRQs to processor cores

Ernst Lobsiger
 

Christian,

looking at Smaug's eLuna last day timeline it *seems* the packet loss on HVS-2 coincides with inbound NIC traffic.
Keep an eye on that. In any case you are running the NIC enp1s0 IRQ on CPU3 now. Happy to see it works so far ...

Cheers,
Ernst

Re: Geosatsignal V8.2.2.1142- no boundaries

Kobus Botha
 

I updated from V8.2.1 now to V8.2.2.
But no boundaries on my pictures.
I do have Countries.dat in the Geosatsignal file.
Please help.
Kobus Botha
South Africa

Re: Geosatsignal V8.2.2.1142- no boundaries

Herman Vijlbrief
 

Hi Kobus,

Please try Beta 8.2.3.1.1167.
This version works fine on my PC.

Regards,

Herman

Op 25-3-2019 om 16:54 schreef Kobus Botha:

I updated from V8.2.1 now to V8.2.2.
But no boundaries on my pictures.
I do have Countries.dat in the Geosatsignal file.
Please help.
Kobus Botha
South Africa

Re: Geosatsignal V8.2.2.1142- no boundaries

Kobus Botha
 

Thanks Herman- appreciated! Kobus

HD AWOL?

geojohnt@...
 

Dear All,

Er, I appear to have lost my E:\ data drive overnight.

I run 24/7 but when I switched the monitors on at 08:00 this morning all
running programmes [MDM  - 0 degrees, IODC, RSS, AVHRR, Animator,
Metop A, Metop B] had stopped running at 02:15 - 02:20.

TC was still showing a pink T.
And SR1 Console was still showing signal.

I closed all programmes and rebooted the computer and found all MSG
programme desktop icons 'white' - except HRPT Reader(?), RAMDISK 
and those that reside on C:\.

'This PC' shows no E:\ Data (HD) drive - as in attached screen shot.

Mmmmm?

Regards,
John Tellick.


HD AWOL?

geojohnt@...
 

Dear All,

Er, I appear to have lost my E:\ data drive overnight.

I run 24/7 but when I switched the monitors on at 08:00 this morning all
running programmes [MDM  - 0 degrees, IODC, RSS, AVHRR, Animator,
Metop A, Metop B] had stopped running at 02:15 - 02:20.

TC was still showing a pink T.
And SR1 Console was still showing signal.

I closed all programmes and rebooted the computer and found all MSG
programme desktop icons 'white' - except HRPT Reader(?), RAMDISK 
and those that reside on C:\.

'This PC' shows no E:\ Data (HD) drive - as in attached screen shot.

Mmmmm?

Regards,
John Tellick.


Re: HD AWOL?

David J Taylor
 

Dear All,

Er, I appear to have lost my E:\ data drive overnight.

I run 24/7 but when I switched the monitors on at 08:00 this morning all
running programmes [MDM - 0 degrees, IODC, RSS, AVHRR, Animator,
Metop A, Metop B] had stopped running at 02:15 - 02:20.

TC was still showing a pink T.
And SR1 Console was still showing signal.

I closed all programmes and rebooted the computer and found all MSG
programme desktop icons 'white' - except HRPT Reader(?), RAMDISK
and those that reside on C:\.

'This PC' shows no E:\ Data (HD) drive - as in attached screen shot.

Mmmmm?

Regards,
John Tellick.
=====================================

John,

It seems that your HRPT Reader was installed on C: - that's fine.

You might be able to get into the BIOS and see whether the HDD (E:) is listed. Perhaps a connector has fallen out? Worth opening the box to check.

I recently had a data disk fail which had been taking much of the HVS-1 and HVS-2 feeds and just saving the data - no processing. Since then I been cutting back on the data saved as far as possible on all PCs.

There's one utility you might try:

https://crystalmark.info/en/software/crystaldiskinfo/

which can show the basic health of an SSD or HDD.

Good luck!

David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv

Help menu

compu_friend
 

Hi all,

I am new to Wxtract.  So while seeing what it takes to make it go I cant find much if anything on the Help menu.
There are a lot of index items listed.  However when highlighted and pushing display , nothing happens.
Maybe I missed doing something during install or?  Anyway I need help finding help! :)

Gerry

Re: Help menu

David J Taylor
 

Hi all,

I am new to Wxtract. So while seeing what it takes to make it go I cant find much if anything on the Help menu.
There are a lot of index items listed. However when highlighted and pushing display , nothing happens.
Maybe I missed doing something during install or? Anyway I need help finding help! :)

Gerry
=================================

Gerry,

If you check the FAQ:

https://www.satsignal.eu/software/faq.htm

Q16 deals with this issue:

"For Windows-10, download, right-click unblock and expand this file, and right-click run the Install.cmd with administrative privilege."

https://www.satsignal.eu/software/WinHelpWin10.zip

Cheers,
David
--
SatSignal Software - Quality software for you
Web: http://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv