TBS 6903 tuner allocations


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

Ernst,

I recall that the two tunes on the 6908 - or their driver software under
Windows - should be used in a particular way because of buffering differences.

I see from an earlier screen-shot (attached) that I used to have:

Device 2, tuner 0, transponder 1.
Device 1, tuner 1, transponder 2.

On page: https://www.satsignal.eu/wxsat/dvb-s2/T1-T2.html
Image:
https://www.satsignal.eu/wxsat/dvb-s2/TBS-single-cable-1-Status-Tuner-production.png

On a rebuilt PC I see that

Device 1, tuner 1, transponder 1.
Device 2, tuner 0, transponder 2.

Would this cause a problem like high packet loss on TP1? I'm seeing a steady
packet loss (and missed 1000/hour, recovered 2000/hour) but only on transponder
1. TP2 is essentially lossless.

The current graphs are here: https://www.satsignal.eu/mrtg/performance_lund.php

The loss seems to stop when I'm actually at the PC, which makes me think it may
not be the TBS at all, but some other background process which runs when I
leave the PC, but I have tried to disable some such as anti-virus on the
EUMETCast processes and tc-recv.exe.

Your thoughts would be appreciated.

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


Ernst Lobsiger
 

On Sat, Nov 13, 2021 at 10:35 PM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:

I recall that the two tunes on the 6908 - or their driver software under
Windows - should be used in a particular way because of buffering differences.
David,

the TBS6908 is twice the TBS6903. You certainly refer to the latter one as in the subject.

As I have never setup a TC receiver under Windows I might not be the right person to answer here. I try to explain once more the problem we had with PCIe cards (only) when HVS-2 started.
HVS-2 was very dynamic going from full throttle to almost zero bits/second for longer periods. Georgios Potiriadis at EUMETSAT finally found the reason for TC client timeouts and CrazyCat
said what HW, the PCIe bridge chip,  was causing this. In the case of the TBS-6903 (and TBS-6908) the driver under GNU/Linux basically consists of three kernel modules loaded at boot up:

stv6120           This module is for the tuner chip including the matrix switch at the input. It has a parameter "rfsource" that you can set for single cable mode.
stv091x           This  module is for the demodulator chip. MODCODs are set here. It has a parameter to set it in single mode to double the bandwidth (never used for EUMETCast).
tbsecp3           This module is for the ECP3 PCIe bridge chip common to all TBS PCIe cards that have been produced after the (deprecated) TBS-6983.

ECP3 allows for up to 8 demodulators each having its own DMA buffer. This buffer accumulates a certain number of 188 Bytes MPE packets and then flushes the whole batch over the bus.
In early drivers IIRC this was hard coded to be 512 MPE packets. HVS-2 on T2 with long gaps of almost zero bits/second made the TC client loose time sync because some minimal heartbeat
was stuck in the DMA buffer that only slowly filled to 512 MPE packets. HVS-1 on T1 never had that problem because BAS always provided some minimal trafffic that kept the DMA buffer busy.


The problem was solved by two different approaches. I added a module parameter to tbsecp3 to choose the size of each of the 8 DMA buffers in units of MPE packets. So we could set
that e.g. to 256 packets for T1 but 32 packets for T2. Of course this increased the interrupt load of the receiver PC but that was no problem. CrazyCat streamlined my solution which is still
part of tbsecp3 and can easily be configured for all TBS cards. EUMETSAT resolved the problem later by always providing some minimal (invisible?) traffic on T2 so that even drivers with a
fixed DMA buffer size of 512 MPE packets should make TC happy. On T1 nothing was added which means that if you set MODCOD for HVS-1 only you have the "dejavue" problem of HVS-2.

On your site you describe the situation under Windows for "Single Cable operation"

https://www.satsignal.eu/wxsat/dvb-s2/T1-T2.html#full-t2

You mention som SR-Test.exe that was used to set the input matrix switch right  (module parameter "rfsource" under GNU/Linux).
You then have a note that makes me think that the PCIe bridge DMA buffer sizes are still fixed somehow in the Windows drivers.

Note: If you are using the beta TBS6903 driver (drivers dated 2017-07-07) you need to lock and receive HVS-1 with tuner-0
and HVS-2 with tuner 1, because they have different-sized packet buffers (64 packets for tuner 0, and 16  packets for tuner 1).

