Topics

Originally Re: [MSG-1] SR1 Traffic dial. - now missed packets

geojohnt@...
 

David,

Thanks for your comments and the link to Arne's results.

I have to say that I've never monitored, as such, missed and recovered packets as I seldom appear to get missed data - as in gaps in images.
I have however over a long period of time noticed in TC HTML Statistics, figures for Missed Packets before FEC and FEC Recovered Packets.
The recovered packets rather few compared to the missed packets if I recall correctly.

But I don't think I was aware of 'image missed data.'

Of course when torrential rain/ice crystal clouds, cause link margin to drop below threshold, then that will cause lost data for that period and 'gaps in images.'

As you know I lost HVS-1 twice yesterday for short periods when its link margin dropped below threshold.

There is some wild weather on its way overnight so I've reset both TC HVS-1 and BS statistics -now, with sun and broken cloud, and SNR where it 'should be.'
I'll see how it goes.

Now, how relevant are the Bad Frame Count and Bad Packet Count figures on the SR1 readout - to all this?
Both of which are zero at the moment - whereas both TC HVS-1 and BS showed quite a lot of missed packets over the same operating period.

And what do they actually show?

Regards,
John

++++++++++++++++++++++++

In a message dated 27/09/2019 17:17:20 GMT Standard Time, gm8arv@... writes:

My
first thought would be to keep a regular check on missed & recovered
packets, and reset those statistics on a daily basis (we have automated
software which will do this).

Even in this delightful part of the world, when the weather is fair, and the
computers aren't overloaded, I can often get zero missed and zero recovered,
on BS, HVS-1 and HVS-2, Ayecka and TBS systems.  I do note though that with
the TBS software, it was only when I reverted to an earlier driver that I
got zeros, otherwise the missed and recovered counts were no-zero, but
matching.  You'll see that Arne's system is also in that state:

  http://home.hccnet.nl/a.van.belle/MRTG/tcstats-p1-tbs6983-hvs-2-tunerb.html

The monthly and yearly graphs show the base steady missed & recovered stream
best.

David J Taylor
 

David,

Thanks for your comments and the link to Arne's results.

I have to say that I've never monitored, as such, missed and recovered packets as I seldom appear to get missed data - as in gaps in images.
I have however over a long period of time noticed in TC HTML Statistics, figures for Missed Packets before FEC and FEC Recovered Packets.
The recovered packets rather few compared to the missed packets if I recall correctly.

But I don't think I was aware of 'image missed data.'

Of course when torrential rain/ice crystal clouds, cause link margin to drop below threshold, then that will cause lost data for that period and 'gaps in images.'

As you know I lost HVS-1 twice yesterday for short periods when its link margin dropped below threshold.

There is some wild weather on its way overnight so I've reset both TC HVS-1 and BS statistics -now, with sun and broken cloud, and SNR where it 'should be.'
I'll see how it goes.

Now, how relevant are the Bad Frame Count and Bad Packet Count figures on the SR1 readout - to all this?
Both of which are zero at the moment - whereas both TC HVS-1 and BS showed quite a lot of missed packets over the same operating period.

And what do they actually show?

Regards,
John
=========================

John,

For simplicity, just record the missed & recovered packets on a daily basis, and reset the statistics after noting the readings. On a good day, both should be zero.

If the bad DVB packets and frames are non-zero, that suggests there's an issue with the signal. If the DVB figures are zero, but you still have packet loss, that suggests there's a computer issue. By recording the times of the losses you may be able to judge what caused them.

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

Cornish Man
 

Hi

HVS-1 ans basic is always disconnecting for me  even in good weather

I sent an email to ERUMetCast and they said to send them the ini and log files.
I am awaiting for them to reply

J larkin

On Saturday, 28 September 2019, 16:10:50 BST, David J Taylor via Groups.Io <gm8arv@...> wrote:


David,

Thanks for your comments and the link to Arne's results.

