Topics

TelliCast Missed Packets False Alarms


Ernst Lobsiger
 

Dear All

A couple of us do make regular plots of missed or missed/recovered
Tellicast IP packets. Plots are mostly done with MRTG some are using
RRDTool. Under GNU/Linux I use a bash script that picks the values
from the TC clients WEB interface (statistics page). I assume this
is done in a similar way under Windows, though I did not find the
script used. Today I observed that my script seems to make rare
false alarms. I had a couple of BASIC missed packets on one receiver
while all 3 other receivers did not show this. More interesting the
WEB interface of the receiver with this false alarm still showed
0/0 missed/recovered packets. I checked Christian Peters receiver
Ancalagon that perfectly works with an older SkyStar 2 eXpress HD
and this receiver showed exactly the same pattern: Missed packets
at 07:50 but nothing missed in the packet statistics that is updated
every 30 minutes by our script "TelliCastStatsCollector" (thanks Arne).
I also checked the TC clients log file and found absolutely nothing.

Looking at David's MRTG page I see a similar effect. Some stations
show this BASIC missed packets event, others don't. The TC clients
statistics page is updated every few seconds. Could this be a problem
of the script reading the page (maybe with error) while it is updated?

http://www.satsignal.eu/mrtg/performance_eumetcast-europe_losses.php

I remember to have seen the effect at least once before but didn't
pay much attention to it. How frequent is this effect? Any other ideas?
What is the script normally used under Windows to get these values?


Best regards
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Dear All
[]
Looking at David's MRTG page I see a similar effect. Some stations
show this BASIC missed packets event, others don't. The TC clients
statistics page is updated every few seconds. Could this be a problem
of the script reading the page (maybe with error) while it is updated?

http://www.satsignal.eu/mrtg/performance_eumetcast-europe_losses.php

I remember to have seen the effect at least once before but didn't
pay much attention to it. How frequent is this effect? Any other ideas?
What is the script normally used under Windows to get these values?


Best regards
Ernst
===============================

Ernst,

I just checked my TelliCastStats program and it reads the whole "Statistics" Web page at once and then parses it for the required strings. However there could be some missed that were corrected until the next run of the program, so there is a chance for error there.

In the statistics I publish, though, there counters are reset to zero at the end of the day, and the values of missed and recovered are typically equal before the reset. I'm coming to the conclusion that it /might/ be the TBS driver or BDADataEx software, as the same PC (Penguin) fed from am Ayecka SR1 over an add-in network card produced zero missed and zero recovered. Same eToken & TelliCast version (2.14.6) etc. etc.

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


Ernst Lobsiger
 

David

Your receivers Alta and Harstad clearly show the "Missed Packets Event" from 07:50 UTC (while Penguin does not).
"TelliCastStatsCollector" typically updates/adds one line every half hour. What do you see in the respective statistics
files of Alta and Harstad? If there is no increase of missed, recovered and lost packets between 07:29 and 07:59
this would mean that you see exactly the same thing as I see here on Terra and on Christian's Ancalagon. Yes
there is a chance that Missed and Recovered are not updated at the same page update. But what I see here is
that Missed and Recovered are still 0 and yours probabaly did not change from what you have had since 02:59?

Cheers
Ernst

P.S. I doubt that this has anything to do with drivers as I use a recent TBS and Christian has and older Technisat.


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Your receivers Alta and Harstad clearly show the "Missed Packets Event" from 07:50 UTC (while Penguin does not).
"TelliCastStatsCollector" typically updates/adds one line every half hour. What do you see in the respective statistics
files of Alta and Harstad? If there is no increase of missed, recovered and lost packets between 07:29 and 07:59
this would mean that you see exactly the same thing as I see here on Terra and on Christian's Ancalagon. Yes
there is a chance that Missed and Recovered are not updated at the same page update. But what I see here is
that Missed and Recovered are still 0 and yours probabaly did not change from what you have had since 02:59?

Cheers
Ernst

P.S. I doubt that this has anything to do with drivers as I use a recent TBS and Christian has and older Technisat.
======================================

Ernst,

When I see events like that I look for other stations and for the 07:50 it's clearly spread across many receivers in Europe, so I believe it so be quite genuine, and not some artefact of timing. There's another event around 09:10, and pairs of events like this are typically associated with uplink stations swaps. The 07:50 shows a signal level drop at several stations - particularly Thorsten and Hartmut. For some time I have suspected that the AGC response of the TBS receivers is faster than the Ayecka, so a quick drop in signal could cause more losses in the Ayecka.

