P2b: PCI Latency Timer(32 PCI Clock) ??
J.K.
the P2b bios ? Any recommended performance settings?
--
Julian Kreisler
http://www.kreisler-art.com
J.K.
Sam Seller
I don't know either...just says 32 is high performance setting in the
manual.
J.K. wrote in message <71in0v$kb8$1...@news.netway.at>...
Carter Buck
> Everyone else who replied to this post was misled... :)
>
> The PCI Latency Timery is almost exactly what it sounds like... It's the
> setting to increase or decrease the time the PCI Bus waits for the ISA bus
> to maintain compatibility. Basically, it slows the PCI Bus down or bridles
> it so that you can use ISA Peripherals in conjunction with PCI Peripherals.
>
> I have no ISA Peripherals so I changed the setting to 0 and witnessed a
> slight performance increase. Just FYI...
>
The PCI Latency setting represents the guaranteed time slice, measured in
PCI clocks, in which the PIIX4E, as a busmaster, can burst data onto the
PCI bus on behalf of the USB and two IDE controllers.
Carter Buck
cb...@california.com
cb...@global.california.com
"J.K." <whok...@netway.at> wrote:
> Can somebody inlighten me on this bios setting under PNP & PCI Setup in
> the P2b bios ? Any recommended performance settings?
>
busmaster on behalf of the IDE and USB controllers,
although I haven't tested P2B BIOS to confirm this. My
inclination would be to try the same setting at which the
system controller latency is set at, which I believe is
64 on the P2B series. Download PCILIST from
www.entechtaiwan.com, it will show the system controller
latency setting, then try setting PIIX4E latency to match.
Carter Buck
cb...@california.com
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Jon Birchmore
here), this controls how many clock cycles a Bus Mastering device can
control the PCI bus. I have a Asus Tx-97 K6-200 64Mb Quantum Fireball ST
4.3 with WIN 98 and was very dissappointed with the IDE Bus Master Drivers
performance (H.D Tach testing), I had very low burst transfer rates around
12mb/sec. I found I had at some point, in my poking around the bios, set
the PCI latency to 1. Setting the PCI latency to 64 gives me burst transfer
rates of around 27mb/s and a CPU utilization of 19% I don't have the
numbers for 32 sorry. I was so pleased to see my UDMA IDE drive finally
performing as expected I left it at 64.
Hope this might help.
Jon Birchmore
--
Remove nospam from address to respond via e-mail.
J.K. wrote in message <71in0v$kb8$1...@news.netway.at>...
>Can somebody inlighten me on this bios setting under PNP & PCI Setup in
>the P2b bios ? Any recommended performance settings?
>
Trevor Cobb
The PCI Latency Timery is almost exactly what it sounds like... It's the
setting to increase or decrease the time the PCI Bus waits for the ISA bus
to maintain compatibility. Basically, it slows the PCI Bus down or bridles
it so that you can use ISA Peripherals in conjunction with PCI Peripherals.
I have no ISA Peripherals so I changed the setting to 0 and witnessed a
slight performance increase. Just FYI...
Trevor
ROY SHARIF M. SISON
> On Mon, 2 Nov 1998, Trevor Cobb wrote:
>
> > Everyone else who replied to this post was misled... :)
> >
> > The PCI Latency Timery is almost exactly what it sounds like... It's the
> > setting to increase or decrease the time the PCI Bus waits for the ISA bus
> > to maintain compatibility. Basically, it slows the PCI Bus down or bridles
> > it so that you can use ISA Peripherals in conjunction with PCI Peripherals.
> >
> > I have no ISA Peripherals so I changed the setting to 0 and witnessed a
> > slight performance increase. Just FYI...
> >
> The PCI Latency setting represents the guaranteed time slice, measured in
> PCI clocks, in which the PIIX4E, as a busmaster, can burst data onto the
> PCI bus on behalf of the USB and two IDE controllers.
>
Does that mean that a higher value will make the data transfer rate faster? or is
it the opposite?....on my TX97-X, I set the PCI Latency Timer at 255......is
there a software/utility that could be downloaded to check the difference?
Thanks.
Roy
cau...@earthlink.com
Companion Handbook that accompanies the Tweak-It bios tweaking
program (which by the way is really cool):
Latency Timer (PCI Clocks)
Controls the length of time an agent can hold the PCI bus when
another has requested it, so it guarantees a PCI card access
within a specified number of clocks.
Since the PCI bus runs faster than ISA, the PCI bus must be
slowed during interactions with it, so here you can define how
long the PCI bus will delay for a transaction between the given
PCI slot and the ISA bus. This number is dependent on the PCI
master device in use and varies from 0 to 255.
AMI defaults to 66, but 40 clocks is a good place to start at
33MHz (Phoenix). The shorter the value, the more rapid access to
the bus a device gets, with better response times, but the lower
becomes the effective bandwidth and hence data throughput.
Normally, leave this alone, but you could set it to a lower value
if you have latency sensitive cards (e.g. audio cards and/or
network cards with small buffers). Increase slightly if I/O
sensitive applications are being run.
Hope this helps,
Clay
ppanbura
>
> Does that mean that a higher value will make the data transfer rate
faster? or is
> it the opposite?....on my TX97-X, I set the PCI Latency Timer at
255......is
> there a software/utility that could be downloaded to check the
difference?
What it means is that it allow one PCI agent to hog the bus that
long if it would do that. There are some tradeoffs here. In some
PCI device it is designed to dump data in chunk say using 64 clocks.
If the latency timer is set lower than this, this PCI device would have
to break the transaction into 2 transactions. This is inefficient for
such
the device since to get on to the bus take arbitration cycle time and
etc.
In the opposite end, if there are multiple devices need the bus, then
setting the latency timer a high value means other devices has to
wait for so long. If it does not have internal buffer to absorb this
latency, then lost of data may occur.
Regards,
-Pandit
Bruce Chastain
>Since the PCI bus runs faster than ISA, the PCI bus must be
>slowed during interactions with it, so here you can define how
>long the PCI bus will delay for a transaction between the given
>PCI slot and the ISA bus. This number is dependent on the PCI
>master device in use and varies from 0 to 255.
Just to clarify, it doesn't just affect just ISA card access. As a result
of a BIOS bug, we discovered that the PCI latency setting has a major
negative impact on the HD Tach IDE drive transfer rate results when
incorrectly set to 0. That's pure PCI.
Bruce.
J.K.
--
Julian Kreisler
http://www.kreisler-art.com
cb...@global.california.com schrieb in Nachricht
<71j3t3$q15$1...@nnrp1.dejanews.com>...
>In article <71in0v$kb8$1...@news.netway.at>,
> "J.K." <whok...@netway.at> wrote:
>> Can somebody inlighten me on this bios setting under PNP & PCI Setup
in
>> the P2b bios ? Any recommended performance settings?
>>
J.K.
Bruce Chastain
<71lrhh$jed$1...@nnrp1.dejanews.com>...
>In article <71k5q1$p...@news9.noc.netcom.net>,
> "Bruce Chastain" <bcha...@XNOSPAMXcsi.com> wrote:
>>
>> Just to clarify, it doesn't just affect just ISA card access. As a
result
>> of a BIOS bug, we discovered that the PCI latency setting has a major
>> negative impact on the HD Tach IDE drive transfer rate results when
>> incorrectly set to 0. That's pure PCI.
>>
>each have their own latency timer settings. I don't have a P2B to
>test, but in the TX97 series and P2L97 series the BIOS selection
>alters both timer settings, and does not affect latency settings
>for the system controller and other PCI devices.
>
>Carter Buck
>cb...@california.com
The P2B only has one setting and the book says that it should be set for 32.
Some people, and only some people have experienced the value reseting back
to 0 when the BIOS defaults are reset. I tried exactly the same operation
that caused theirs to reset back to 0 and mine stuck at the book 32. All on
the exact same BIOS version.
Even if you don't accept the ASUS book value as the correct default,
everyone's BIOS setttings should go back to the SAME default when reset.
That makes it a bug to me.
Anyway, the point of my post was just to expand on the ISA comments that
were being made.
Bruce.
Bruce Chastain
> With all the
>arguing on what the Latency setting means, I changed it to various
>settings (haven't fully tested the optimum setting yet, but here's
>what I have. C: is a Maxtor 6.8gb drive, with Ultra DMA enabled. D:
>is a Seagate Medalist 3.2gb Drive.
>
>Setting C: MB/sec C: avg D: MB/sec D: Avg Seek
> Seek
>0 7.4 8.5 4.6 9.0
>64 7.1 8.5 4.8 8.9
>255 1.7 8.7 3.3 11.7
My results with my P2B and Maxtor drives are different and matches what I've
seen reported by others. I'm using HD Tach because it's the only program
I've seen which seems to do a good job of measuring the UDMA read burst
speed, which is much faster that the average transfer rate. A system which
can keep up with the adverage transfer rate, may not be capable of the max
read burst rate as the following results show:
Setting Read Burst Rate Ave Read rate
0 12.8MB/sec 11.4MB/sec
32 24.2MB/sec 11.5MB/sec
64 24.2MB/sec 11.5MB/sec
255 24.2MB/sec 11.5MB/sec
The average read rate never changes, but the read burst rate drops
dramatically at a PCI Latency setting of 0.
Anyway, the book setting is 32 which works best for me.
Bruce.
Carter Buck
> The P2B only has one setting and the book says that it should be set for 32.
> Some people, and only some people have experienced the value reseting back
> to 0 when the BIOS defaults are reset. I tried exactly the same operation
> that caused theirs to reset back to 0 and mine stuck at the book 32. All on
> the exact same BIOS version.
>
> Even if you don't accept the ASUS book value as the correct default,
> everyone's BIOS setttings should go back to the SAME default when reset.
>
> That makes it a bug to me.
>
> Anyway, the point of my post was just to expand on the ISA comments that
> were being made.
>
Yes, I didn't recall the zero default value as being what you were
referring to until after posting, and that is a bug. But that wasn't the
point of my post either, except to say that the affect on IDE was not a
bug. Mainly I was pointing out that in the BIOS's I've looked at, the USB
and IDE controller latency settings were the only values changed by the
BIOS setting.
I do question whether some of the ISA comments are more toward PCI 2.0
rather than PCI 2.1, which uses the delayed transaction and passive
release mechanisms to reach the target latencies that are problematic
with the ISA bus. But, I don't have the PCI specification to look at, and
it costs $25 plus shipping and handling...
Carter Buck
cb...@california.com
Carter Buck
> Just a few notes to clarify things to everyone. With all the
> arguing on what the Latency setting means, I changed it to various
> settings (haven't fully tested the optimum setting yet, but here's
> what I have. C: is a Maxtor 6.8gb drive, with Ultra DMA enabled. D:
> is a Seagate Medalist 3.2gb Drive.
>
Another note to save testing of various values, use multiples of 16, as
the lower 4 bits of the number are ignored.
Carter Buck
cb...@california.com
cb...@global.california.com
The TX and LX chipsets use the PIIX4, and the EX, LX, and GX
chipsets use the PIIX4E.
cb...@global.california.com
"J.K." <whok...@netway.at> wrote:
> Thanks a lot, but what does the "E" in PIIX4E stand for?
>
It's Intel's designation to identify later revisions of the PIIX4.
The TX and LX chipsets use the PIIX4, and the EX, BX, and GX
cb...@global.california.com
"Bruce Chastain" <bcha...@XNOSPAMXcsi.com> wrote:
>
> Just to clarify, it doesn't just affect just ISA card access. As a result
> of a BIOS bug, we discovered that the PCI latency setting has a major
> negative impact on the HD Tach IDE drive transfer rate results when
> incorrectly set to 0. That's pure PCI.
>
I don't consider it to be a BIOS bug. The USB and IDE controllers
each have their own latency timer settings. I don't have a P2B to
test, but in the TX97 series and P2L97 series the BIOS selection
alters both timer settings, and does not affect latency settings
for the system controller and other PCI devices.
Carter Buck
Nikos Tabakis
has ACPI bugs. The PIIX4E chip is found on the BX chipset (and
possibly the LX, I'm not sure) and it's supposedly a bugfree version.
Maybe the E stands for enhanced.
Regards
Nikos Tabakis
J.K. wrote in message <71kbho$s6c$1...@news.netway.at>...
>Thanks a lot, but what does the "E" in PIIX4E stand for?
>
John H. Guillory
<bcha...@XNOSPAMXcsi.com> wrote:
>cau...@earthlink.com wrote in message <363D8647...@earthlink.com>...
>>Since the PCI bus runs faster than ISA, the PCI bus must be
>>slowed during interactions with it, so here you can define how
>>long the PCI bus will delay for a transaction between the given
>>PCI slot and the ISA bus. This number is dependent on the PCI
>>master device in use and varies from 0 to 255.
>
>
>Just to clarify, it doesn't just affect just ISA card access. As a result
>of a BIOS bug, we discovered that the PCI latency setting has a major
>negative impact on the HD Tach IDE drive transfer rate results when
>incorrectly set to 0. That's pure PCI.
Just a few notes to clarify things to everyone. With all the
arguing on what the Latency setting means, I changed it to various
settings (haven't fully tested the optimum setting yet, but here's
what I have. C: is a Maxtor 6.8gb drive, with Ultra DMA enabled. D:
is a Seagate Medalist 3.2gb Drive.
Setting C: MB/sec C: avg D: MB/sec D: Avg Seek
Seek
0 7.4 8.5 4.6 9.0
64 7.1 8.5 4.8 8.9
255 1.7 8.7 3.3 11.7
From the results, the majority of the settings only affected the
Seagate, but when set to 255, it shot my Maxtor down to pieces on the
transfer rate! I'd say from looking at the figures, 32 or 64 would be
a better setting, though this is only on my system, and only using
those two hard drives. I'm not sure if the Maxtor's capable of
handling worse settings than the seagate, or backwards, but the
results is there for those who are curious. BTW - the benchmarks are
done with Nuts & Bolts for Windows 3.1 and Windows'95 (I can't find a
version number)
Bruce Chastain
>Yes, I didn't recall the zero default value as being what you were
>referring to until after posting, and that is a bug. But that wasn't the
>point of my post either, except to say that the affect on IDE was not a
>bug.
Agreed.
>Mainly I was pointing out that in the BIOS's I've looked at, the USB
>and IDE controller latency settings were the only values changed by the
>BIOS setting.
Yes, also agreed. I'd not heard the ISA thing before.
>I do question whether some of the ISA comments are more toward PCI 2.0
>rather than PCI 2.1, which uses the delayed transaction and passive
>release mechanisms to reach the target latencies that are problematic
>with the ISA bus. But, I don't have the PCI specification to look at, and
>it costs $25 plus shipping and handling...
I don't have any ISA cards anymore (yea!) and I can't think of anyway to
test that. Anyway, it's pretty obvious that the setting does affect the IDE
controller and for my system, the book default 32 is the lowest value that
gives the best HD Tach results.
Bruce.
A Poster
This is a common misunderstanding of PCI and how it works.
In PCI systems, there is a tradeoff between the desire to achieve low latency and the desire to
achieve high bandwidth (throughput). High throughput is achieved by allowing devices to use long
burst transfers. Low latency is achieved by reducing the maximum burst transfer length.
A given PCI master introduces latency on PCI bus each time it uses the PCI bus to do a transaction.
This latency is a function of the behavior of both the master and the target device during the
transaction as well as the state of the masters GNT# signal. The bus command used, transaction
burst length, master data latency for each data phase, and the Latency Timer are the primary
parameters which control the masters behavior.
PCI is designed so that data transfers between a bus master and a target occur as register to
register transfers. Therefore bus masters typically do not insert wait states since they only
request transactions when they are prepared to transfer data (unless they are broken). Targets
typically have an initial access latency less than the 16 clock maximum allowed (this is simplified
since it really depends upon the trasaction type).
If a PCI master were allowed to burst indefinitely to a target which could absorb the data
indefinitely, then there would be no upper bound on the latency which a master could introduce into
a PCI system. However, the master Latency Timer provides a mechanism to constrain a master's tenure
on the bus (when other masters need to use the bus).
In effect, the Latency Timer controls the tradeoff between high throughput (higher Latency Timer
values) and low latency (lower Latency Timer values).
Following example borrowed from somewhere (can't remember) but it has been reformatted
For example, assuming an target initial latency of 8, then the Latency Timer expires during the 7th
data phase. The transaction completes with the 8th data phase. This means that a maximum of 32
bytes (assuming 32-bit transfers) are transferred during the burst transaction. The total PCI
clocks is 8 + (8-1) + 1 = 16 clocks. This yields a bandwidth (MB/s) of 32 bytes / (16 clock * 30
ns/clock) = 60MB/s. The latency is 16 * 30ns = 0.48us.
For a Latency Timer of 22 clocks, there are 16 data phases, resulting in 64 bytes being burst
transferred in 24 clocks yielding a 80MB/s throughput. The latency is 24 * 30ns = 0.72us.
For a Latency Timer of 38 clocks, there are 32 data phases, resulting in 128 bytes being burst
transferred in 40 clocks yielding a 96MB/s throughput. The latency is 40 * 30ns = 1.20us.
For a Latency Timer of 70 clocks, there are 64 data phases, resulting in 256 bytes being burst
transferred in 72 clocks yielding a 107MB/s throughput. The latency is 72 * 30ns = 2.16us.
Clearly showing that as the burst length increases the amount of data transferred increases and
hence the bandwidth. It also shows that the amount of data transferred doubles while the Latency
Timer increases by a lesser amount.
On the ASUS P2L97 BIOS 1005 the BIOS setting will configure add-in PCI devices as well as the IDE
and USB controllers with this value. Typically devices hardwire the bottom three bits of this
register to provide a 8 clock resolution. The PIIX4 has the IDE and USB bottom four bits hardwired
zero, so the resolution of these devices is only 16 clocks.
The PIIX4 PCI-to-ISA/EIO bridge does not have a Latency Timer register. The 2.1 revision of the PCI
specification requires much tighter controls on target and master latency. Targets must respond with
TRDY# or STOP# within 16 clocks of FRAME#, and masters must assert IRDY# within 8 PCI clocks for any
data phase. PCI cycles to or from ISA typically take longer than this. PIIX4 provides a programmable
delayed completion mechanism described in the PCI specification to meet the required target
latencies. This includes a Discard Timer which times out if a PCI Master with an outstanding delayed
transaction has not retried the transaction for greater than 2^15 PCI clocks.
The PIIX4 ISA bridge also support Guaranteed Access Time (GAT) mode, which will now violate the
spirit of the PCI specification. PIIX4 provides a programmable passive release mechanism to meet the
required master latencies. When passive release is enabled in PIIX4, ISA masters may see long delays
in accesses to any PCI memory, including the main DRAM array. The ISA GAT mode is not supported with
passive release enabled. ISA masters must honor IOCHRDY.
I think that in the P2L97 BIOS the "PCI 2.1 Support" option controls the support for the delayed
transaction and passive release mechanism. So, when "PCI 2.1 support" is enabled, this will disable
the ISA GAT mode which may slow down ISA devices.
See the PCI 2.1 and PCI 2.2 Specifcations available from the PCI Sig http://www.pcisig.com as well
as the 440LX AGPSet and PIIX4 datasheets available from Intel http://developer.intel.com
MindShare, Inc. also sells good computer architecture books for those who cannot purchase the
various specification documents http://www.mindshare.com
A. Poster
cau...@earthlink.com
Thanks.
Clay
A Poster wrote:
>
> This is a common misunderstanding of PCI and how it works.
<Lots of good info deleted>
Bruce Chastain
>
>This is a common misunderstanding of PCI and how it works.
Excellent! Thanks very much for posting all that!!
Bruce.