So, unless you have now some other means to set these DMA buffer sizes, those might depend on your Windows driver version :-(  ??.
But don't worry there is still the EUMETSAT solution of the initial problem. All drivers should work now except for MODCODs HVS-1 only.
In othe words I do not think that having T1 on demod 0 and T2 on demod 1 should be a problem nowadays (with recent Windows drivers).

That all said the first thing I would try is to go to your Windows control panel and under "Netzbetrieb und Energiesparen" tell it
to never go to the energy saving mode if it is working unattended. I attach a German screenshot, this must look similar in English.


I also noted that CrazyCat has a new version of BDADataEx from 2021/10/27  (no idea what he has improved though)

http://crazycat69.narod.ru/sattelite/DVBDataEx/bdadataex.htm

Good luck,
Ernst





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

On 14/11/2021 11:59, Ernst Lobsiger via groups.io wrote:
Good luck,
Ernst
Ernst,

Thanks for your notes. I sill need to read and understand them (again).

Just a progress report for the moment:

Work here continues to make PC Lund usable. It seems to have a large packet
loss on one of the two TBS 6903 tuners. I tried swapping the two tuners and
the loss went with the tuner (from HVS-1 to HVS-2). HVS-1 is now almost
loss-less (as HVS-2 was before the change), but it appears that losses are
minimal while the PC is being used (mouse, keyboard etc.) and start after the
user goes away. However, there is no screen-saver, or screen timeout currently
set, and the PC power is set for maximum performance and I can't see anything
set for a few minutes timeout in the advanced power settings.

Power settings are all at maximum, with no power-saving timeout, screen-saver,
or screen shutdown. I need to be sure I'm using the settings you indicated.

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


Ernst Lobsiger
 

David,

I attach an english screen copy of the settings I had to use when testing TelliCastStatsCollector.cmd over the LAN.
I also attach a layout of the tuner chip of the TBS-6903. As I explained I have an stv6120 module parameter "rfsource".

rfsource = 0  (default, 2 cables)  --> demod0 at socket LNB0 / demod1 at socket LNB1   (T1 and T2 any band and polarisation)
rfsource = 1  single cable mode, plug cable at socket LNB0   (only works with T1 and T2 same band and polarisation)
rfsource = 2  single cable mode, plug cable at socket LNB1   (only works with T1 and T2 same band and polarisation)

I still don't know how you switch to single cable mode. Do you still use the SR-Test.exe you mentionned?
Does this just what rfsource = 1 does under GNU/Linux? So you cannot try the setting of rfsource = 2?

It seems your losses occur on demod0. Is this also the case if you do not switch to single cable mode? You
will probably have to reboot or power down? You then just test demod0 on input socket LNB0 (T1 or T2 only).

Another trick that sometimes works (and TBS support proposes) is to use another PCIe slot for the TBS card.

One more thought I had: There might be power saving configurations for the PCIe bus. This used to
be called ASPM and was/is used mainly for Laptops and mobile PCs? Maybe accessible in BIOS only.

I hope you can finally fix this. I have one receiver with a TBS-6903 that runs perfectly here under GNU/Linux.

Cheers,
Ernst


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

On 14/11/2021 11:59, Ernst Lobsiger via groups.io wrote:

Good luck,
Ernst
Thanks, Ernst. I've carried out further tests which have narrowed things down,
but I' still without a full explanation.

1. Swapping the tuners between HVS-1 and HVS-2: the packet loss moves with the
tuner. As HVS-1 is sent to a 4 TB HD, and HVS-2 to a RAMdisk, I think this
eliminates RAMdisk or HD from the problem.

2. Running at the maximum power setting (rather than "balanced" or "energy
saving" did not stop the packet loss. I wouldn't find the identical screen to
yours, but having the ability to control power and screen-saver was present.

3. I don't believe that having a screen-saver (blank screen) or not affected
the problem.

4. Setting the "Power off monitor" time to "never" did resolve the problem.

5. Switching the monitor on and off with its front panel switch did not cause
the problem to start again.

Arne had suggested some new process running when the issues started, but I
could not see a obvious change in CPU, network I/O, or disk I/O.

So my current conclusion is that something unknown happens when the monitor
power-off DVI signal is sent, which affects Device 1, Tuner 1. This is with a
completely fresh installation of Windows, to a PC which used not to have this
problem. One possible other clue is that when a Windows Restart command is
issued, the PC takes a very long time to complete the restart - the spinning
icon last for several minutes, which obviously isn't right....

I'll add this tale to my Web page.

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


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

On 15/11/2021 13:40, Ernst Lobsiger via groups.io wrote:
David,

I attach an english screen copy of the settings I had to use when testing
TelliCastStatsCollector.cmd over the LAN.
I also attach a layout of the tuner chip of the TBS-6903. As I explained I have
an stv6120 module parameter "rfsource".

rfsource = 0  (default, 2 cables)  --> demod0 at socket LNB0 / demod1 at socket
LNB1   (T1 and T2 any band and polarisation)
rfsource = 1  single cable mode, plug cable at socket LNB0   (only works with
T1 and T2 same band and polarisation)
rfsource = 2  single cable mode, plug cable at socket LNB1   (only works with
T1 and T2 same band and polarisation)

I still don't know how you switch to single cable mode. Do you still use the
SR-Test.exe you mentionned?
Does this just what rfsource = 1 does under GNU/Linux? So you cannot try the
setting of rfsource = 2?

It seems your losses occur on demod0. Is this also the case if you do not
switch to single cable mode? You
will probably have to reboot or power down? You then just test demod0 on input
socket LNB0 (T1 or T2 only).

Another trick that sometimes works (and TBS support proposes) is to use another
PCIe slot for the TBS card.

One more thought I had: There might be power saving configurations for the PCIe
bus. This used to
be called ASPM and was/is used mainly for Laptops and mobile PCs? Maybe
accessible in BIOS only.

I hope you can finally fix this. I have one receiver with a TBS-6903 that runs
perfectly here under GNU/Linux.

Cheers,
Ernst
Ernst,

Our e-mails crossed.

Yes, I use SR-Test.exe to set the "single cable" operation. It runs in Admin
mode at PC startup:

~~~~~~~~~~~~~~~~~~~~~~~~~
C:
PUSHD \Tools\BDADataEx
SR-Test.exe
timeout 5
start BDADataEx.exe
timeout 5
start BDADataEx.exe 1
POPD
timeout 5
~~~~~~~~~~~~~~~~~~~~~~~~~

I don't want to try any further experiments now as I'd like to be sure it's now
OK! But this PC did work with the TBS 6903 (not 08) in the same PCIe slot, so
I don't think that's the issue.

Thanks for the chip diagram. Seeing the I2C interface makes me wonder whether
a "power off DVI monitor" command is somehow finding its way into the TBS 6903
card, Tuner 1, through some programming error (AKA "feature") which has been
introduced by a fresh Windows install. Yes, that seems unlikely, but....

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


Ernst Lobsiger
 

David,

I understand you solved your problem by not letting the system turn off the screen. I had a very similar issue here:
I scheduled the Windows PC to make an RSS frame of the UK every 5 minutes and to make a video every 30 minutes.
The satellite data was read from one of my GNU/Linux receivers via a SAMBA share. But when I left the PC after some
time the screen turned black and the PC *stopped making frames* !! It only restarted when the screen was lit again.
It seemed like the whole system went to sleep if I was not sitting in front and then and when moving the mouse.

I opened control panel / system /  power & sleep (the last screenshot I posted) and set it to Sleep "never".
Even with the Screen setting of "15 minutes" my monitor did never turn black again. I simply switched it off
with the front knob and during the next night all RSS frames were produced unattended as expected.

Windows 10 Pro
Version 21H1
Windows Feature Experience Pack 120.2212.3920.0

Cheers,
Ernst


Ernst Lobsiger
 

David and Arne,

my problem explained in the last post could be caused by the NIC going in some sleep state. It's a PCIe device like the TBS6903.
Then the connection to SAMBA would not work and even with the scheduler triggering my Satpy scripts would not find any data.
I wonder whether Windows 10 does now try to put whatever it finds on the PCIe bus to a low power state when let unattended?

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby

At the CLI try "powercfg /a" to find out what low power states your PC can be put in. The more UEFI the less we set in the BIOS.

Regards,
Ernst


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

On 15/11/2021 18:22, Ernst Lobsiger via groups.io wrote:
David and Arne,

my problem explained in the last post could be caused by the NIC going in some
sleep state. It's a PCIe device like the TBS6903.
Then the connection to SAMBA would not work and even with the scheduler
triggering my Satpy scripts would not find any data.
I wonder whether Windows 10 does now try to put whatever it finds on the PCIe
bus to a low power state when let unattended?

https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby
<https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/modern-standby>

At the CLI try "powercfg /a" to find out what low power states your PC can be
put in. The more UEFI the less we set in the BIOS.

Regards,
Ernst
Ernst,

On my system I see:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
C:\Users\David>powercfg /a
The following sleep states are available on this system:
Standby (S3)
Hibernate
Hybrid Sleep
Fast Startup

The following sleep states are not available on this system:
Standby (S1)
The system firmware does not support this standby state.

Standby (S2)
The system firmware does not support this standby state.

Standby (S0 Low Power Idle)
The system firmware does not support this standby state.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I'm now seeing a steady lost and recovered rate, together with odd bursts of
lost throughout the day, but only on the HVS-2/RAMdisk configuration/tuner.
This with the monitor permanently on logically, but physically switched off on
the front panel.

https://www.satsignal.eu/mrtg/performance_lund.php
(possibly with a Ctrl-F5)

I still don't understand why just one tuner is affected by the "Turn off screen
after..." setting.

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


Ernst Lobsiger
 

David,

I think it's not a demod problem but a PCIe bridge problem. As I said in a post before this ECP3 chip (common to all TBS PCIe cards issued after the TBS6983 Arne uses) has 8 "channels" with seperate DMA buffers for up to 8 demodulators. If I got you right you did put T2 or T1  on demod0 and the problem was always there. This is always "channel0" of the ECP3 chip. I also notet that most of your lost packets bursts on HVS-2 are in sync with spikes of your HD/SSD read usage.

Under GNU/Linux there is interrupt affinity. You can pin certain interrupts to always use the same processor core. Your most frequent interrupts are probably related to ECP3 DMA transfer of the TBS-card, to your NIC and to the HDD/ SSD.
Under GNU/Linux you can do as root a "# cat /proc/interrupts" to see who uses what interrupts how often. The busiest interrupts should be on separate cores. There should be a similar system information under Windows 10 somewhere.
While I can optimize interrupts with a simple bash script under GNU/Linux Interrupt affinity under Windows 10 is probably registry stuff. So that's not the first thing you want to touch. But try to find out what causes thes HDD/SSD read spikes.


Good luck,
Ernst


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

On 16/11/2021 17:40, Ernst Lobsiger via groups.io wrote:
David,

I think it's not a demod problem but a PCIe bridge problem. As I said in a post
before this ECP3 chip (common to all TBS PCIe cards issued after the TBS6983
Arne uses) has 8 "channels" with seperate DMA buffers for up to 8 demodulators.
If I got you right you did put T2 or T1  on demod0 and the problem was always
there. This is always "channel0" of the ECP3 chip. I also notet that most of
your lost packets bursts on HVS-2 are in sync with spikes of your HD/SSD read
usage.

Under GNU/Linux there is interrupt affinity. You can pin certain interrupts to
always use the same processor core. Your most frequent interrupts are probably
related to ECP3 DMA transfer of the TBS-card, to your NIC and to the HDD/ SSD.
Under GNU/Linux you can do as root a "# cat /proc/interrupts" to see who uses
what interrupts how often. The busiest interrupts should be on separate cores.
There should be a similar system information under Windows 10 somewhere.
While I can optimize interrupts with a simple bash script under GNU/Linux
Interrupt affinity under Windows 10 is probably registry stuff. So that's not
the first thing you want to touch. But try to find out what causes thes HDD/SSD
read spikes.


Good luck,
Ernst
Thanks for your comments, Ernst, and apologise for need them to be repeated!
Windows has processor affinity, yes, but I don't know about interrupt affinity.

On my particular system there are 4 cores. The HVS-1 and HVS-2 TelliCast
processes are allowed to run on any core. The two BDADataEx processes and both
only allowed to run on Core 0 and both are at Realtime priority. I wonder
whether separating the affinity of the two BDADataEx processes would help? I
don't know where the affinity is set - it may be within the BDADataEx.exe itself?

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


Ernst Lobsiger
 

On Wed, Nov 17, 2021 at 06:52 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
Windows has processor affinity, yes, but I don't know about interrupt affinity.
David,

here is a tool for interrupt affinity under Windows

https://www.techpowerup.com/download/microsoft-interrupt-affinity-tool/

use it at your own risk and peril :-).

Cheers,
Ernst


CrazyCat
 

Hi David,

I make test build BDADataEx 1.4.12 with Affinity option
http://crazycat69.narod.ru/sattelite/DVBDataEx/test/BDADataEx.rar


On Wed, Nov 17, 2021 at 04:52 PM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
On my particular system there are 4 cores. The HVS-1 and HVS-2 TelliCast
processes are allowed to run on any core. The two BDADataEx processes and both
only allowed to run on Core 0 and both are at Realtime priority. I wonder
whether separating the affinity of the two BDADataEx processes would help? I
don't know where the affinity is set - it may be within the BDADataEx.exe itself?


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

On 19/11/2021 17:56, CrazyCat wrote:
Hi David,

I make test build BDADataEx 1.4.12 with *Affinity* option
http://crazycat69.narod.ru/sattelite/DVBDataEx/test/BDADataEx.rar
<http://crazycat69.narod.ru/sattelite/DVBDataEx/test/BDADataEx.rar>
Many thanks for that, CrazyCat. I hope to test this, but I need to ask Ernst a
question first.

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


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

On 17/11/2021 16:57, Ernst Lobsiger via groups.io wrote:
David,

here is a tool for interrupt affinity under Windows

https://www.techpowerup.com/download/microsoft-interrupt-affinity-tool/
<https://www.techpowerup.com/download/microsoft-interrupt-affinity-tool/>

use it at your own risk and peril :-).