Penguin is TBS (faster response vs. steady losses) and Alta and Harstad are a single Ayecka with a 5-port 1Gbps hub. I chose the TBS5927 as the most recent TBS I had to hand. I should swap it with the 5925 which didn't give the missed/recovered when used on a less powerful PC (now a file store).

Statistics below show a genuine loss.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
TelliCast statistics for Alta using Ayecka SR 1 #1 on Basic Service
YYYY-MM-DD hh:mm Recov. Missed Bytes Packets
UTC Packets Packets Received Received
2020-09-14 00:29 0 0 1694911450 1456883
2020-09-14 00:59 0 0 3266029928 2807497
2020-09-14 01:29 0 0 5142555963 4418903
2020-09-14 01:59 0 0 6652508331 5715263
2020-09-14 02:29 0 0 8468076371 7276117
2020-09-14 02:59 0 0 9974067753 8569162
2020-09-14 03:29 0 0 11381370119 9779593
2020-09-14 03:59 0 0 12953323892 11131402
2020-09-14 04:29 0 0 14431665034 12402065
2020-09-14 04:59 0 0 16303606439 14008333
2020-09-14 05:29 0 0 17632880915 15152058
2020-09-14 05:59 0 0 19477360185 16736827
2020-09-14 06:29 0 0 21413373662 18398791
2020-09-14 06:59 0 0 22794798271 19585498
2020-09-14 07:29 0 0 24904048183 21397799
2020-09-14 07:59 5 78 26698937421 22937739
2020-09-14 08:29 5 78 28312265715 24323993
2020-09-14 08:59 5 78 30417799884 26132284
2020-09-14 09:29 24 176 32506523503 27926928
2020-09-14 09:59 24 176 35082944291 30135178
2020-09-14 10:29 24 176 36716034405 31538215
2020-09-14 10:59 24 176 39103714366 33584918
2020-09-14 11:29 24 176 41379720319 35538339
2020-09-14 11:59 24 176 42880593701 36826902
2020-09-14 12:29 24 176 44956290445 38608543
2020-09-14 12:59 24 176 47429640438 40729854
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I might also account for differences between stations by the different selection of data channels they chose to receive. Fewer or different UDP connections happening!

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


Ernst Lobsiger
 

David

Sorry my interpretation of the Alta plot was wrong. I was taking the losses you had yesterday early morning
for today morning. So your output of "TelliCastStatsCollector" for Alta is what should be expected. It clearly
shows the jump shortly befor 08:00 that can also be seen in the MRTG plot. And YES this is a hickup seen
all over Europe and you are right that stations might not see it because of their different channel selection.

But this does not resolve or explain my problem:

1) All my 4 receivers have identical channel selection but only Terra has seen the even in the eLuna graph.
2) None of the 4 receivers has seen the 07:50 event in the cumulative "TelliCastStatsCollector" output file.
3) Christian Peters has seen exactly the same strange bahaviour on Ancalagon that I see here on Terra.

TelliCastStatsCollector outputs from today (plots have been attached at the first post of the thread):

--------------------------------------------------------------------------------
TelliCastStatsCollector_0   (A script for GNU/Linux)                 Version 1.1
(c) David Taylor, Arne van Belle, and Ernst Lobsiger                 License GPL

