Date   
Re: not yet perfect, but...

David J Taylor
 

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

Cheers,

U.
Judging by your graphs, Ulrich, it seems you may have made an adjustment around 13:00 UTC.

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:

http://www.satsignal.eu/mrtg/performance_eumetcast-europe-packets.php

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.

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.

http://eumetmon.rummelecke.de/

The peaks at about 06:30 UTC and 12:55 UTC look to be due to a different activity.

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.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

Ulrich G. Kliegis
 

I'll add a www.-alias, nevertheless, to the server routing.
Ooops, not that easily feasible. So, no www.

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

Cheers,

U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Thu, 3 Mar 2011 10:55:00 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

I'm sure you meant:
http://eumetmon.rummelecke.de/
Sure!

I'll add a www.-alias, nevertheless, to the server routing.

Cheers,
U.

EnviHam File Browser

fbreame
 

Although not strictly a MSG topic, we may have some EnviHam (an experimental project for reception of EnviSat images similar to EUMETCast) users on this group, so this may be of interest.

As I mentioned on the GEO-Subscribers group recently, I've written a browser for EnviHam files, called, unimaginatively, EnviHamBrowser. This makes it quicker and easier to see their coverage, and then to select one or more to be opened in the ESA-supplied VISAT viewer. Unfortunately VISAT, although it does show coverage, is rather slow in opening files (at least on my setup).

EnviHamBrowser is available for download on my www site at

http://www.vf0123.btinternet.co.uk

together with its user guide, if anyone would like to try it. Please read the user guide for installation instructions.

(If you have already downloaded the original version 0.1.0, please update to the new version 0.1.1 which fixes a problem with incorrect views on images longer than 1 orbit.)

I haven't had the opportunity to test it on a lot of systems, so you will be doing a valuable beta test. Please let me know of any problems or comments.

Francis Breame

Re: re- cma

Alan Sewards
 

Geoffrey,

In your mail of 24 Feb, you gave your recv-channels.ini file and the relevant block is:

#METOP AVHRR Data channel EPS-10
[EPS-10]
target_directory=C:&#92;received&#92;EPS-10

In my opinion, this block is quite correct. The title line (there for humans) is commented with the #, so is ignored by the software. The crucial two lines required for the computer are present and correct. The only thing following from this is that you must look for incoming files in the folder C:&#92;received&#92;EPS-10, and NOT in the folder with the same name in the C:&#92;Program Files&#92;T Systems&#92;Business TV-IP tree.

Best regards - Alan S

On 03/03/2011 10:44 AM, Geoffrey Gee wrote:
Alan

In rec channels.ini the line Metop AVHRR is not commented . Is this
relevant to my troubles ?

No useful news from Eumetsat as yet..

Best Regards.....Geoffrey



------------------------------------

Unsure what a term means? Check the Glossary at:
http://www.satsignal.eu/wxsat/glossary.htm
Yahoo! Groups Links



--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

Re: not yet perfect, but...

David J Taylor
 

Just added FSY size and missed packets graphs. See
www.eumetmon.rummelecke.de
I just tried, and got: "Hier entsteht eine neue Internetpr�senz! ", but I'm sure you meant:
http://eumetmon.rummelecke.de/

I've added your packet loss (which should be much nearer zero, by the way).

Is there a simple and not too resources-hungry way to determine the free
space on the HDDs? I'd like to plot that too, if possible.

Cheers,
U.

(if you wonder what "rummelecke" is and don't find in your dictionary - that's
right. It is a family-idiom, standing for corners where unsorted items
sedimentate. My office is such a place...)
Danke!

There are some notes on disk space here:

http://www.satsignal.eu/mrtg/performance_howto.php#DiskSpace

and it's not really satisfactory. You can get the disk used, but not the percent used, and not the disk free. Even worse, the entries are an index into the disk table, and those entry numbers change if, for example, you plug in a USB memory stick. I've not found an easy way to do this in Perl (without add 3rd party modules), so I really should write a small Delphi program with takes one or two HD names as parameters (e.g. C: E:), and has an option to return percent used, percent free, MB used or MB free as the integer result. Maybe one day? Maybe someone else would write something?

I upload at 15 minute intervals - sort of consistent with Meteosat-9 scans, but the more frequent the better.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: re- cma

Hans-Joachim Empel
 

In rec.channels.ini the METOP AVHRR is EPS10.

My rec channels.ini looks like this :