Cheers,
Ernst
Ernst,

Many thanks for that. Unfortunately the program is from 2007 and hasn't been
updated. When running it you get the device list, but not the interrupt mask -
"the registry value is an unexpected type".

The device list is quite long - longer than I expected - but it shows just one
TBS6903 device with a physical PCI address, but two TAP adapters without a
hardware address (just /device/00000003 or something like that).

Now that CrazyCat has the affinity ability that may help, but I don't know
enough about Windows internals (even though I have the book) to know whether
there should be any relation between program affinity and interrupt affinity.
Something in me says there won't be, as interrupts could occur at any time, and
Windows would simply choose the least busy processor to handle them, and then
notify the the process expecting that interrupt that its data is ready.

As this is UDP data coming in, I guess BDADataEx converts the DVB stream into a
series of UDP packets and sends them to Windows as if they come from a network
device. As there is (apparently) just one hardware device as seen by Windows,
perhaps having two different affinities for the two BDADataEx instances is a
good idea, assuming that the two processors nominated are actually free, or the
least loaded at that instant!

Perhaps best to let Windows decide on this four-processor system!

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


Ernst Lobsiger
 

On Sat, Nov 20, 2021 at 12:52 AM, David J Taylor GM8ARV 🏴󠁧󠁢󠁳󠁣󠁴󠁿 🇪🇺 wrote:
Now that CrazyCat has the affinity ability that may help, but I don't know
enough about Windows internals (even though I have the book) to know whether
there should be any relation between program affinity and interrupt affinity.
David,