HOST: terra
RECV: Quad Inverto Black Ultra, TBS-6903X V2 + 22uF, TelliCast client(s)  2.14.7
DESC: Receives BAS + HVS-1 + HVS-2 using a single LNB cable    (BAS stats shown)
--------------------------------------------------------------------------------
YearMonDay   -UTC-    Missed    Recov.      Lost      Received          Received
YYYY-MM-DD   hh:mm   Packets   Packets   Packets       Packets             Bytes
2020-09-14   00:29         0         0         0     1'043'779     1'218'611'135
2020-09-14   00:59         0         0         0     1'865'374     2'177'387'679
2020-09-14   01:29         0         0         0     2'817'145     3'288'413'332
2020-09-14   01:59         0         0         0     3'708'243     4'328'800'372
2020-09-14   02:29         0         0         0     4'826'564     5'634'922'354
2020-09-14   02:59         0         0         0     5'709'300     6'665'412'798
2020-09-14   03:29         0         0         0     6'579'318     7'680'698'882
2020-09-14   03:59         0         0         0     7'498'968     8'754'342'013
2020-09-14   04:29         0         0         0     8'363'918     9'763'886'580
2020-09-14   04:59         0         0         0     9'608'286    11'217'646'769
2020-09-14   05:29         0         0         0    10'357'582    12'091'441'267
2020-09-14   05:59         0         0         0    11'481'347    13'404'065'405
2020-09-14   06:29         0         0         0    12'693'048    14'819'622'799
2020-09-14   06:59         0         0         0    13'494'975    15'755'570'696
2020-09-14   07:29         0         0         0    14'793'577    17'272'532'428
2020-09-14   07:59         0         0         0    15'884'019    18'546'015'532
2020-09-14   08:29         0         0         0    16'853'594    19'677'643'258
2020-09-14   08:59         0         0         0    18'080'869    21'111'452'146
2020-09-14   09:29         0         0         0    19'202'724    22'421'229'930
2020-09-14   09:59         0         0         0    20'501'049    23'938'551'072
2020-09-14   10:29         0         0         0    21'409'451    24'998'841'248
2020-09-14   10:59         0         0         0    22'870'628    26'707'208'545
2020-09-14   11:29         0         0         0    24'321'310    28'402'840'570
2020-09-14   11:59         0         0         0    25'160'730    29'382'749'087
2020-09-14   12:29         0         0         0    26'499'225    30'946'232'612
2020-09-14   12:59         0         0         0    28'094'135    32'811'753'487
2020-09-14   13:29         0         0         0    29'150'829    34'045'559'296
And that's what Christian Peters got in Germany:

--------------------------------------------------------------------------------
TelliCastStatsCollector.sh  (A script for GNU/Linux)                 Version 1.0
(c) David Taylor, Arne van Belle, and Ernst Lobsiger                 License GPL

HOST: ancalagon
RECV: Inverto Black Ultra LNB, SKYSTAR 2 HD, TelliCast client(s) 2.14.7 ALPHA 1
DESC: Receives BS+ does image processing ...      (BS stats shown)
--------------------------------------------------------------------------------
YearMonDay   -UTC-    Missed    Recov.      Lost      Received          Received
YYYY-MM-DD   hh:mm   Packets   Packets   Packets       Packets             Bytes
2020-09-14   00:29         0         0         0     1'051'090     1'227'334'142
2020-09-14   00:59         0         0         0     1'901'876     2'220'304'879
2020-09-14   01:29         0         0         0     2'899'539     3'385'237'180
2020-09-14   01:59         0         0         0     3'787'944     4'422'607'635
2020-09-14   02:29         0         0         0     4'942'235     5'770'941'848
2020-09-14   02:59         0         0         0     5'872'905     6'857'666'586
2020-09-14   03:29         0         0         0     6'740'958     7'870'765'150
2020-09-14   03:59         0         0         0     7'667'971     8'953'200'506
2020-09-14   04:29         0         0         0     8'567'436    10'003'136'114
2020-09-14   04:59         0         0         0     9'835'906    11'485'217'661
2020-09-14   05:29         0         0         0    10'579'834    12'352'937'849
2020-09-14   05:59         0         0         0    11'741'757    13'710'328'069
2020-09-14   06:29         0         0         0    12'987'806    15'166'136'364
2020-09-14   06:59         0         0         0    13'784'921    16'096'641'451
2020-09-14   07:29         0         0         0    15'108'845    17'643'465'989
2020-09-14   07:59         0         0         0    16'246'422    18'972'118'399
2020-09-14   08:29         0         0         0    17'241'766    20'134'010'740
2020-09-14   08:59         0         0         0    18'461'761    21'559'584'884
2020-09-14   09:29         0         0         0    19'637'085    22'932'084'121
2020-09-14   09:59         0         0         0    20'975'525    24'496'528'383
2020-09-14   10:29         0         0         0    21'884'262    25'557'428'732
2020-09-14   10:59         0         0         0    23'389'786    27'317'971'286
2020-09-14   11:29         0         0         0    24'870'986    29'049'427'085
2020-09-14   11:59         0         0         0    25'737'011    30'060'698'446
2020-09-14   12:29         0         0         0    27'086'614    31'637'401'209
2020-09-14   12:59         0         0         0    28'734'347    33'564'763'511
2020-09-14   13:29         0         0         0    29'820'024    34'832'775'251


Best regards
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Sorry my interpretation of the Alta plot was wrong. I was taking the losses you had yesterday early morning
for today morning. So your output of "TelliCastStatsCollector" for Alta is what should be expected. It clearly
shows the jump shortly befor 08:00 that can also be seen in the MRTG plot. And YES this is a hickup seen
all over Europe and you are right that stations might not see it because of their different channel selection.

