Re: [opensuse-factory] hdparm
-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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] hdparm
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=RWT01170100 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] hdparm
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=RWT01170100 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] hdparm
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. -- Regards, Rajko. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] hdparm
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. hdparm is for the old IDE driver, sdparm is the one. # rpm -qf /sbin/sdparm scsi-1.7_2.36_1.22_0.18_0.99_0.91-44 There is also a manpage. sdparm -al /dev/sda for a good description of the bits. 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [opensuse-factory] hdparm
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=RWT01170100 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