under GNU/Linux you have both and these are independant choices. You can tell a process to run on one core. This can e.g. be the HVS-2 client. Maybe under Windows this could also be BDADataEx.
I have never experimented with this feature. On the other hand you can tell the kernel to use always the same core to serve a special interrupt. In /proc/interrupts all devices and their interrupts are listed.
In the case of a TBS-6903 probably the busiest interrupt will be the one used by the ECP3 PCIe bridge for DMA transfer of a bunch of MPE packets to the kernel. The kernel then sorts and assembles these
MPE (188Bytes) packets per PID to UDP packets that finally are sent to an internal interface dvbond0. Under Windows that's probably what BDA (Microsoft) and BDADataEx (CrazyCat, sounds to me like
"Extract Data from BDA") does. Now the busiest interrupts (ECP3, HDD/SSD, NIC, USB?) should not occurr on the same core. I have a script that pins these interrupts as far as possible to different cores.

This should be possible under Windows as well. The question is now what the new BDADataEx switch does. CrazyCat should please explain whether this pins BDADataEx or the ECP3 interrupt to some core ?

Cheers,
Ernst

Attached: Output of # cat /proc/interrupts of my receiver Kallisto (Devuan 3.0, Beowulf, GNU/Linux, using a TBS-6909X, note the tbsecp3 entry):

           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7       
  0:          8          0          0          0          0          0          0          0  IR-IO-APIC   2-edge      timer
  4:          0          0          0    1318049          0          0          0          0  IR-IO-APIC   4-edge      ttyS0
  5:          0          0          0          0          0          0          0          0  IR-IO-APIC   5-edge      parport0
  8:          0          0          0          0          0         21          0          0  IR-IO-APIC   8-edge      rtc0
  9:          0          0          0          0          0          0          0          0  IR-IO-APIC   9-fasteoi   acpi
 16:          0         31          0          0          0          0          0          0  IR-IO-APIC  16-fasteoi   ehci_hcd:usb1
 17:         62          0          0          0          0          0          0          0  IR-IO-APIC  17-fasteoi   snd_hda_intel:card1
 18:          0          0          0          0          0          0          0          0  IR-IO-APIC  18-fasteoi   i801_smbus
 19:          0 1415776871          0          0          0          0          0          0  IR-IO-APIC  19-fasteoi   tbsecp3
 23:          0          0          0          0    3267825          0          0          0  IR-IO-APIC  23-fasteoi   ehci_hcd:usb3
 24:          0          0          0          0          0          0          0          0  DMAR-MSI   0-edge      dmar0
 25:          0          0          0          0          0          0          0          0  IR-PCI-MSI 16384-edge      PCIe PME
 26:          0          0          0          0          0          0          0          0  IR-PCI-MSI 458752-edge      PCIe PME
 27:          0          0          0          0          0          0          0          0  IR-PCI-MSI 473088-edge      PCIe PME
 28:          0          0          0          0          0          0          0    3255510  IR-PCI-MSI 409600-edge      eth0
 29:          0          0   29746433          0          0          0          0          0  IR-PCI-MSI 512000-edge      ahci[0000:00:1f.2]
 30:          0          0          0          0          0          0          0          0  IR-PCI-MSI 327680-edge      xhci_hcd
 31:          0          0          0          0          0         23          0          0  IR-PCI-MSI 360448-edge      mei_me
 32:          0          0          0          0          0          0          0        242  IR-PCI-MSI 442368-edge      snd_hda_intel:card0
 33:          0          0    4060863          0          0          0          0          0  IR-PCI-MSI 524288-edge      nvkm