But this does not resolve or explain my problem:

1) All my 4 receivers have identical channel selection but only Terra has seen the even in the eLuna graph.
2) None of the 4 receivers has seen the 07:50 event in the cumulative "TelliCastStatsCollector" output file.
3) Christian Peters has seen exactly the same strange bahaviour on Ancalagon that I see here on Terra.
[]

Best regards
Ernst
========================================

No problem with the interpretation of Alta. That PC is due for retirement and I may be abusing it in the period up to switch-off (hammering the HD etc. as I intend to make it a virtual machine).

If the uplink switch this morning did cause a brief outage, it's possible that the different receivers will have a different response to that uplink switch (including lock-up time), and hence some may see nothing, some missed and recovered, and some lost. Can you correlate the observations with receiver type?

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


Ernst Lobsiger
 

David

As I said before this is not a driver problem which also means it's not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m while under Windows IIRC
you  use wget to dump this page (do you?).

If these scripts work correctly then 07:50 and 07:55 there must have been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again missed/recovered = 0/0 on the same page.

Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and 07:59                 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow filled lost packets in the rrd DB.

Regards
Ernst




David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

As I said before this is not a driver problem which also means it's not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m while under Windows IIRC
you use wget to dump this page (do you?).

If these scripts work correctly then 07:50 and 07:55 there must have been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again missed/recovered = 0/0 on the same page.

Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and 07:59 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow filled lost packets in the rrd DB.

Regards
Ernst
====================================

Ernst,

Well it appears to be a driver or receiver problem as with the same Windows-10/64 PC no missed packets with a networked Ayecka RX, continuous missed/recovered with a TBS5927/BDADataEx. Different receiver chip?

Under Windows I use my own software to retrieve the statistics page, not wget. URL:

url := 'http://' + node + '/www/tsl/receiver/tsl_receiver_statistics.html';

where node includes the port number.

I can certainly see that there is a time window where a small number of errors might be corrected between one reporting interval and the next, but I imagine that to be within a few packets, so likely well under a millisecond. Yes, we should check that out! But I don't recall ever seeing the count being reset to zero. Missed and recovered being equal and non-zero, yes. But never going backwards.

Perhaps the Linux variant of TelliCast behaves differently? Seems unlikely!

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


Ernst Lobsiger
 

David

Your problem with the TBS5927 most probably is a driver problem. But here it's not.

What I remember to have seen is that we get missed packets that are shown recovered
with the next update of the TelliCast client statistics page (approximately 3s later).

What I cannot know or even simulate is: What happens if my script unsing the w3m browser
accesses the statistics page exactly when it's updating? Even java script is involved!

Regards
Ernst


Am 14.09.2020 21:09, schrieb David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 via groups.io:

David
As I said before this is not a driver problem which also means it's
not receiver dependant. I have two
receivers that use the stiid135 chip and only one receiver has had the
problem. Christian uses an old
stv0903 chip. The only coincidence is that Christian uses my scripts
and that both of us also use ntp.
The statistics page is dumped and then analized with textbrowser w3m
while under Windows IIRC
you use wget to dump this page (do you?).
If these scripts work correctly then 07:50 and 07:55 there must have
been some missed and not recovered
= lost packets while 07:59 "TelliCastStatsCollector" found again
missed/recovered = 0/0 on the same page.
Two rather unlikely explanations come to mind:
a) The client (auto) reseted the statistics page between 07:55 and
07:59 (Terra still has 0/0 now)
b) The eLuna update script 07:50 and 07:55 ended in error that somehow
filled lost packets in the rrd DB.
Regards
Ernst
====================================
Ernst,
Well it appears to be a driver or receiver problem as with the same
Windows-10/64 PC no missed packets with a networked Ayecka RX,
continuous missed/recovered with a TBS5927/BDADataEx. Different
receiver chip?
Under Windows I use my own software to retrieve the statistics page,
not wget. URL:
url := 'http://' + node + '/www/tsl/receiver/tsl_receiver_statistics.html';
where node includes the port number.
I can certainly see that there is a time window where a small number
of errors might be corrected between one reporting interval and the
next, but I imagine that to be within a few packets, so likely well
under a millisecond. Yes, we should check that out! But I don't
recall ever seeing the count being reset to zero. Missed and
recovered being equal and non-zero, yes. But never going backwards.
Perhaps the Linux variant of TelliCast behaves differently? Seems unlikely!
Cheers,
David
--
SatSignal Software - Quality software for you
Web: https://www.satsignal.eu
Email: david-taylor@...
Twitter: @gm8arv


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Your problem with the TBS5927 most probably is a driver problem. But
here it's not.