I have to say that I've never monitored, as such, missed and recovered
packets as I seldom appear to get missed data - as in gaps in images.
I have however over a long period of time noticed in TC HTML Statistics,
figures for Missed Packets before FEC and FEC Recovered Packets.
The recovered packets rather few compared to the missed packets if I recall
correctly.

But I don't think I was aware of 'image missed data.'

Of course when torrential rain/ice crystal clouds, cause link margin to drop
below threshold, then that will cause lost data for that period and 'gaps in
images.'

As you know I lost HVS-1 twice yesterday for short periods when its link
margin dropped below threshold.

There is some wild weather on its way overnight so I've reset both TC HVS-1
and BS statistics -now, with sun and broken cloud, and SNR where it 'should
be.'
I'll see how it goes.

Now, how relevant are the Bad Frame Count and Bad Packet Count figures on
the SR1 readout - to all this?
Both of which are zero at the moment - whereas both TC HVS-1 and BS showed
quite a lot of missed packets over the same operating period.

And what do they actually show?

Regards,
John
=========================

John,

For simplicity, just record the missed & recovered packets on a daily basis,
and reset the statistics  after noting the readings.  On a good day, both
should be zero.

If the bad DVB packets and frames are non-zero, that suggests there's an
issue with the signal.  If the DVB figures are zero, but you still have
packet loss, that suggests there's a computer issue.  By recording the times
of the losses you may be able to judge what caused them.

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




geojohnt@...
 

David,

Thanks for that, interesting.
So, the SR1 figures relate to received signal 'quality' and the TC figures rather to computer data handling activity and workload?

I reset SR1 and both TC's 'packet figures' yesterday at 12:10 GMT knowing bad weather was on the way.
The rain down here started around 18:00 GMT and wasn't that heavy but continuous.
I checked the 'packet readouts' at 22:41 GMT and all were still 0.

When I got up at 07:30 GMT we had had some heavy rain overnight and my HVS-1 TC icon was red with SR1's SNR around 11.00 dB.
This went up to 12.0 + whilst sitting at the computer but the red HVS-1 icon didn't reset - which it does automatically when the LM is restored.

I opened HVS-1 HTML and saw that data was actually running - being shown on the graph.
And there was one Status error message from earlier.
Clicking reset, reset that and cleared the red TC icon.

So with data flowing despite the red task bar icon, the icon is slow to reset when the link margin rises above the threshold - it seems.
Or, I seem to recall, it remains red when a Status error message has been recorded.

This is a bit confusing(?), since a red TC task bar icon suggests lost lock and no data flowing?
It really needs another colour to inform of an error message warning?
Yellow for connecting, orange for message waiting, red for lost lock - no data throughput?

At 09:10 GMT I checked missed packets and HVS-1 showed Missed Packets 1611 - Recovered Packets 0.

BS showed Missed Packets 2114 - Recovered Packets 45.

SR1 showed Bad Frame Count 2226 - Bad Packet Counts 16942.

I then reset all at that time.

I think you are saying that if the computer is struggling with the amount of data/services it is having to deal with, TC will show lost/missed packets of data?
Does then low/er SNR - though above link margin threshold, also add to this loss?

I'm running a single PC system 24/7:
Intel i5-4690K CPU @ 3.50 GHz.
16 GB RA1.81 T HDD
Windows 10 Home
and no RAMDisk.

Programmes running: MSG-4 - + FSD, IODC, RSS, Animator, AVHRR Manager (NOAA-19, Metop A B C) Metop Manager B, Metop Manager C, GOES-16, GOES-17, HImarawi, and receive (store) Modis data - programme not running.

Task Manager appears to show my computer is not stressed - but of course I only look at that occasionally.
However, dare I say, your 'favourite' Anti Virus Software programme BullGuard 🙂 does kick in every now and again to do 'house cleaning,' optimisation and defraging - and goodness knows what else with the HDD working on this as well.