NMI:      16145      23462      21583      22693      20261      19027      15918      15328   Non-maskable interrupts
LOC:  153775488  586746645  398399531  388269865  325950027  253666782  202693335  176936583   Local timer interrupts
SPU:          0          0          0          0          0          0          0          0   Spurious interrupts
PMI:      16145      23462      21583      22693      20261      19027      15918      15328   Performance monitoring interrupts
IWI:          0          5          0          0          0          0          0          0   IRQ work interrupts
RTR:          0          0          0          0          0          0          0          0   APIC ICR read retries
RES:  117490731    5532105   18876446    9023898    5781590    4223042    3687445    3482737   Rescheduling interrupts
CAL:   28108361   26115001   28588588   28688108   27971425   27915887   27513570   27572657   Function call interrupts
TLB:   28881833   26792476   29240539   29311575   28567330   28482494   28063990   28101568   TLB shootdowns
TRM:          0          0          0          0          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0          0          0          0          0   Threshold APIC interrupts
DFR:          0          0          0          0          0          0          0          0   Deferred Error APIC interrupts
MCE:          0          0          0          0          0          0          0          0   Machine check exceptions
MCP:       6524       6525       6525       6525       6525       6525       6525       6525   Machine check polls
ERR:          0
MIS:          0
PIN:          0          0          0          0          0          0          0          0   Posted-interrupt notification event
NPI:          0          0          0          0          0          0          0          0   Nested posted-interrupt event
PIW:          0          0          0          0          0          0          0          0   Posted-interrupt wakeup event