What I remember to have seen is that we get missed packets that are
shown recovered
with the next update of the TelliCast client statistics page
(approximately 3s later).

What I cannot know or even simulate is: What happens if my script unsing
the w3m browser
accesses the statistics page exactly when it's updating? Even java
script is involved!

Regards
Ernst
================================

Ernst,

Well, I'm using the latest TBS driver for the TBS5927, so what to make of that! I suspect others are simply not monitoring to the same level, and/or simply accepting the issue.

I don't think there's much you can do about the "time to correct" issue - it's fundamental to the way the error correction works, isn't it? The correction may not be possible until the next buffer of information is received, so that brings in USB polling, network buffer and PCIe buffer size, depending on the receiver architecture.

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


Ernst Lobsiger
 

David

TBH I have no idea concerning EUMETCast USB devices. AFAIK the whole TS is sent to the PC over the USB cable.
Several users seem to have acceptable even good results with the TBS5925 (same ST chip stv0900 AAC as in SR1).
What I do know is PCIe cards with ECP3 bridges. I have fixed the OS ECP3 code for missed interrupts and added a
buffer size that can be selected for up to 8 transponders with CrazyCat. All modern PCIe cards use the ECP3 bridge.

EUMETSAT has added a minimum traffic to T2 to resolve the PCIe buffer delay problem from the dissemination side.
AFAIK there is no such thing on T1 for HVS-1. That means you still cannot receive HVS-1 alone using a MODCOD
filter. You always need BASIC to keep the PCIe buffers busy. So at least for PCIe cards "time to correct" is no issue.

Cheers,
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

TBH I have no idea concerning EUMETCast USB devices. AFAIK the whole TS is sent to the PC over the USB cable.
Several users seem to have acceptable even good results with the TBS5925 (same ST chip stv0900 AAC as in SR1).
What I do know is PCIe cards with ECP3 bridges. I have fixed the OS ECP3 code for missed interrupts and added a
buffer size that can be selected for up to 8 transponders with CrazyCat. All modern PCIe cards use the ECP3 bridge.

EUMETSAT has added a minimum traffic to T2 to resolve the PCIe buffer delay problem from the dissemination side.
AFAIK there is no such thing on T1 for HVS-1. That means you still cannot receive HVS-1 alone using a MODCOD
filter. You always need BASIC to keep the PCIe buffers busy. So at least for PCIe cards "time to correct" is no issue.

Cheers,
Ernst
=====================================

Thanks for those details, Ernst.

USB is strange in that it's a polling system (1 kHz rate for USB 2, IIRC), but clearly good enough to keep "CD quality" audio running without breaks. With 55 Mbps TS rate - who knows!

I do receive HVS-1 alone on an Ayecka SR1 with MODCOD selection, but of course that's with a UDP link and network devices, not PCIe. On my PC Lund (TBS6903/BDADataEx) it does take HVS-1 only, using MODCOD "All", but no TelliCast running for the BAS PIDs. Works with zero packet loss when the signal level is sufficiently high and stable.

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


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

Progress report.

I've been trying to resolve the steady missed/recovered TelliCast packets issue on PC Penguin, and I did further tests yesterday and today but without success so far.

- Adding a RAMdisk (tmp and received)

- changing to a TBS5925 (from TBS5927)

- and moving to a USB 3 port (from USB 2) have all made no difference.

Items left in common: BDADataEx (but that works correctly with the TBS6903 PCIe card running BAS, HVS-1 and HVS-2, and with an earlier PC with a TBS5925 USB receiver plugged into a separate USB3 card). TelliCast was 2.14.5 on the old PC, 2.14.6 on the new. I'm reluctant to revert TelliCast, or the TBS5927, as they are units which the new user would be using.

It seems that the new PC has a single main USB hub internally on the motherboard, so perhaps there's a parameter I can tune there? If so, I couldn't see one Perhaps adding a low-profile PCIe USB 2 card could be an option giving two top-level hubs, such cards seem to be no longer available! I am trying to avoid USB 3.0 cards as they require extra power connectors.

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


Ernst Lobsiger
 

David

Running out of other options: Have you tried to disable C-States in the BIOS (if possible at all)?
Christian recently had this deja vue with a Technisat SkyStar2 eXpress HD card on his Ancalagon.