Regards,
John.

++++++++++++++++++++++++++++++++++++

In a message dated 28/09/2019 16:10:51 GMT Standard Time, gm8arv@... writes:

For simplicity, just record the missed & recovered packets on a daily basis,
and reset the statistics  after noting the readings.  On a good day, both
should be zero.

If the bad DVB packets and frames are non-zero, that suggests there's an
issue with the signal.  If the DVB figures are zero, but you still have
packet loss, that suggests there's a computer issue.  By recording the times
of the losses you may be able to judge what caused them.

David J Taylor
 

David,

Thanks for that, interesting.
So, the SR1 figures relate to received signal 'quality' and the TC figures rather to computer data handling activity and workload?

I reset SR1 and both TC's 'packet figures' yesterday at 12:10 GMT knowing bad weather was on the way.
The rain down here started around 18:00 GMT and wasn't that heavy but continuous.
I checked the 'packet readouts' at 22:41 GMT and all were still 0.

When I got up at 07:30 GMT we had had some heavy rain overnight and my HVS-1 TC icon was red with SR1's SNR around 11.00 dB
This went up to 12.0 + whilst sitting at the computer but the red HVS-1 icon didn't reset - which it does automatically when the LM is restored.

I opened HVS-1 HTML and saw that data was actually running - being shown on the graph.
And there was one Status error message from earlier.
Clicking reset, reset that and cleared the red TC icon.

So with data flowing despite the red task bar icon, the icon is slow to reset when the link margin rises above the threshold - it seems.
Or, I seem to recall, it remains red when a Status error message has been recorded.

This is a bit confusing(?), since a red TC task bar icon suggests lost lock and no data flowing?
It really needs another colour to inform of an error message warning?

Yellow for connecting, orange for message waiting, red for lost lock - no data throughput?

At 09:10 GMT I checked missed packets and HVS-1 showed Missed Packets 1611 - Recovered Packets 0.

BS showed Missed Packets 2114 - Recovered Packets 45

SR1 showed Bad Frame Count 2226 - Bad Packet Counts 16942.

I then reset all at that time.


I think you are saying that if the computer is struggling with the amount of data/services it is having to deal with, TC will show lost/missed packets of data?
Does then low/er SNR - though above link margin threshold, also add to this loss?

I'm running a single PC system 24/7:
Intel i5-4690K CPU @ 3.50 GHz.
16 GB RA1.81 T HDD
Windows 10 Home
and no RAMDisk.

Programmes running: MSG-4 - + FSD, IODC, RSS, Animator, AVHRR Manager (NOAA-19, Metop A B C) Metop Manager B, Metop Manager C, GOES-16, GOES-17, HImarawi, and receive (store) Modis data - programme not running.

Task Manager appears to show my computer is not stressed - but of course I only look at that occasionally.
However, dare I say, your 'favourite' Anti Virus Software programme BullGuard ???? does kick in every now and again to do 'house cleaning,' optimisation and defraging - and goodness knows what else with the HDD working on this as well.

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

John,

The red icon behaves differently in two circumstances:

- with signal loss and restoration the icon goes red and then clears.

- with some file errors the icon stays red, until you reset it. The error message gives a clue to the problem.

I think the present behaviour is satisfactory, once you know the above.

The missed/recovered packet count can be greater if the link margin is lower, yes, particularly if there are variations in the signal causing momentary drop-outs (wind is a cause in this location). The lower the link margin, the greater the chance of it being below the threshold.

Even with the perfect signal (well, 4 dB or greater steady link margin), if any PC activity causes the data stream to be interrupted, that can result in lost packets. Yes, virus scanners can cause this, so if the PC doesn't have any users, turn off the scanner, of if there's a keyboard someone can interact with stop the scanner looking at the EUMETCast directories. In the past, a RAMdisk has been shown to ameliorate this problem, but I'm not so sure these days with faster PCs and updates to TelliCast.

