Re: C-states of Intel CPU's cause firewire transfer corruptions
Brought to you by:
aeb,
bencollins
From: Nizamov S. <niz...@gm...> - 2012-08-08 15:40:21
|
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 |