Regards
Ernst


David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺
 

David

Running out of other options: Have you tried to disable C-States in the BIOS (if possible at all)?
Christian recently had this deja vue with a Technisat SkyStar2 eXpress HD card on his Ancalagon.

Regards
Ernst
=================================

Thanks, Ernst. No, I've not tried at. I see 13 C-states listed here:

https://www.dell.com/support/article/en-uk/qna41893/what-is-the-c-state?lang=en

Were you thinking of any particular one?

What was Christian's problem exactly? Perhaps there is a message reference?

I wish I knew the time that it takes for a missed packet to be recovered. USB devices are polled every millisecond, so perhaps if the device isn't polled sufficiently frequently that's the missed packet, and on the next poll there's enough to recover the packet. Perhaps the USB is too busy? Why do we only see this on direct PCie and USB devices, and even then only on /some/ systems. I've never seen this on network-connected receivers where the MTU is about three times bigger (1500 bytes) than what I've seen quoted for USB 2 (500 bytes).

Back of envelope sum: USB practical max, say 240 Mbps, 30 MBps, 1 millisecond polling => 30 kB per poll. EUMETCast Basic Service 55 Mbps, well under 240 Mbps. Doesn't help!

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


Ernst Lobsiger
 

David

Christian had lots of missed and recovered packets, see here:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=c&time1=2020-09-06+20%3A00&time2=2020-09-07+15%3A00

Now with C-States turned off in the BIOS it looks like that:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=b&time1=&time2=

In the BIOS you normally can not check C-States one by one. Maybe you have 2 or 3 options for processor energy savings.


Cheers,
Ernst


Christian Peters
 

David,

as Ernst said, try to disable C-States (I did in complete). Cures the problem with the SkyStar2 eXpress HD and even on Smaug where I use two TBS 5925 the get full service. Even there it was ok only after switching off C-states.

Regards,

Christian 

Am 19.09.2020 um 20:56 schrieb Ernst Lobsiger via groups.io <ernst.lobsiger@...>:

David

Christian had lots of missed and recovered packets, see here:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=c&time1=2020-09-06+20%3A00&time2=2020-09-07+15%3A00

Now with C-States turned off in the BIOS it looks like that:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=b&time1=&time2=

In the BIOS you normally can not check C-States one by one. Maybe you have 2 or 3 options for processor energy savings.


Cheers,
Ernst


R. Alblas
 

Not sure if I did already ask this some time ago, but what exactly is a missed packet, and how can it be recovered anyway? If a packet is missed for whatever  reason you can't ask to resend it (UDP) , it's gone. If there is an error in the packet then it may be corrected, but that's not a 'missed' packet... And I don't think each packet is sent twice?

Cheers,
Rob.



On 19-09-2020 20:56, Ernst Lobsiger via groups.io wrote:
David

Christian had lots of missed and recovered packets, see here:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=c&time1=2020-09-06+20%3A00&time2=2020-09-07+15%3A00

Now with C-States turned off in the BIOS it looks like that:

https://eluna-ancalagon.hcpeters.de/index.pl?rrd=24_packets0&type=b&time1=&time2=

In the BIOS you normally can not check C-States one by one. Maybe you have 2 or 3 options for processor energy savings.


Cheers,
Ernst


Ernst Lobsiger
 

Rob

There is 2 kinds of FEC involved: The EUMETCast TS has MPE packets with 188 Bytes. There is FEC on the DVB-S2 demodulator called LDPC.
MPE packets are tagged with PID and assembled per PID to UDP packets by the OS. Tellicast has it's own FEC on the IP (UDP) level. A "missed"
packet is some damaged UDP packet (CRC ERROR or whatever). If TelliCast's FEC can fix it it's called recovered and you will have no files lost.

Regards
Ernst


R. Alblas
 

OK, thanks. So it's not really a 'missed' packet but a packet with  errors.

Regards,
Rob.


On 19-09-2020 21:48, Ernst Lobsiger via groups.io wrote:
Rob

There is 2 kinds of FEC involved: The EUMETCast TS has MPE packets with 188 Bytes. There is FEC on the DVB-S2 demodulator called LDPC.
MPE packets are tagged with PID and assembled per PID to UDP packets by the OS. Tellicast has it's own FEC on the IP (UDP) level. A "missed"
packet is some damaged UDP packet (CRC ERROR or whatever). If TelliCast's FEC can fix it it's called recovered and you will have no files lost.

Regards
Ernst