[EPS-10]
target_directory=D : EPS-10
tmp_directory=D : received / tmp

Hope that helps

Regards from Germany
Joachim

----- Original Message -----
From: "Geoffrey Gee" <geogee@...>
To: <MSG-1@...>
Sent: Thursday, March 03, 2011 10:44 AM
Subject: Re: [MSG-1] re- cma


Alan
In rec channels.ini the line Metop AVHRR is not commented . Is this relevant to my troubles ?
No useful news from Eumetsat as yet..
Best Regards.....Geoffrey ------------------------------------
Unsure what a term means? Check the Glossary at: http://www.satsignal.eu/wxsat/glossary.htm
Yahoo! Groups Links

Re: re- cma

geoffreygee90
 

Alan

In rec channels.ini the line Metop AVHRR is not commented . Is this relevant to my troubles ?

No useful news from Eumetsat as yet..

Best Regards.....Geoffrey

Re: not yet perfect, but...

Ulrich G. Kliegis
 

I know that EUMETSAT do look at the
pages and take an interest in them.
I forgot to mention that I changed the upload interval from 20 to 10 mins. My
data seemed to lag a bit behind most others'.

Cheers,
U.

Re: not yet perfect, but...

Ulrich G. Kliegis
 

Many thanks for setting this up. I know that EUMETSAT do look at the
pages and take an interest in them.
Just added FSY size and missed packets graphs. See
www.eumetmon.rummelecke.de

Is there a simple and not too resources-hungry way to determine the free
space on the HDDs? I'd like to plot that too, if possible.

Cheers,
U.

(if you wonder what "rummelecke" is and don't find in your dictionary - that's
right. It is a family-idiom, standing for corners where unsorted items
sedimentate. My office is such a place...)

Re: re- cma

Alan Sewards
 

Duncan,
Line Metop AVHRR should be commented, like #Metop AVHRR
line NOAA 19 GAC should be commented, like #NOAA 19 GAC.

I'm not sure if it is obligatory, but I use a temp_directory= xxx line for each of the channels, where xxx is receiving&#92;tmp for those channels where your target directory is received, and receiving&#92;EPS-10 etc for the others. Also I don't know where these files are installed as you do not give the path - are your files in a root directory or in the Business TV-IP directory?

And finally, please punctuate your postings. They are difficult to read with no full stops and no paragraphing.

Best regards - Alan S

On 02/03/2011 5:26 PM, Duncan Edwards wrote:
Just as a precaution here is a copy of my recv-channels. As i only
receive a small portion of the data compaired to others i am wondering
as Ian said "my ramdisk is filling up fast" if i may after all this time
of recieving the data i may have something wrong here any comments would
be apreciated. Best Regards Duncan

recv-channels.ini - TelliCast+TelliVision Client channel configuration file
#
# 2-4-3 10-10-2005
#
[EUMETSAT Data Channel 1]
target_directory=received

[EUMETSAT Data Channel 2]
target_directory=received

[EUMETSAT Data Channel 3]
target_directory=received

[EUMETSAT Data Channel 4]
target_directory=received

[EUMETSAT Data Channel 11]
target_directory=received

Metop AVHRR
[EPS-10]
target_directory=received&#92;EPS-10

NOAA 19 GAC
[EPS-15]
target_directory=received&#92;EPS-15

# target_directory: Directory for received files. The target_directory name
# is relative to the current working directory.
# syntax: target_directory=<directory>
# default: received

tmp_directory=receiving/tmp/files
# tmp_directory: If this parameter is given tc-recv will internally
# store/compose all received files within the given directory and
# later move them to the target directory.
# While this option requires an additional move operation it
# guarantees that all files appearing in the target directory are
# fully written to the file system.
# syntax: tmp_directory=<directory>
# default: undefined=off, but default value may be redefined in
# recv.ini

# Section per channel or channel group identified by channel name (wildcard
# "*" allowed at end of name)

#activate_ftp_forwarding=1
# activate_ftp_forwarding: Will activate FTP forwarding for the correctly
# received files according to the recv.ini [ftp_forwarding]
# parameters.
# syntax: activate_ftp_forwarding=<value of range>
# range: 0/1
# default: 0=off

