On Sunday 06 May 2007 17:51, Donn Washburn wrote:
Rajko M. wrote:
On Sunday 06 May 2007 13:15, Donn Washburn wrote:
Has anyone noticed this problem? It maybe a problem with hdparm dealing with the sda drive and not hda
Can you give output of hdparm that is making trouble to you. The transfer rate of 66 interface is lower than the 66 MB/s. How much lower depends on many factors.
Just trying to change the to 32 (1) bit from the default 16 (0) # hdparm -c1 /dev/sda /dev/sda: setting 32-bit IO_support flag to 1 HDIO_SET_32BIT failed: Invalid argument IO_support = 0 (default 16-bit) #
It seems to be a "sda" related issue and not hdparm. It happens on three different machine running 10.3Alpha2
Any more questions let me know
I did also upgrade hdparm in a effort to see if it was hdparm or the sda issue
I guess that you found Sid's mail. The sdparm is not applicable. You said that they are IDE drives on older 500 MHz system, so hdparm should be right application. I'm not familiar with hdparm internals so I ran test on my older computer with 10.3 alpha 1 and it shows the same error, although I used symlink hda that points to sda ie. solving naming: hdparm -c1 /dev/hda That might be because the device ID major is changed from 3 to 8. Which probably confuses hdparm. The hdparm -i /dev/hda claims that parameter is not applicable for the device. The same works fine in 10.2. The speed test hdparm -t /dev/hda shows speed of 55 MB/s for ATA 100 drive, which seems to be right. For details on transfer rates http://www.realworldtech.com/page.cfm?ArticleID=RWT011701000000 The difference between 16 and 32 transfer is non existent on older machine, both show 55 MB/s. The reason is probably oldfashioned parallel cable that has 16 lines for data transfer and using 32 bit brings no improvement, except on very old systems where CPU load is 1/2 if it can send 32 bits to controller at once. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M. wrote:
On Sunday 06 May 2007 17:51, Donn Washburn wrote:
Rajko M. wrote:
On Sunday 06 May 2007 13:15, Donn Washburn wrote:
Has anyone noticed this problem? It maybe a problem with hdparm dealing with the sda drive and not hda Can you give output of hdparm that is making trouble to you. The transfer rate of 66 interface is lower than the 66 MB/s. How much lower depends on many factors. Just trying to change the to 32 (1) bit from the default 16 (0) # hdparm -c1 /dev/sda /dev/sda: setting 32-bit IO_support flag to 1 HDIO_SET_32BIT failed: Invalid argument IO_support = 0 (default 16-bit) #
It seems to be a "sda" related issue and not hdparm. It happens on three different machine running 10.3Alpha2
Any more questions let me know
I did also upgrade hdparm in a effort to see if it was hdparm or the sda issue
I guess that you found Sid's mail. The sdparm is not applicable.
You said that they are IDE drives on older 500 MHz system, so hdparm should be right application. I'm not familiar with hdparm internals so I ran test on my older computer with 10.3 alpha 1 and it shows the same error, although I used symlink hda that points to sda ie. solving naming: hdparm -c1 /dev/hda That might be because the device ID major is changed from 3 to 8. Which probably confuses hdparm. The hdparm -i /dev/hda claims that parameter is not applicable for the device. The same works fine in 10.2.
The speed test hdparm -t /dev/hda shows speed of 55 MB/s for ATA 100 drive, which seems to be right. For details on transfer rates http://www.realworldtech.com/page.cfm?ArticleID=RWT011701000000
The difference between 16 and 32 transfer is non existent on older machine, both show 55 MB/s. The reason is probably oldfashioned parallel cable that has 16 lines for data transfer and using 32 bit brings no improvement, except on very old systems where CPU load is 1/2 if it can send 32 bits to controller at once.
I did mention this to Donn in a private email, then we got into the subject of the difference between cables. OFF TOPIC:- One thing I read said, in order to minimise crosstalk, that all 80 wires are connected at the blue end, but 40 connect to the grey connector, the other 40 go to the black connector. However, trying to verify it using a DVM, I got shorts registered on the same pins on both the grey and the black connectors. One suggestion from Donn is that they use 40 pins and 40 earths commoned up at the blue (motherboard) end. This seems likely as shorts on a number of pins can be measured on the connectors, though I haven't done enough to verify how they are distributed. Then there is the connundrum as to how the whole thing looks electrically when connected to devices and a motherboard. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Monday 07 May 2007 09:43, Sid Boyce wrote:
Rajko M. wrote: ...
The speed test hdparm -t /dev/hda shows speed of 55 MB/s for ATA 100 drive, which seems to be right. For details on transfer rates http://www.realworldtech.com/page.cfm?ArticleID=RWT011701000000
The difference between 16 and 32 transfer is non existent on older machine, both show 55 MB/s. The reason is probably oldfashioned parallel cable that has 16 lines for data transfer and using 32 bit brings no improvement, except on very old systems where CPU load is 1/2 if it can send 32 bits to controller at once.
I did mention this to Donn in a private email, then we got into the subject of the difference between cables.
OFF TOPIC:- One thing I read said, in order to minimise crosstalk, that all 80 wires are connected at the blue end, but 40 connect to the grey connector, the other 40 go to the black connector. However, trying to verify it using a DVM, I got shorts registered on the same pins on both the grey and the black connectors. One suggestion from Donn is that they use 40 pins and 40 earths commoned up at the blue (motherboard) end. This seems likely as shorts on a number of pins can be measured on the connectors, though I haven't done enough to verify how they are distributed. Then there is the connundrum as to how the whole thing looks electrically when connected to devices and a motherboard. Regards Sid.
Grounds commoned on motherboard side will show shorts on the other end too. Wires are to short to see 2 wire lengths resistance with DMV, so it will appear as short on both ends. They had to use existing ground pins on 40 pins connector and they needed 40 extra wires between existing signal wires to prevent crosstalk. More: http://en.wikipedia.org/wiki/Advanced_Technology_Attachment I never tried to find out exact reasons for the one side grounding. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M. wrote:
Grounds commoned on motherboard side will show shorts on the other end too. Wires are to short to see 2 wire lengths resistance with DMV, so it will appear as short on both ends. They had to use existing ground pins on 40 pins connector and they needed 40 extra wires between existing signal wires to prevent crosstalk. More: http://en.wikipedia.org/wiki/Advanced_Technology_Attachment
I never tried to find out exact reasons for the one side grounding.
I will remind everyone that grounding in multiple places is a bad idea. Reason is what is known as a "ground loops". It ends up as hum or a potential voltage differences - worse case heat. The idea of center point ground means only grounded at one single point or at least the additional 40 wires connected at the computer MB end and open on the IDE Drive end. It can be used as a shield from adjacent signals coming from the stray magnetic fields created around a conductor by current flowing through a wire. If connected at both ends my guess it would cause interference with the shifting of data (the reason SATA is better and faster). If they are NOT connected at either end - bad idea! All of those wires that are floating would be about 144Mhz - 2M HAM length and with my 50 Watt Kenwood radio I could likely destroy your data day. Just think 40 antennas. Grounding them at one end is good to stop this effect. -- 73 de Donn Washburn 307 Savoy Street Email: " n5xwb@hal-pc.org " Sugar Land, TX 77478 LL# 1.281.242.3256 Ham Callsign N5XWB HAMs : " n5xwb@arrl.net " VoIP via Gizmo: bmw_87kbike / via Skype: n5xwbg BMW MOA #: 4146 - Ambassador " http://counter.li.org " #279316 Did you know? The transistor was invented by three white men. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M. wrote:
On Monday 07 May 2007 09:43, Sid Boyce wrote:
Rajko M. wrote: ...
The speed test hdparm -t /dev/hda shows speed of 55 MB/s for ATA 100 drive, which seems to be right. For details on transfer rates http://www.realworldtech.com/page.cfm?ArticleID=RWT011701000000
The difference between 16 and 32 transfer is non existent on older machine, both show 55 MB/s. The reason is probably oldfashioned parallel cable that has 16 lines for data transfer and using 32 bit brings no improvement, except on very old systems where CPU load is 1/2 if it can send 32 bits to controller at once. I did mention this to Donn in a private email, then we got into the subject of the difference between cables.
OFF TOPIC:- One thing I read said, in order to minimise crosstalk, that all 80 wires are connected at the blue end, but 40 connect to the grey connector, the other 40 go to the black connector. However, trying to verify it using a DVM, I got shorts registered on the same pins on both the grey and the black connectors. One suggestion from Donn is that they use 40 pins and 40 earths commoned up at the blue (motherboard) end. This seems likely as shorts on a number of pins can be measured on the connectors, though I haven't done enough to verify how they are distributed. Then there is the connundrum as to how the whole thing looks electrically when connected to devices and a motherboard. Regards Sid.
Grounds commoned on motherboard side will show shorts on the other end too. Wires are to short to see 2 wire lengths resistance with DMV, so it will appear as short on both ends. They had to use existing ground pins on 40 pins connector and they needed 40 extra wires between existing signal wires to prevent crosstalk. More: http://en.wikipedia.org/wiki/Advanced_Technology_Attachment
I never tried to find out exact reasons for the one side grounding.
Thanks for the URL, excellent description. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2007-05-07 at 20:42 -0500, Rajko M. wrote:
I never tried to find out exact reasons for the one side grounding.
Loop currents. They would form 40 independent loops, and a loop in a variable magnetic field, such as induced by the varying currents in the adjacent cables, will produce currents. Instead of a shield you would end with an antenna, kind of. - -- Cheers, Carlos E. R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFGQGeWtTMYHG2NR9URAnBBAJ9lpTjJCs+EDlQKwY1aQNvWpbAhrgCeIxBE FAJ9GpwTGhzGcopNIbTbSWk= =um5H -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
Rajko M. wrote: [...]
You said that they are IDE drives on older 500 MHz system, so hdparm should be right application. I'm not familiar with hdparm internals so I ran test on my older computer with 10.3 alpha 1 and it shows the same error, although I used symlink hda that points to sda ie. solving naming: hdparm -c1 /dev/hda That might be because the device ID major is changed from 3 to 8. Which probably confuses hdparm. The hdparm -i /dev/hda claims that parameter is not applicable for the device. The same works fine in 10.2.
The cause is the transition to libata IDE drivers. Libata currently doesn't support DMA mode change. See https://bugzilla.novell.com/show_bug.cgi?id=264681#c14 for details. Ladislav -- Best Regards Ladislav Slezák Yast Developer ------------------------------------------------------------------------ SUSE LINUX, s.r.o. e-mail: lslezak@suse.cz Lihovarská 1060/12 tel: +420 284 028 960 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http://www.suse.cz/ --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
On Thursday 10 May 2007 02:24, Ladislav Slezak wrote:
The cause is the transition to libata IDE drivers. Libata currently doesn't support DMA mode change. See https://bugzilla.novell.com/show_bug.cgi?id=264681#c14 for details.
Thanks for the fedback Ladislav. I had similar error messages long time ago, but it was hardware that didn't support certain functionality. -- Regards, Rajko. --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory+help@opensuse.org
participants (5)
-
Carlos E. R. -
Donn Washburn -
Ladislav Slezak -
Rajko M. -
Sid Boyce