Anzeige:
Ergebnis 1 bis 2 von 2

Thema: Wo wird Latency Timer eingestellt?

  1. #1
    Registrierter Benutzer
    Registriert seit
    Nov 2001
    Ort
    Rheinland
    Beiträge
    117

    Wo wird Latency Timer eingestellt?

    Hi

    Bei der Info zu meiner Hardware sehe ich, daß Linux die Latency-Timer für die einzelnen Devices unterschiedlich einstellt. Im Bios steht latency time 32, bei der Info steht z.B. für USB 64 und für den IDE-Controller 120.
    Geht das System standardmässig auf Sicherheit? Kann man manuelle Änderungen an der Zeit vornehmen (und wenn überhaupt, wo) ?

    Danke euch

    Nachtrag per Änderung:

    Es könnte auch sein, daß sich die Komponenten Ihrer erforderliche Latency-Zeit selber nehmen / definieren. Dann wäre meine Info ja richtig und nicht etwas, was von Linux eingestellt wird, sondern eine reine Hardwareangelegenheit. Wer weiss dazu mehr. Ich finde in meinen Büchern und im Internet nichts zu dem Thema, außer eben der altbekannten BIOS-Einstellung zum Timer und dessen Auswirkung.
    Geändert von weha (06.02.02 um 08:33 Uhr)
    ______________________________
    Life is to short for reboots

  2. #2
    Registrierter Benutzer
    Registriert seit
    Nov 2001
    Ort
    Rheinland
    Beiträge
    117

    Gefunden

    habe ich etwas. Ich stelle es hier zur Verfügung, falls noch jemand anderes Interresse daran haben sollte:


    The PCI latency timer
    The answer to this question has everything to do with a configurable setting that each PCI device has, the PCI bus latency timer. It's normally the role of the Linux driver to set the proper PCI bus latency timer value for each PCI device in your system, and most of the time the default settings are adequate (if not optimal), all the devices get along fine and the system works properly. The PCI bus latency timer can range from zero to 248. If a device has a setting of zero, then it will immediately give up the bus if another device needs to transmit. If a device has a setting of 248, it will continue to use the bus for a longer period of time before stopping, while the other device waits for its turn.

    If all of your devices have relatively high PCI bus latency timer settings and a lot of data is being sent over the bus, then your PCI cards are generally going to have to wait longer before they gain control of the bus and can begin sending data. However, once they gain control of the bus they will be able to burst a lot of data across it before giving up the bus to another device. This is why high PCI bus latency timer settings increase latency (the delay in sending data across the bus), but also increase effective bandwidth. Because each device gets to burst large amounts of data across the bus without interruption, the PCI bus is used more efficiently and your PCI devices can transmit more data.

    On the other hand, if all your PCI devices have low PCI bus latency settings, then they're going to gladly give up the bus if another card needs to transmit data. This results in a much lower data transmit latency, since no device is going to hold on to the bus for an extended period of time, causing other devices to wait. The dark side to all this is that low PCI bus latency timer settings reduce the effective PCI bus bandwidth when two or more PCI devices are operating simultaneously. This happens because large data bursts become much less frequent and control of the bus changes rapidly, increasing overhead.

    Most Linux distributions include a suite of tools called pci-utils that allow you to view and change the latency timer settings for your PCI devices. To view your current PCI latency settings, type:



    # lspci -v



    Typing this command will display very detailed information about all of your PCI devices. The PCI latency setting for each device is listed on the third line, right before the IRQ setting.

    PCI latency approaches
    How does this relate to my garbled sound problem? Well, I was experiencing garbled sound because with my default PCI latency settings the way they were, the V550 dominated the PCI bus when performing 3D acceleration. Here is why. My V550 is an AGP 2X card, so when I turned off AGP (to increase stability), I reduced the card's bandwidth to main memory by 75%! Because my V550 now was trying to pump the same amount of data across the slower PCI bus, the PCI bus was nearing 100% utilization, and this was causing problems for my sound hardware. Audio devices are especially susceptible to PCI latency issues because they generally have small data buffers and need their audio data delivered to them on time to avoid buffer underruns. With my current settings, the V550 was using so much PCI bandwidth that there wasn't enough left to get data to my sound card, so I experienced audio distortion caused by buffer underruns.

    There are two possible solutions to this problem. The first and most obvious solution would be to use the setpci command to reduce my V550's PCI latency timer. This would cause it to share the PCI bus more readily, allowing my other devices to transmit their data with less latency. I tried this solution using the setpci command and it worked. However, I decided not to go this route because I wanted to maximize my already crippled 3D graphics performance, not additionally hinder it.

    I decided to try out a second higher-performance option. Instead of reducing my V550 PCI bus latency, I increased the PCI latency of all my devices to the relatively high value of 176 (devices normally default to somewhere around 32, except for my V550 which defaulted to above 200). Then I set the PCI bus latency of my latency-sensitive devices to the maximum setting, 248. This solved the problem, as I had hoped, by allowing my sound card to burst relatively huge chunks of data across the bus in one go, allowing it to maximize its use of the bus and avoid buffer-underrun conditions. At the same time, my other devices could also transmit data in chunks that were small enough not to hog the bus, but large enough to use the bus efficiently. I was particularly pleased with this solution because I was able to solve my audio problem while at the same time increasing the effective bandwidth of my development machine's PCI bus. Here's the excerpt from my system startup scripts that did the trick:


    #"open up" the PCI bus by allowing fairly long bursts for all devices, increasing performance
    setpci -v -d *:* latency_timer=b0

    #maximize latency timers for network and audio, allowing them to transmit
    #more data per burst, preventing buffer over/underrun conditions

    setpci -v -s 00:0f.0 latency_timer=ff
    setpci -v -s 00:0e.0 latency_timer=ff



    On the first line, the -d *:* option tells setpci to apply this setting to all PCI devices. The latency_timer=b0 option sets the timer to 176 ("b0" is hexadecimal for 176.). the -s options on the last two lines specify the PCI device that will be affected by PCI bus/slot and function, rather than by vendor and device ID. These are the first numbers listed for each device when you type lspci. The ff value specifies a latency timer setting of 256, which is rounded down to 248 by setpci. If you're experiencing a PCI latency timer-related issue, you'll need to experiment with lspci and setpci to find the optimal values for your system. If your hardware can handle it, larger latency timer values are best.
    ______________________________
    Life is to short for reboots

Lesezeichen

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •