Re: C-states of Intel CPU's cause firewire transfer corruptions

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 454-5900

2012/8/8 Clemens Ladisch <cl...@la...>:
> Nizamov Shawkat wrote:
>> On old PC this CCD camera was connected using VT6307 card. I used this
>> setup for more than the year and it showed no corruptions at all [...]
>> However, after connecting the same camera using the same VT6307 card
>> to the quad-core p5@2.8GHz
>
> The P5 was sold in 1993.  Do you mean the i5-2300?

Sorry, i5-760 @ 2.80GHz. Gigabyte GA-P55A-UD3 motherboard.

>
>> 8 Gb RAM (Linux), I noticed that there are corruptions in the acquired
>> frames.  [...]
>> With the same VT6307 card and CCD camera on my newer Linux workstation,
>> I noticed that about 1 byte in 15000 bytes would be lost (actually in
>> my case that means that approximately 1 line of pixels would be zeroed
>> out in every 5-10 frames).
>
> Please note that modern Intel chipsets do not have PCI support, so many
> mainboards include some PCIe/PCI bridge chip -- and almost all vendors
> try to save a few cents by using cheap crap.
>
> Which bridge do you have (lspci)?
>

It's all Intel :

00:00.0 Host bridge: Intel Corporation Core Processor DMI (rev 11)
00:03.0 PCI bridge: Intel Corporation Core Processor PCI Express Root
Port 1 (rev 11)
00:08.0 System peripheral: Intel Corporation Core Processor System
Management Registers (rev 11)
00:08.1 System peripheral: Intel Corporation Core Processor Semaphore
and Scratchpad Registers (rev 11)
00:08.2 System peripheral: Intel Corporation Core Processor System
Control and Status Registers (rev 11)
00:08.3 System peripheral: Intel Corporation Core Processor
Miscellaneous Registers (rev 11)
00:10.0 System peripheral: Intel Corporation Core Processor QPI Link (rev 11)
00:10.1 System peripheral: Intel Corporation Core Processor QPI
Routing and Protocol Registers (rev 11)
00:1a.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1a.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1a.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1a.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 06)
00:1b.0 Audio device: Intel Corporation 5 Series/3400 Series Chipset
High Definition Audio (rev 06)
00:1c.0 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 1 (rev 06)
00:1c.1 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 2 (rev 06)
00:1c.4 PCI bridge: Intel Corporation 5 Series/3400 Series Chipset PCI
Express Root Port 5 (rev 06)
00:1d.0 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1d.1 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1d.2 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1d.3 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB Universal Host Controller (rev 06)
00:1d.7 USB controller: Intel Corporation 5 Series/3400 Series Chipset
USB2 Enhanced Host Controller (rev 06)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
00:1f.0 ISA bridge: Intel Corporation 5 Series Chipset LPC Interface
Controller (rev 06)
00:1f.2 SATA controller: Intel Corporation 5 Series/3400 Series
Chipset 6 port SATA AHCI Controller (rev 06)
00:1f.3 SMBus: Intel Corporation 5 Series/3400 Series Chipset SMBus
Controller (rev 06)
01:00.0 VGA compatible controller: Advanced Micro Devices [AMD] nee
ATI Cedar PRO [Radeon HD 5450]
01:00.1 Audio device: Advanced Micro Devices [AMD] nee ATI Cedar HDMI
Audio [Radeon HD 5400/6300 Series]
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 03)
04:00.0 Signal processing controller: National Instruments PXIe-4353
05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link)
3f:00.0 Host bridge: Intel Corporation Core Processor QuickPath
Architecture Generic Non-Core Registers (rev 04)
3f:00.1 Host bridge: Intel Corporation Core Processor QuickPath
Architecture System Address Decoder (rev 04)
3f:02.0 Host bridge: Intel Corporation Core Processor QPI Link 0 (rev 04)
3f:02.1 Host bridge: Intel Corporation Core Processor QPI Physical 0 (rev 04)
3f:03.0 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller (rev 04)
3f:03.1 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Target Address Decoder (rev 04)
3f:03.4 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Test Registers (rev 04)
3f:04.0 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 0 Control Registers (rev 04)
3f:04.1 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 0 Address Registers (rev 04)
3f:04.2 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 0 Rank Registers (rev 04)
3f:04.3 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 0 Thermal Control Registers (rev 04)
3f:05.0 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 1 Control Registers (rev 04)
3f:05.1 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 1 Address Registers (rev 04)
3f:05.2 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 1 Rank Registers (rev 04)
3f:05.3 Host bridge: Intel Corporation Core Processor Integrated
Memory Controller Channel 1 Thermal Control Registers (rev 04)

>> I guess that this is very small error rate
>
> The expected error rate for a correctly designed and configured system
> is expected to be essentially zero.
>

I mean that in general such errors are not noticed by the user. Not
that it is acceptable by design.
I did not noticed it too in coriander when checking it as a generic
video camera.
But on absolutely static and generally homogenous image with
illumination conditions changing each frame, inter-frame buffer
corruptions were revealed immediately.

>> I changed PCI ports, made sure that there is no other PCI devices on
>> the bus, adjusted all possible PCI bus and device settings including
>> exotic ones (memory/address stepping), played with giving real-time
>> priority to my test program, higher interrupt priority to the firewire
>> module, tried to force VT6307 to run in OHCI1.1 mode, recompile dc1394
>> libraries, coriander etc. I tried a fresh Linux kernel 3.5. I got the
>> smaller rate of corruptions but never could get rid of them
>> completely.
>
> In theory, none of these should be able to affect your C-state problem.
> Were there methods that actually did have a significant effect?
>

There were no significant or obviously notable changes.
Slight changes that I observed most probably should be attributed to
the background processes, which wake up CPU cores more or less
frequently. I have a bunch of desktop and development applications
open, however top and iotop did not show any heavyweight processes
during acquisition.

>> I could not find the LSI chips with 4kb buffer therefore I
>> bought FW card with 2 Kb buffer, but with much more robust TI chip
>> (43AB23).
>
> PCI or PCIe?  If the latter, which bridge?
>

It is PCI.

05:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB23
IEEE-1394a-2000 Controller (PHY/Link) (prog-if 10 [OHCI])
        Flags: bus master, medium devsel, latency 32, IRQ 18
        Memory at fbbff000 (32-bit, non-prefetchable) [size=2K]
        Memory at fbbf8000 (32-bit, non-prefetchable) [size=16K]
        Capabilities: <access denied>
        Kernel driver in use: firewire_ohci
        Kernel modules: firewire-ohci

As far as I understand, it is connected via this bridge and it is the
only PCI device connected to this bridge:

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev a6)
(prog-if 01 [Subtractive decode])
        Flags: bus master, fast devsel, latency 0
        Bus: primary=00, secondary=05, subordinate=05, sec-latency=32

>> I found an application note which blamed that newer Intel CPU's
>> introduced so known C-states for power consumption reduction. They
>> claimed that even if a single core of CPU gets into such state, not
>> only its frequency, but the bandwidth of buses will be reduced too!
>
> All modern CPUs include the memory controller, so they have to be woken
> up for the controller to be able to write data to memory.  The deeper
> the sleep state, the longer it takes to wake up.  (In theory, it should
> be possible to configure the MC to prevent it from sleeping, but I doubt
> that there is any BIOS option for this.)
>
>

It explains a lot, thank you.

With best regards,
S.Nizamov