![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
-
Some users have recently had their accounts hijacked. It seems that the now defunct EVGA forums might have compromised your password there and seems many are using the same PW here. We would suggest you UPDATE YOUR PASSWORD and TURN ON 2FA for your account here to further secure it. None of the compromised accounts had 2FA turned on.
Once you have enabled 2FA, your account will be updated soon to show a badge, letting other members know that you use 2FA to protect your account. This should be beneficial for everyone that uses FSFT.
enabling dma?
- Thread starter altec
- Start date
Ice Czar
Inscrutable
- Joined
- Jul 8, 2001
- Messages
- 27,174
Start > Run > (type) devmgmt.msc > IDE ATA/ATAPI controllers > Primary IDE Channel > Advanced Settings > Current Mode Of Transfer Device 0 should be Ultra DMA Mode
if not verify you have an 80 wire 40 pin IDE cable and that the Transfer mode in that window is set to DMA if available, repeat for the Secondary IDE Channel (both devices if applicable)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cut and paste 101
Optimizing Physical Configuration
being on the same channel there are a few considerations
IDE\ATA\ATAPI is sequential
meaning first the HDD reads a part of the file until the HDD's Cache is full then writes it to the Second HDD,
then that repeats each taking its own turn
then its unlikely its reading the file from a single location, its probably fragmented, and when it writing it, its also writing it to multiple locations, that introduces the latency and access times of both drives into it
if your going to be transfering alot of data inbetween two HDDs on a regular basis, its best if they are on their own channels, writing from a HDD to a Optical drive is alot better, the optical can only deal with a maximum of 33MB/s Burst (UDMA mode2) whereas the HDD is probably at UDMA mode5 100MB/s burst (50>30MB/s Sustained), in short the sequential issues arent enought to effect the burn speed with modern software (and reads arent really an issue either) both cant saturate the bus
of course those are just interface speeds and are not the sole consideration of HDD performance > As the Disc Spins @ Lost Circuits
there is a myth about putting optical drives on the same channel as HDDs, it is just that a myth, but it keeps getting reinforced by the way Windows deals with ATA\ATAPI issues
basically with Independent Device Timing two devices (master\slave) both transfer their data at their own highest speed, but, they both either have to be PIO (which is glacially slow) or UDMA, if one defaults to PIO because of some issue, Windows will default the other as well. There was a time when CDROMs where only PIO, and HDDs where DMA, for that period of history you didnt want to share a channel, but modern opticals are UDMA mode2 so there is rarely any issue
some of the reasons a device might default to PIO
DMA Mode for ATA/ATAPI Devices in Windows XP
IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur
however if possible it is ideal
(for data integrity if nothing else)
to have each device as a master on its own channel
whenever possible consider from what source to what target the large files are being transfer on a regular basis,
and try to adapt your physical configuration to accommodate that
if not verify you have an 80 wire 40 pin IDE cable and that the Transfer mode in that window is set to DMA if available, repeat for the Secondary IDE Channel (both devices if applicable)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
cut and paste 101
Optimizing Physical Configuration
being on the same channel there are a few considerations
IDE\ATA\ATAPI is sequential
meaning first the HDD reads a part of the file until the HDD's Cache is full then writes it to the Second HDD,
then that repeats each taking its own turn
then its unlikely its reading the file from a single location, its probably fragmented, and when it writing it, its also writing it to multiple locations, that introduces the latency and access times of both drives into it
if your going to be transfering alot of data inbetween two HDDs on a regular basis, its best if they are on their own channels, writing from a HDD to a Optical drive is alot better, the optical can only deal with a maximum of 33MB/s Burst (UDMA mode2) whereas the HDD is probably at UDMA mode5 100MB/s burst (50>30MB/s Sustained), in short the sequential issues arent enought to effect the burn speed with modern software (and reads arent really an issue either) both cant saturate the bus
of course those are just interface speeds and are not the sole consideration of HDD performance > As the Disc Spins @ Lost Circuits
there is a myth about putting optical drives on the same channel as HDDs, it is just that a myth, but it keeps getting reinforced by the way Windows deals with ATA\ATAPI issues
basically with Independent Device Timing two devices (master\slave) both transfer their data at their own highest speed, but, they both either have to be PIO (which is glacially slow) or UDMA, if one defaults to PIO because of some issue, Windows will default the other as well. There was a time when CDROMs where only PIO, and HDDs where DMA, for that period of history you didnt want to share a channel, but modern opticals are UDMA mode2 so there is rarely any issue
some of the reasons a device might default to PIO
DMA Mode for ATA/ATAPI Devices in Windows XP
IDE ATA and ATAPI Disks Use PIO Mode After Multiple Time-Out or CRC Errors Occur
however if possible it is ideal
(for data integrity if nothing else)
to have each device as a master on its own channel
whenever possible consider from what source to what target the large files are being transfer on a regular basis,
and try to adapt your physical configuration to accommodate that
I had this issue with my ATI tv program as well. Everything said that DMA was enabled, but the video was all jerky and jumpy. What I did was delete the primary and secondary IDE channels. Then when I re-booted, the channels were re-installed and all was well.