#tmp_directory=receiving/tmp/files
# tmp_directory: If this parameter is given tc-recv will internally
# store/compose all received files within the given directory and
# later move them to the target directory.
# While this option requires an additional move operation it
# guarantees that all files appearing in the target directory are
# fully written to the file system.
# syntax: tmp_directory=<directory>
# default: undefined=off, but default value may be redefined in
# recv.ini

#tmp_prefix=.
# tmp_prefix: Like tmp_directory, but files are composed within the final
# target directories but stored with the given prefix in front of
# the normal filenames until the files are fully written.
# syntax: tmp_prefix=<file name start>
# default: undefined=off, but default value may be redefined in
# recv.ini

#tmp_suffix=.tmp
# tmp_suffix: Like tmp_prefix, but adding a suffix to the normal filenames
# until the files are fully written.
# syntax: tmp_suffix=<file suffix>
# default: undefined=off, but default value may be redefined in
# recv.ini

--
Alan Sewards
email: alan@...
web site: http://asewards.free.fr

re- cma

duncan
 

Just as a precaution here is a copy of my recv-channels. As i only receive a small portion of the data compaired to others i am wondering as Ian said "my ramdisk is filling up fast" if i may after all this time of recieving the data i may have something wrong here any comments would be apreciated. Best Regards Duncan

recv-channels.ini - TelliCast+TelliVision Client channel configuration file
#
# 2-4-3 10-10-2005
#
[EUMETSAT Data Channel 1]
target_directory=received

[EUMETSAT Data Channel 2]
target_directory=received

[EUMETSAT Data Channel 3]
target_directory=received

[EUMETSAT Data Channel 4]
target_directory=received

[EUMETSAT Data Channel 11]
target_directory=received

Metop AVHRR
[EPS-10]
target_directory=received&#92;EPS-10

NOAA 19 GAC
[EPS-15]
target_directory=received&#92;EPS-15



# target_directory: Directory for received files. The target_directory name
# is relative to the current working directory.
# syntax: target_directory=<directory>
# default: received

tmp_directory=receiving/tmp/files
# tmp_directory: If this parameter is given tc-recv will internally
# store/compose all received files within the given directory and
# later move them to the target directory.
# While this option requires an additional move operation it
# guarantees that all files appearing in the target directory are
# fully written to the file system.
# syntax: tmp_directory=<directory>
# default: undefined=off, but default value may be redefined in
# recv.ini




# Section per channel or channel group identified by channel name (wildcard
# "*" allowed at end of name)

#activate_ftp_forwarding=1
# activate_ftp_forwarding: Will activate FTP forwarding for the correctly
# received files according to the recv.ini [ftp_forwarding]
# parameters.
# syntax: activate_ftp_forwarding=<value of range>
# range: 0/1
# default: 0=off

#tmp_directory=receiving/tmp/files
# tmp_directory: If this parameter is given tc-recv will internally
# store/compose all received files within the given directory and
# later move them to the target directory.
# While this option requires an additional move operation it
# guarantees that all files appearing in the target directory are
# fully written to the file system.
# syntax: tmp_directory=<directory>
# default: undefined=off, but default value may be redefined in
# recv.ini

#tmp_prefix=.
# tmp_prefix: Like tmp_directory, but files are composed within the final
# target directories but stored with the given prefix in front of
# the normal filenames until the files are fully written.
# syntax: tmp_prefix=<file name start>
# default: undefined=off, but default value may be redefined in
# recv.ini

#tmp_suffix=.tmp
# tmp_suffix: Like tmp_prefix, but adding a suffix to the normal filenames
# until the files are fully written.
# syntax: tmp_suffix=<file suffix>
# default: undefined=off, but default value may be redefined in
# recv.ini

re- cma

duncan
 

Ian Thanks for the quick reoply.I have set the ramdisk to 3100000. i had set it far to high at 320 so i guess this may cure it The ramdisk is still set at 299mb i have been runing since the lat reset at 3pm and it is now 4 pm the ramdisk shows 258 free of 299 so wee will see i dont think i have done anything out of the normal i like i say asked to have the CMA this morning so i could recieve the FY-2E data and it is working all ok it seems for now . I have never had this before Ian it was a pretty task bar. I will keep an eye on it all i have done is put the [EUMETSAT Data Channel 11]
target_directory=received
in my recv- channels . Thanks again Regards Duncan

Re: cma

Ian Deans
 

Duncan, if you have a RAMdisk of 299 Mb your file_database_size should be no more than 313 Mb and preferably between 310 and 313 Mb.