David, to begin with you should have a similar interrupt list as above from Windows 10 to see whether there is something to optimize at all.


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

On 20/11/2021 09:35, Ernst Lobsiger via groups.io wrote:
David,

under GNU/Linux you have both and these are independant choices. You can tell a
process to run on one core. This can e.g. be the HVS-2 client. Maybe under
Windows this could also be BDADataEx.
I have never experimented with this feature. On the other hand you can tell the
kernel to use always the same core to serve a special interrupt. In
/proc/interrupts all devices and their interrupts are listed.
In the case of a TBS-6903 probably the busiest interrupt will be the one used
by the ECP3 PCIe bridge for DMA transfer of a bunch of MPE packets to the
kernel. The kernel then sorts and assembles these
MPE (188Bytes) packets per PID to UDP packets that finally are sent to an
internal interface dvbond0. Under Windows that's probably what BDA (Microsoft)
and BDADataEx (CrazyCat, sounds to me like
"Extract Data from BDA") does. Now the busiest interrupts (ECP3, HDD/SSD, NIC,
USB?) should not occurr on the same core. I have a script that pins these
interrupts as far as possible to different cores.

This should be possible under Windows as well. The question is now what the new
BDADataEx switch does. CrazyCat should please explain whether this pins
BDADataEx or the ECP3 interrupt to some core ?

Cheers,
Ernst

Attached: Output of # cat /proc/interrupts of my receiver Kallisto (Devuan 3.0,
Beowulf, GNU/Linux, using a TBS-6909X, note the tbsecp3 entry):
[]

David, to begin with you should have a similar interrupt list as above from
Windows 10 to see whether there is something to optimize at all.
Thanks for that, Ernst. I can get the list of interrupt sources but not their
associations. My system has only 4 cores, and my feeling is that if I dedicate
two cores exclusively to the two TAP devices that leaves the system with just
two cores for everything else, and I wonder whether that would be the best
balance. With 8 cores you're only dedicating 25% of the resources.

It would be interesting to hear what results CrazyCat has seen.

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


Ernst Lobsiger
 

David,

Sorry to ask this: Do you run 2 instances of BDADataEx if you receive 2 transponders? Or do you only need 2 Tap Adapters?

If you run 2 BDADataEx processes then the new switch most probably pins the process (or Tap Adapter?) and not the ECP3 interrupt!
I would not make any sense to pin the ECP3 interrupt in different ways from the 2 BDADataEx panels. To run two processes of
BDADataEx pined to different cores might be worth to try.

Cheers,
Ernst


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

On 20/11/2021 10:47, Ernst Lobsiger via groups.io wrote:
David,

Sorry to ask this: Do you run 2 instances of BDADataEx if you receive 2
transponders? Or do you only need 2 Tap Adapters?

If you run 2 BDADataEx processes then the new switch most probably pins the
process (or Tap Adapter?) and not the ECP3 interrupt!
I would not make any sense to pin the ECP3 interrupt in different ways from the
2 BDADataEx panels. To run two processes of
BDADataEx pined to different cores might be worth to try.

Cheers,
Ernst
_._,_._,
Ernst,

You run a program (effectively installing a device) which adds a second TAP
device. You then run two instances of BDADataEx (two different tuner
frequencies) and (I believe) each instance attaches to a different TAP "device".

I'll have to try the two affinities, but without making it exclusive. I we
could identify the continuous missed & recovered packets I feel that something
useful would have been learnt.

I think I'm gradually understanding a little better what happens. (In the past
Have have modified device drivers for VAX/VMS so I have worked at that level,
some years ago, though).

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


CrazyCat
 

Two instances BDADataEx (two precess with own settings) work with separate TAP-DVB virtual network interface (not use any irq)


On Sat, Nov 20, 2021 at 12:47 PM, Ernst Lobsiger wrote:
Sorry to ask this: Do you run 2 instances of BDADataEx if you receive 2 transponders? Or do you only need 2 Tap Adapters?

If you run 2 BDADataEx processes then the new switch most probably pins the process (or Tap Adapter?) and not the ECP3 interrupt!
I would not make any sense to pin the ECP3 interrupt in different ways from the 2 BDADataEx panels. To run two processes of
BDADataEx pined to different cores might be worth to try.