As I've mentioned many times before, automatic monitoring with e.g. MRTG can help you tie periods of loss to periods of high CPU, low memory, high network I/O, or scheduled malware scanning. Otherwise it's more guesswork.

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

geojohnt@...
 

David,

Thanks again for your further information.

Regarding the 'stuck' TC red icon issue, 'now I know.'
It seems the red icon may have misled me into thinking that I had 42 minutes of no HVS-1 reception.
Demonstrated another day by seeing data flowing on the HTML Shell graph whilst a red icon was showing.

Might be worth taking this up with EUMETSAT?

Regarding PC activity and missed packets, despite my PC being able to cope with its high processing demand from all your programmes running at the same time, I think I added to missed packets yesterday having been using HRPT Reader and GSS to process and display Metop and and MSG Hi-Res images - 'at the same time.'

Anyway, as I said earlier, I'm not aware of and image gaps so there is no problem.

>As I've mentioned many times before, automatic monitoring with e.g. MRTG can
>help you tie periods of loss to periods of high CPU, low memory, high
>network I/O, or scheduled malware scanning.  Otherwise it's more guesswork.

Indeed you have.

It would be an interesting exercise but since I'm not suffering image degradation, it's just another thing to set up.
And really, I guess, I don't need the EUMETCast computer connected to wifi 24/7 in which case I could turn off 'active' BullGuard scanning?
I only need Internet access on that computer to upgrade SatSignal programmes.
Oh, and importantly kepler updates.

Regards,
John.



In a message dated 29/09/2019 16:22:37 GMT Standard Time, gm8arv@... writes:


The red icon behaves differently in two circumstances:

- with signal loss and restoration the icon goes red and then clears.

- with some file errors the icon stays red, until you reset it.  The error
message gives a clue to the problem.

I think the present behaviour is satisfactory, once you know the above.

The missed/recovered packet count can be greater if the link margin is
lower, yes, particularly if there are variations in the signal causing
momentary drop-outs (wind is a cause in this location).  The lower the link
margin, the greater the chance of it being below the threshold.

Even with the perfect signal (well, 4 dB or greater steady link margin), if
any PC activity causes the data stream to be interrupted, that can result in
lost packets.  Yes, virus scanners can cause this, so if the PC doesn't have
any users, turn off the scanner, of if there's a keyboard someone can
interact with stop the scanner looking at the EUMETCast directories.  In the
past, a RAMdisk has been shown to ameliorate this problem, but I'm not so
sure these days with faster PCs and updates to TelliCast.

As I've mentioned many times before, automatic monitoring with e.g. MRTG can
help you tie periods of loss to periods of high CPU, low memory, high
network I/O, or scheduled malware scanning.  Otherwise it's more guesswork.

geojohnt@...
 

David,

Just to say I did quite a bit of opening MSG and GOES images in GSS, and Metop and AVHRR Manager images in HRPT Reader yesterday and none of these activities, creating extra HDD activity whilst still running all the Satsignal programmes, caused no lost packets on TC HVS-1 and BS.

And yesterday despite some rain at times, SNR didn't drop 'that much' and I've had no lost packets on TC in the last 24 hour period.
I suspect the 'dreaded' BullGuard when it periodically automatically optimises my computer - perhaps?

Alas I've 'done something to my PuTTY Telnet and it won't open now.
Not sure how to 'fix' it.

Rather annoying as we have thunder storms forecast for this area today with frequent lightning.
I'll need to keep my eye my SNR.

Regards,
John.

In a message dated 30/09/2019 10:33:52 GMT Standard Time, geojohnt@... writes:

Regarding PC activity and missed packets, despite my PC being able to cope with its high processing demand from all your programmes running at the same time, I think I added to missed packets yesterday having been using HRPT Reader and GSS to process and display Metop and and MSG Hi-Res images - 'at the same time.'