Mailing List archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[vdr] Re: PCI Latecy and OSD?



First I've changed the power supply. There is only the DVBs (rev 1.3) card in one PCI slot. Here are the result of my evening tests:

I am using a twin LNB on my dish. The first feed is connected to the faulty PC the second one is connected to the working PC.

Here is the frontend status output from the first PC:

[root@(none) szap]# ./szap -n 1
zapping to 'Das Erste':
sat 0, frequency = 11837 MHz H, symbolrate 27500000, vpid = 0x0065, apid = 0x0066
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 0d | signal 8f8f | snr c2c2 | ber 000002a8 | unc ffffffff |
status 0d | signal 8a8a | snr c0c0 | ber 000002a8 | unc 00000000 |
status 0c | signal 8e8e | snr b6b6 | ber 000002a8 | unc 00000000 |
status 1f | signal 8686 | snr c0c0 | ber 000133f8 | unc 00000000 | FE_HAS_LOCK
status 0c | signal 8d8d | snr bcbc | ber 000133f8 | unc 00000000 |
status 1f | signal 8686 | snr c2c2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8686 | snr baba | ber 00000000 | unc 00000000 |
status 0c | signal 9898 | snr a7a7 | ber 00000000 | unc 00000000 |
status 0c | signal 9292 | snr aeae | ber 00000000 | unc 00000000 |
status 1f | signal 8686 | snr c5c5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8a8a | snr c4c4 | ber 000000fa | unc 00000000 |
status 1f | signal 8787 | snr c5c5 | ber 000000fa | unc 00000000 | FE_HAS_LOCK
status 1f | signal 8181 | snr bcbc | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 8484 | snr c2c2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8989 | snr b0b0 | ber 00000000 | unc ffffffff |
status 00 | signal bcbc | snr 8888 | ber 00000000 | unc ffffffff |
status 00 | signal 9f9f | snr 8787 | ber 00000000 | unc ffffffff |
status 00 | signal c3c3 | snr 3e3e | ber 00000000 | unc ffffffff |
status 00 | signal 6666 | snr 3b3b | ber 00000000 | unc ffffffff |
status 1f | signal a8a8 | snr cdcd | ber 00000000 | unc ffffffff | FE_HAS_LOCK
status 0c | signal 9191 | snr b8b8 | ber 00000000 | unc 00000000 |
status 0d | signal 8383 | snr bbbb | ber 00000000 | unc 00000000 |
status 1f | signal 8484 | snr b9b9 | ber 00011fbc | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8d8d | snr baba | ber 00011fbc | unc 00000000 |
status 0d | signal 9191 | snr b8b8 | ber 00000000 | unc 00000000 |
status 1f | signal a5a5 | snr cdcd | ber 00000000 | unc ffffffff | FE_HAS_LOCK
status 0d | signal 9494 | snr b6b6 | ber 00000000 | unc 00000000 |
status 0d | signal 8888 | snr b6b6 | ber 00000000 | unc 00000000 |
status 1f | signal 8484 | snr bdbd | ber 0001325e | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8d8d | snr bbbb | ber 0001325e | unc 00000000 |
status 0d | signal 8f8f | snr bdbd | ber 00000000 | unc 00000000 |
status 0d | signal 9a9a | snr baba | ber 00000000 | unc 00000000 |
status 1f | signal 8080 | snr c6c6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8686 | snr bebe | ber 00000000 | unc 00000000 |
status 0d | signal 8484 | snr b1b1 | ber 00000000 | unc 00000009 |
status 0c | signal 9696 | snr b2b2 | ber 000010ea | unc 00000000 |
status 0d | signal 9494 | snr bfbf | ber 000010ea | unc 00000000 |
status 0d | signal 9191 | snr bdbd | ber 00000000 | unc 00000000 |
status 0d | signal 8484 | snr b8b8 | ber 00000000 | unc 00000000 |
status 1f | signal 8b8b | snr bbbb | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 9393 | snr b5b5 | ber 00000000 | unc 00000000 |
status 0d | signal 9393 | snr b7b7 | ber 00000000 | unc 00000000 |
status 0c | signal dbdb | snr a0a0 | ber 00000000 | unc 00000000 |
status 1f | signal 7070 | snr c9c9 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 0d | signal 8f8f | snr b3b3 | ber 00000352 | unc 00000000 |
status 0c | signal 9595 | snr b1b1 | ber 00000352 | unc 00000000 |
status 1f | signal c0c0 | snr c5c5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

As you can see it is really bad.
Here is the one from the second PC:


[root@(none) szap]# ./szap -n 1
zapping to 'Das Erste':
sat 0, frequency = 11837 MHz H, symbolrate 27500000, vpid = 0x0065, apid = 0x0066
using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0'
status 03 | signal 9494 | snr d4d4 | ber 0001ec12 | unc ffffffff |
status 1f | signal 9393 | snr d6d6 | ber 0001ec12 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d6d6 | ber 0001ec12 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9b9b | snr d5d5 | ber 000154d2 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9e9e | snr d5d5 | ber 000154d2 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9696 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9494 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9a9a | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9191 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9a9a | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9696 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 8f8f | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9494 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9898 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9191 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9292 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9191 | snr d7d7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9595 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9898 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9999 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9a9a | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9292 | snr d7d7 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9494 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9191 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9898 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9898 | snr d3d3 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9a9a | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9292 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9999 | snr d2d2 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9797 | snr d5d5 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9494 | snr d6d6 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9c9c | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9898 | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK
status 1f | signal 9d9d | snr d4d4 | ber 00000000 | unc 00000000 | FE_HAS_LOCK

