32 data transfer

  • Thread starter Thread starter Alb
  • Start date Start date
A

Alb

Hi All, I have a P4P800 SE MB, in the BIOS-IDE configuration there the
parameter : "32Bit Data Transefert . Disabled"
Can some explain what is it ?

Thanks
 
"Alb" said:
Hi All, I have a P4P800 SE MB, in the BIOS-IDE configuration there the
parameter : "32Bit Data Transefert . Disabled"
Can some explain what is it ?

Thanks
Click to expand...

That setting controls the performance of PIO data transfers. The
transfers can either be 16 bit, across the IDE cable, or can be
32 bit. Most people do not use PIO transfer for their disk
drives, so the setting is not that important. PIO transfer mode
only delivers ~4MB/sec, while the DMA transfer modes can do a
lot better than that.

Don't worry about it. Set it to 32 bit if you want, but I don't
see a real incentive to change it.

http://www.rojakpot.com/default.aspx?location=8&var1=0&var2=3

Paul
 
Paul said:
That setting controls the performance of PIO data transfers. The
transfers can either be 16 bit, across the IDE cable, or can be
32 bit. Most people do not use PIO transfer for their disk
drives, so the setting is not that important. PIO transfer mode
only delivers ~4MB/sec, while the DMA transfer modes can do a
lot better than that.

Don't worry about it. Set it to 32 bit if you want, but I don't
see a real incentive to change it.

http://www.rojakpot.com/default.aspx?location=8&var1=0&var2=3
Click to expand...
You are misunderstanding what is being said.
The IDE cable, only has 40 wires in all (latter cables add another 40
earth connetions, but they are not used for signalling), which does not
allow enough wires for a '32bit' data path, and control. The transfer
'width' to the drives, always remains the same (16bits). The change
affects how the motherboard IDE controller transfers the data to the
processor, _not_ the transfers across the cable as such. The IDE
controller is adjusted to combine two 16bit reads from the HD, into a
single 32bit transfer to the processor, as a single transaction.
The 32bit transfer mode, can cause problems with some chipsets (most
noticeably older Via units), and especially with OS's like NT.
If working correctly, it can speed up the overall PCI bus performance a
little, but unless you are sure that the OS you are using, and the chipset
involved are OK, it can be dangerous. If you want to try it, use a
temproary HD, and test on this, before using it 'for real'.

Best Wishes
 
"Roger Hamlett" said:
You are misunderstanding what is being said.
The IDE cable, only has 40 wires in all (latter cables add another 40
earth connetions, but they are not used for signalling), which does not
allow enough wires for a '32bit' data path, and control. The transfer
'width' to the drives, always remains the same (16bits). The change
affects how the motherboard IDE controller transfers the data to the
processor, _not_ the transfers across the cable as such. The IDE
controller is adjusted to combine two 16bit reads from the HD, into a
single 32bit transfer to the processor, as a single transaction.
The 32bit transfer mode, can cause problems with some chipsets (most
noticeably older Via units), and especially with OS's like NT.
If working correctly, it can speed up the overall PCI bus performance a
little, but unless you are sure that the OS you are using, and the chipset
involved are OK, it can be dangerous. If you want to try it, use a
temproary HD, and test on this, before using it 'for real'.

Best Wishes
Click to expand...

No, I'm not misunderstanding the combining of two 16 bit
data transfers on the cable, to a 32 bit staging register
in the Southbridge. I have looked at the cable interface
specification before, and am aware of the interface. I
didn't feel explaining that would help the OP in any way.
It is also stated in the Rojakpot entry, for what it is
worth.

There is even a description of this in the ICH5 datasheet.

"5.16.1.5 PIO 32-Bit IDE Data Port Accesses

A 32-bit PCI transaction run to the IDE data address (01F0h
primary, 0170h secondary) results in two back to back 16-bit
transactions to the IDE data port. The 32-bit data port feature
is enabled for all timings, not just enhanced timing. For compatible
timings, a shutdown and startup latency is incurred between the
two, 16-bit halves of the IDE transaction. This guarantees that
the chip selects are deasserted for at least two PCI clocks
between the two cycles."

I don't think anyone intentionally runs in PIO mode, and
that should be reason enough not to bother changing the
setting.

Looking in the Microsoft KB, I do see mention of a problem
with NT 3.51 and a hot fix being in the works. So I suppose
someone running raw 3.51 could be endangered by the setting.
Thanks for pointing that out, I'll remember that the next
time :-)

Paul
 
Paul said:
No, I'm not misunderstanding the combining of two 16 bit
data transfers on the cable, to a 32 bit staging register
in the Southbridge. I have looked at the cable interface
specification before, and am aware of the interface. I
didn't feel explaining that would help the OP in any way.
It is also stated in the Rojakpot entry, for what it is
worth.
Click to expand...
You do though say specifically that "transfers can be 16bit across the IDE
cable, or can be 32bit". This is simply wrong... :-)
There is even a description of this in the ICH5 datasheet.

"5.16.1.5 PIO 32-Bit IDE Data Port Accesses

A 32-bit PCI transaction run to the IDE data address (01F0h
primary, 0170h secondary) results in two back to back 16-bit
transactions to the IDE data port. The 32-bit data port feature
is enabled for all timings, not just enhanced timing. For compatible
timings, a shutdown and startup latency is incurred between the
two, 16-bit halves of the IDE transaction. This guarantees that
the chip selects are deasserted for at least two PCI clocks
between the two cycles."

I don't think anyone intentionally runs in PIO mode, and
that should be reason enough not to bother changing the
setting.

Looking in the Microsoft KB, I do see mention of a problem
with NT 3.51 and a hot fix being in the works. So I suppose
someone running raw 3.51 could be endangered by the setting.
Thanks for pointing that out, I'll remember that the next
time :-)

Paul
Click to expand...

Best Wishes
 
Back
Top