Date   
Re: I can not open FTP

David J Taylor
 

From: caucheteux.m@...

Flashfxp works perfectly I would like to download the files automatically.
=====================

.. and the FTPhelper should also work perfectly if you remove the Proxy entry, as I have already suggested.

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

Re: I can not open FTP

caucheteux.m@...
 

thanks sir Taylor , i will try to solve this problem later. thank you to everyone Eumetsat they are very pleasant. thank you for the keys and free access, and thank you for your software simple to understand.

New Data

Ian Deans
 

I see that the Metop C AVHRR wind data due to start yesterday 14/3/2019 on HVS-1 has clearly been delayed.

That means both lots of new data (Metop C and Sentinel 3B ) advised on the Weekly Report have not started and there is no word about the delay.

Regards
Ian.

Re: New Data

Graham Woolf
 

Hi Ian

I am getting data today - it did actually start yesterday.

Kind Regards

Graham

Re: New Data

Ian Deans
 

On 15/03/2019 12:06, Graham Woolf wrote:
Hi Ian
I am getting data today - it did actually start yesterday.
Kind Regards
Graham
====================================================================

Which data Graham, Sentinel3B Channel 4 or Metop C EPS 10 (HVS_1)

Regards
Ian.

Re: New Data

Graham Woolf
 

Hi Ian

I'm getting both - the METOP-C AVHHR Winds and also the Sentinel 3B SLSTR-L2 data

I did have to register for the METOP-C data though

Regards

Graham

Re: New Data

Ian Deans
 

On 15/03/2019 12:20, Graham Woolf wrote:
Hi Ian
I'm getting both - the METOP-C AVHHR Winds and also the Sentinel 3B SLSTR-L2 data
I did have to register for the METOP-C data though
Regards
Graham
=============================================================

Thanks for the update Graham.
I did request the Metop-C data via the Portal and had a acknowledgement from Debbie that the GRAS data was now available ( which I am receiving) and my EKU would be updated for the AVHRR wind data on 14/3/2019.

I will query this with Eumetsat.

Thanks for your help.
Ian.

Help me AVHR pictures

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
 
 

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