If your file_database_size is larger than your RAMdisk it will likely shutdown Tellique for a few seconds and start the RAMdisk full again and that will cause some losses. The size of your RAMdisk is actually 299 x 1024 divided by 1000 twice which equals 313.52 Mb.

However more of a worry is why your RAMdisk is being used up so quickly and you really need to find the reason for this.

Hope that helps.

Regards
Ian.

-----Original Message-----
From: Duncan Edwards
Sent: Wednesday, March 02, 2011 3:15 PM
To: MSG-1@...
Subject: [MSG-1] cma

Hi From this morning i have just started to recieve CMA and all was well for a couple of hours with no problems until i came back to the pc and noticed that i had a string of red Ts and one pink T all data had stopped so i looked at the ramdisc which i have set at 299mb and it had 260mb left so was not full .i dont know if i have set the file_database_size correct maybe this is the problem i would apreciate the size i need to set if possible.If i take out
[EUMETSAT Data Channel 11]all runs ok again any ideas would be apreciated Best Regards Duncan

cma

duncan
 

Hi From this morning i have just started to recieve CMA and all was well for a couple of hours with no problems until i came back to the pc and noticed that i had a string of red Ts and one pink T all data had stopped so i looked at the ramdisc which i have set at 299mb and it had 260mb left so was not full .i dont know if i have set the file_database_size correct maybe this is the problem i would apreciate the size i need to set if possible.If i take out
[EUMETSAT Data Channel 11]all runs ok again any ideas would be apreciated Best Regards Duncan

Re: not yet perfect, but...

James Brown
 

In message <DC907E03EB364CD0A76FC62CDA375CA7@narvik>, David J Taylor <gm8arv@...> writes
David - I notice on your monitoring page there is the option for WX data
if there is a home weather station - if you wish you could add the one
below to the Porthcawl one - it is updated every 10 minutes and runs
24/7.

Cheers

James

http://www.meteosat.co.uk/Porthcawl/
Added - ISS pass due now!

Cheers,
David
Thanks David - 8 octa's of cloud here :-((

I've also changed the MRTG to read bytes now as per your suggestion .

Thanks again,

James
--
James Brown

Re: not yet perfect, but...

David J Taylor
 

David - I notice on your monitoring page there is the option for WX data
if there is a home weather station - if you wish you could add the one
below to the Porthcawl one - it is updated every 10 minutes and runs
24/7.

Cheers

James

http://www.meteosat.co.uk/Porthcawl/
Added - ISS pass due now!

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...

Re: not yet perfect, but...

James Brown
 

I can see that I must update your location, as
you've now given it more accurately on the page:
David - I notice on your monitoring page there is the option for WX data if there is a home weather station - if you wish you could add the one below to the Porthcawl one - it is updated every 10 minutes and runs 24/7.

Cheers

James

http://www.meteosat.co.uk/Porthcawl/

--
James Brown

Re: not yet perfect, but...

Ulrich G. Kliegis
 

An: <MSG-1@...>
Von: "David J Taylor" <gm8arv@...>
Datum: Tue, 1 Mar 2011 14:18:23 -0000
Betreff: Re: [MSG-1] not yet perfect, but...
Antwort an: MSG-1@...

Many thanks for setting this up. I know that EUMETSAT do look at the
pages and take an interest in them.
Glad to be able to feed them something back ;)

It's rewarding to see that something like that can be accomplished and
finished in a few days. If one considers the involved technology down to the
transistor level - surprising that it works, somehow miraculous.

Thanks again for your assistance, and - hey folks, it's fun, we might like to
see some more greens growing.

Cheers,
U.

Re: not yet perfect, but...

David J Taylor
 

Set back to bytes / s.
I think the bits/ s was imported from the helpful cfg example I received from
where the other bit-pit is still visible -
Yes, I noticed! <G>

I also purged the ytics=3 in the dvb-section but it stayed like it is.

Cheers,
U.
The 3-ticks has gone in most of the graphs, but the yearly graph is only updated once a day, unless you delete the PNG files, and restart MRTG or wait for its next run. I can see that I must update your location, as you've now given it more accurately on the page:

http://eumetmon.rummelecke.de/windbuedel_dvb.html

Many thanks for setting this up. I know that EUMETSAT do look at the pages and take an interest in them.

Cheers,
David
--
SatSignal software - quality software written to your requirements
Web: http://www.satsignal.eu
Email: david-taylor@...