No problem at all.


Where can it come from?

I can repeat the test with a spliter if needed. I am unable to post in the linux-DVB mailing list due to wrong email address in my registration may be someone can do it for me.


Alexw wrote:


OK, I'll enable DMA access on hda this evening. I don't know if this will help because the problem is present when I am watching TV. May be the system is slowed down during the harddrive access when I am logging information through syslog.

The motherboard I have is the G Pro from ASrock. It is based on a 650/952L chip.

I'll let you know the result of this evening tests.

Alex

Simeon Walker wrote:

I notice from your lspci output that you are using the same/very
similar chipset as me (I am using an MSI Hermes 650 box).

The IDE interface identifies itself as an SiS 5513 which was
an old SiS chip! This means that the driver does not automatically
enable DMA. I don't know if this may be you problem. It
certainly has an effect on the record/playback performance
that I see.

Look at the man page for hdparm, doing something like
hdparm -t /dev/hda
will give an idea of the disk speed. After enabling DMA with
hdparm -d1 /dev/hda
the disk speed give by my system went from 3 to 50 MB/s!

Hope this help,
Simeon

On 01/27/03 20:10, alexw wrote:

Hi,

I've got quite the same problem but using VDR with only one DVB card. The picture is getting pixelized with sqares during 1~2 seconds. Sometimes the screen goes black.

I've try several driver version, the result is the same :-(

Tested driver:

DVB-cvs-20030102
DVB-cvs-20030116
linux-dvb.2002-12-01.tar.bz2
linux-dvb.2002-12-08.tar.bz2
linux-dvb.2003-01-08-ci-ll


Playing with the latency does not fix the problem.

Here is the lspci -vvv

00:00.0 Host bridge: Silicon Integrated Systems [SiS] 650 Host (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
Latency: 32
Region 0: Memory at e0000000 (32-bit, non-prefetchable) [size=64M]
Capabilities: [c0] AGP version 2.0
Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Silicon Integrated Systems [SiS] 5591/5592 AGP (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Bus: primary=00, secondary=01, subordinate=02, sec-latency=0
I/O behind bridge: 0000c000-0000cfff
Memory behind bridge: dfd00000-dfefffff
Prefetchable memory behind bridge: cfa00000-dfbfffff
BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B-

00:02.0 ISA bridge: Silicon Integrated Systems [SiS] 85C503/5513 (rev 04)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 0

00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (prog-if 80 [Master])
Subsystem: Unknown device 1849:5513
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128
Region 4: I/O ports at ff00 [size=16]

00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 10/100 Ethernet (rev 90)
Subsystem: Unknown device 1849:0900
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (13000ns min, 2750ns max)
Interrupt: pin A routed to IRQ 5
Region 0: I/O ports at dc00 [size=256]
Region 1: Memory at dfff8000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at dffc0000 [disabled] [size=128K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
Subsystem: Technotrend Systemtechnik GmbH: Unknown device 0000
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 128 (3750ns min, 9500ns max)
Interrupt: pin A routed to IRQ 3
Region 0: Memory at dfff7e00 (32-bit, non-prefetchable) [size=512]

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS]: Unknown device 6325 (prog-if 00 [VGA])
Subsystem: Unknown device 1849:6325
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
BIST result: 00
Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Region 1: Memory at dfee0000 (32-bit, non-prefetchable) [size=128K]
Region 2: I/O ports at cc00 [size=128]
Capabilities: [40] Power Management version 1
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] AGP version 2.0
Status: RQ=15 SBA+ 64bit- FW- Rate=x1,x2,x4
Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>


I am using VDR version 1.2.21. This soft rocks ;-)

Cheers,

Alex


Rene Bartsch wrote:

----- Original Message -----
From: "Bläser, Lars" <LBlaeser@hofheim.de>
To: <vdr@linuxtv.org>
Sent: Monday, January 27, 2003 3:09 PM
Subject: [vdr] PCI Latecy and OSD?



vdr 1.0.4 AIO, 2 full DVB-s with single irq for every card)

as i had problems with my 2 DVB-s cards (picture distorsion on card1 when


recording on card2)

i tried to increase the pci latency from 32 to 64 and had so effect - only


the impression that the typical OSD problem (lower quarter somtimes missing
and wrong colors) increased

so i decresed the latency to 16 and had significant less OSD problems then


with 32


Did you try a latency of 128? The DVB-cards need it at least.

Rene














--
Info:
To unsubscribe send a mail to listar@linuxtv.org with "unsubscribe vdr" as subject.



Home | Main Index | Thread Index