darry wrote on 2020-09-24, 03:26:

You are absolutely right ! […]
Show full quote

The Serpent Rider wrote on 2020-09-24, 02:37:

darry wrote on 2020-05-21, 22:08:

This is, again, in a P3 1400MHz 512K system with an i815ep/ICH2 ATA66 controller

ICH2 is ATA100 though.

You are absolutely right !

After installing the drivers from the installation CD of my industrial board and getting results consistent with ATA66 , I never bothered checking .
The results were as follows :
atto_ich2_jmd330_860evo.png

After reading your post and checking the datasheet, I downloaded and ran IATA_CD.EXE which updated my driver. I then ran a test which gave the following strange results . I also tried running a test with HDTACH, but that crashed the system with the new driver, so I rolled back .
atto_ata100.png

EDIT: I am using the same Jmicron IDE to SATA adapter that I was using with a Promise ULTRA133 TX2 and that was giving me about 90MB/second .

I also tried Intel Application Accelerator (version 2.2 I think) in both DEFAULT UDMA5 and forced UDMA4 modes . The same low read speed for larger block sizes was apparent and HDTACH also crashed the system . I also got some nice crosslinked files (that'swhat backups are for, 🤣).

I do not know if this is due to the Intel drivers not liking my IDE to SATA converter or my Samsung 860 EVO SSD or something else .

What I do know is that the Intel base inf driver that uses ESDI_506.PDR (patched for LBA48 using BHDD31) works fine at UDMA4 speeds with my adapter and SSD . It has normal read speeds, does not crash when using HDTACH and does not cause DATA corruption .

EDIT: Anybody have an idea why the base Intel driver that uses ESDI_506.PDR only does UDMA4 in my setup ?

EDIT2: I ordered a Startech IDE to SATA adapter, reportedly based on a Sunplus SPIF223A . I will see if that behaves differently .

darry wrote on 2020-09-24, 14:23:

I also tried Intel Application Accelerator (version 2.2 I think) in both DEFAULT UDMA5 and forced UDMA4 modes . The same low re […]
Show full quote

darry wrote on 2020-09-24, 03:26:

You are absolutely right ! […]
Show full quote

The Serpent Rider wrote on 2020-09-24, 02:37:

ICH2 is ATA100 though.

You are absolutely right !

After installing the drivers from the installation CD of my industrial board and getting results consistent with ATA66 , I never bothered checking .
The results were as follows :
atto_ich2_jmd330_860evo.png

After reading your post and checking the datasheet, I downloaded and ran IATA_CD.EXE which updated my driver. I then ran a test which gave the following strange results . I also tried running a test with HDTACH, but that crashed the system with the new driver, so I rolled back .
atto_ata100.png

EDIT: I am using the same Jmicron IDE to SATA adapter that I was using with a Promise ULTRA133 TX2 and that was giving me about 90MB/second .

I also tried Intel Application Accelerator (version 2.2 I think) in both DEFAULT UDMA5 and forced UDMA4 modes . The same low read speed for larger block sizes was apparent and HDTACH also crashed the system . I also got some nice crosslinked files (that'swhat backups are for, 🤣).

I do not know if this is due to the Intel drivers not liking my IDE to SATA converter or my Samsung 860 EVO SSD or something else .

What I do know is that the Intel base inf driver that uses ESDI_506.PDR (patched for LBA48 using BHDD31) works fine at UDMA4 speeds with my adapter and SSD . It has normal read speeds, does not crash when using HDTACH and does not cause DATA corruption .

EDIT: Anybody have an idea why the base Intel driver that uses ESDI_506.PDR only does UDMA4 in my setup ?

EDIT2: I ordered a Startech IDE to SATA adapter, reportedly based on a Sunplus SPIF223A . I will see if that behaves differently .

At this point, I am pretty convinced that UDMA 4 default in my setup is a BIOS limitation .
I have tried 3 different IDE to SATA adpters
- a Jmicron JMD330 based no-name adapter (may be branded, but not on the PCB, so I really don't know as I junked the box a long time ago)
- a Jmicron JM20330 based SinLoon branded adapter
- a Sunplus SPIF223A based Startech branded PATA2SATA3

All of them work fine in Windows 98 SE using the Intel default .inf "drivers" that rely on ESDI_506.PDR (I am using the BHDD31 patched version for LB48 support) and default to UDMA 4 (ATA66) once DMA is enabled .
All of them have comparable performance using either the aforementioned driver or Intel Application Accelerator (IAA) 2.3. See below an example when running ESDI_506.PDR based drivers :

All of them will only use UDMA 4 as a max when using UDMA2.SYS under DOS (even if /M5 is used)
All of them pass SMART (tested with Speedfan under Windows)
Only the Jmicron JMD330 and Jmicron JM20330 allow TRIM to work under DOS

Specifically when using Intel Application Accelerator (IAA) 2.3 :
All of them are unstable and can easily crash HDTACH 2.61 and/or generate corruption whether running at UDMA 5 or UDMA 4
All of them have weird slowdowns when reading at larger block sizes in ATTO (whether at UDMA 4 or UDMA 5) and are at best only about 10-15MB/second faster in UDMA 5 mode than UDMA 4 . Here is an example at UDMA 5 .

I have no idea why IAA is unstable on my setup, but even if it was reliable, I would not see much of an incentive to use it considering the limited write speed gains and significant read speed slowdowns .

I've been doing some benchmarking in DOS with Speedsys on a Shuttle AK39N v1.2 with the latest bios & Athlon XP 2600+ (Barton) CPU.

I tested the integrated IDE vs a Maxtor SATA150 TX2plus bus master PCI card equipped with a Promise PDC20375 controller.

I had expected the the integrated to match or surpass the Maxtor card if the storage devices were at the same transfer mode because the integrated controller is on 533Mhz Vlink instead of PCI.

Curiously, the Maxtor controller spends a lot of time crushing the integrated IDE.

Is this because of some sort of magic in the Promise PDC20375 controller or is it that the Maxtor card has much better BIOS?

Any tests I could try to verify assumptions?

I'll just drop a link here for cross-reference: SSD with winxp and ide adapter

Curiously, the Maxtor controller spends a lot of time crushing the integrated IDE.

Probably requires better integrated IDE like Nvidia nForce 2/3 (at least Nvidia boasted it) or Intel ICH5+ for a full picture. As we've already established, VIA/SIS chipsets weren't exactly top tier material, in regards to I/O performance.

I had an M7NCG handy. You were quite right. Nforce 2 demolishes the Via on all the benches throughput benchmarks that matter--

I guess that explains why the Via board + CPU was $7 on ebay. Not a collectors item.

Here's a comparison using the M2 -- PATA sled with a super cheapo SSD

IDE1 <ATA> BR 32G
Cylinders: 62037, Heads: 16, Sectors: 63 (29.82 GB)
Serial Number : 0000000000010000842
Firmware Revision : SBFC21.2
Maximum Transfer Mode : PIO 4, DMA 2, UDMA 6 (ATA-133)
Selected DMA Transfer Mode : UDMA 6

1Speedsys Test          Nvidia MCP2      Via VT8235
2Random access time     : 0.18 ms        : 0.18 ms
3Linear read speed      : 66,650 KB/s    : 6,421 KB/s
4Min read speed         : 66,479 KB/s    : 6,420 KB/s 
5Max read speed         : 66,767 KB/s    : 6,423 KB/s
6Linear write speed     : 73,287 KB/s    : 6,439 KB/s
7Min write speed        : 70,473 KB/s    : 6,439 KB/s 
8Max write speed        : 73,454 KB/s    : 6,440 KB/s
9Buffered read speed    : 64,103 KB/s    : 6,413 KB/s

The Serpent Rider wrote on 2020-12-01, 20:23:

Probably requires better integrated IDE like Nvidia nForce 2/3 (at least Nvidia boasted it) or...

Yes, they boasted it... In a very incompatible way. I remember being a nightmare in Linux installs, and also in XP when you used the incorrect drivers for your chipset... Also, it doesn't seem to like IBM/Hitachi disks too much.

To think it was basically an highly modded ALi/ULi IP IDE Block...

hyoenmadan wrote on 2020-12-01, 22:00:

Yes, they boasted it... In a very incompatible way. I remember being a nightmare in Linux installs, and also in XP when you used the incorrect drivers for your chipset... Also, it doesn't seem to like IBM/Hitachi disks too much.
To think it was basically an highly modded ALi/ULi IP IDE Block...

Oh yeah, it's coming back to me now. Those drivers for XP that would make your windows install do nothing but bluescreen if you swapped motherboards. They were wonderful and terrible at the same time. Sometimes there is that compatibility/performance trade off. I guess in retro computing, we always have that trade off!!

Anyway, my M7 MCG 400 mobo didn't like getting woken up from its long slumber.

I guess those 6.3v capacitors were not meant to last.
But it matches my Geforce 6100-M9 board now =)

And my K7T Turbo too!!

I've been dreading this part of my retro reclamation project. I've entered the age of the puffy capacitors.
Time to improve those soldering skills.

I'm still working on my benchmarking-- Got a lot of data. Got code code written to shred speedsys and atto (Little endian =b ) benchmark files and stick them in graphs.

Wanted to type out loud about some things that I've been pondering.

Things I had forgotten and have now remembered:

1. Computers slower than 100Mhz have significant CPU limitations doing PIO. Replacing a tricycle with a racing bike isn't going to do much when the legs are that weak.
2. MSDOS fdisk is frustrating. Ended up putting Freedos Fdisk on my boot disk because I couldn't take it any more.
3. I remember the 528MB limit because it was so painful for so long, but I forgot about most of the other odd temporary IDE limitations.
4. Need to ground PIN 34 on the ide connector to go faster than UDMA2. It's noticeable if you put a device with a 40 pin female block directly on the IDE connector in a 21st century PC
5. It was not unusual to see vender supplied storage controller drivers cache data even when the program requests no caching. Example:
   https://www.tomshardware.com/reviews/bus-mast … drivers,36.html

Things I never realized:

1. Benchmarking storage in DOS is tough because inefficient BIOS routines are often a severe point of resistance, even with shadow ram turned on. It causes benchmark results compress into a narrow band because the BIOS prevents anything device from doing very well. Option roms included in advanced storage solutions often do better, but can still leave a lot of the hardware performance untapped. For example, my Promise IDE controller does > 40MB/s reads, but is as slow as the Motherboard BIOS for writes ~4MB/s when it should be 10x to 15x faster than that.
2. Hard to predict what you'll get when you buy new flash devices. Ebay & Amazon market have a significant quantity of counterfeit flash storage solutions for sale. Sticking to new products with correctly printed graphics is the best way to go but sometimes vendors slip stream significantly different products into the product pipeline under the same product name. I bought the same CF a year later with the same label, new in box and got something with significantly worse performance. Wasn't that it had the wrong firmware. It was a different device.
3. Some old hard drives behave in very unexpected ways if the controller tries to do LBA. I almost threw out a Quantum LPS 240 because it was clanking like a broken metal lathe when the BIOS defaulted to LBA. Switched to CHS and it came back to life.
4. Sinitechi SD adapters fail to get the most from modern SD's because they are capped at the "High Speed" SD protocol. A faster SD's creeps a little closer to the 25MB/s limit, but don't get much when you buy faster devices, which is pretty much anything made in the last 10 years that isn't total junk. Frustrating, but it doesn't make much of a difference on computers that only have ATA33 and slower anyway.
5. Speedsys has a "verify" test. It's interesting as a "system agnostic" benchmark, because it appears speedsys issues an ATA verify command (40h) to validate a block without transmitting any data. The device should read the block without transmitting any data and return a good value if the read completed successfully. Should give you something close to the true max performance of the storage device, right? The problem is that the newer CF and SD devices seem to cheat by accepting the command and returning success immediately. There's no way the device can validate that fast, because internally, it can't talk to the SD any faster than 25MB/s.

   

I guess it's possible that there is a corresponding Verify command in the SD protocol that aligns with the ATA Verify command and the Sinitechi just passes the command along to the SD.

Here's the first batch of data--

https://docs.google.com/spreadsheets/d/1eukj2 … dit?usp=sharing

Notes:

• Scripted speedsys with a batch file to dump results into an 8.3 text files
• Used a powershell script to collect results and jam the raw data into a SQL database
• Wrote SQL to shred the raw data into structured data
• Did a manual pass on the data to clean things up, such as adding more descriptive names
• I have only worked with 2 motherboards so far MSI AN35N Ultra 1.1 (Nforce2) & Shuttle AK39N (KT400)
• Did some tests with the Nforce2 under Windows. Didn't work as often as it did under DOS.
• The KT400 bios is not fast, so my DOS results for that board are all very slow unless I connected through the TX2Plus controller
• There are a number of gaps in the coverage that I'll go back and review
• Eventually want to repeat the process with older boards ( 440BX, 430FX, Opti 895, etx)
• Eventually want to do a correlation between drive stats and Win98 boot times
• I have a similar set up for ATTO, but I see a number of outliers that are likely related to Win98 storage drivers on 2005 era hardware

Very cool! That looks like quite a bit of work!

Obviously, there's a huge range of performance numbers, but in your testing did any specific devices stand out as noticeably good or bad under use?

Ozzuneoj wrote on 2021-01-26, 21:07:

Obviously, there's a huge range of performance numbers, but in your testing did any specific devices stand out as noticeably good or bad under use?

Nothing that's too earth shattering in hindsight.

Many motherboard motherboard BIOS's only do DOS disk IO at ATA -1 speeds, so not much else matters without a better BIOS or udma.sys
I ran into some odd situations where CF or SD adapter didn't get along with a certain BIOS and wouldn't work or would run really slowly. Would run fine on other systems or in windows.
If you are using a 40 pin DOM or a Female 40 pin CF adapter, you likely need to get out the soldering pen to go faster than UDMA-2
Compact Flash and SD cards in an FC1307A adapters get significantly lower speedsys results than an 8 year old used SSD or a $20 mSata device in a pata 44 enclosure
I should get some real world benchmarks like windows boot time so that this stuff actually means something.