Here are the results with the CF connected to the internal controller

This is the result with the compact flash connected inside the XT-CF card

What are your considerations? I don't know if it is possible to connect a card to the internal controller (which seems much better to me) and use the XT-IDE BIOS because I wasn't able to do it, that is, leaving the XT-CF card connected to the computer and inserting a Compact Flash from 4Gb (but partitioned at 2Gb and perfectly functional if inserted into the XT-IDE) this is not seen by the computer but rather, in the IBM bios it sees it as a 400MB hard disk and does not boot.

Are you comparing different cards? A 512MB directly on the controller and a 4GB one on the XT-IDE card? That won't give you results suitable to reach conclusions.

There is also a third route you might want to try, since you are experimenting: DDO software on the 4GB card without XT-IDE BIOS.

No, test are related only on 512MB Card, each time connected on the XT-CF and Directly to the Mainboard ctrl.

I want to use only an Hardware solution.

What amazes me here is that I get a vastly different result with a 486/40.
And I don't mean to just quadruple the test score, it is more like adding two zeros.

I just looked it up:
with the 486 on deturbo, I get a HDD score of ~1700. That is a factor of 100. On turbo, I get 2700.
I get a buffered read speed of ~2200 KB/s, that is 10 times yours.
Yes, I know I have VLB, but iirc, the normal IDE controller wasn't that much slower.
I just wonder what makes the score go up by x100 when read speed goes up x10.

Have you checked the CF-card in a USB2 card reader?

Assuming they have a means to write the eeprom (etherlink III lacks flashing function, iirc), the xtide xub is a better option than using a ddo.

We did not have such fun stuff bitd, so had to make do with ddo's (that came free with drives, conveniently!), but the shenanigans ddos do to prevent the real boot track getting overwritten can cause problems with properly lba aware oses.

Xtide xub is native stuff.

wierd_w wrote on 2024-07-28, 10:21:

Assuming they have a means to write the eeprom (etherlink III lacks flashing function, iirc), the xtide xub is a better option than using a ddo.

We did not have such fun stuff bitd, so had to make do with ddo's (that came free with drives, conveniently!), but the shenanigans ddos do to prevent the real boot track getting overwritten can cause problems with properly lba aware oses.

Xtide xub is native stuff.

You used too many abbreviations, I didn't understand...

ux-3 wrote on 2024-07-28, 10:20:

What amazes me here is that I get a vastly different result with a 486/40. And I don't mean to just quadruple the test score, it […]
Show full quote

What amazes me here is that I get a vastly different result with a 486/40.
And I don't mean to just quadruple the test score, it is more like adding two zeros.

I just looked it up:
with the 486 on deturbo, I get a HDD score of ~1700. That is a factor of 100. On turbo, I get 2700.
I get a buffered read speed of ~2200 KB/s, that is 10 times yours.
Yes, I know I have VLB, but iirc, the normal IDE controller wasn't that much slower.
I just wonder what makes the score go up by x100 when read speed goes up x10.

Have you checked the CF-card in a USB2 card reader?

In my opinion it depends a lot on the Compact Flash... the one I tested is 512MB, therefore very old in technology.

AlessandroB wrote on 2024-07-28, 11:27:

In my opinion it depends a lot on the Compact Flash... the one I tested is 512MB, therefore very old in technology.

I tested 1 GB CF. Two different brands, similar results.
I did suggest to check the transfer rate with a USB2.0 card reader, to see if the card is the limit.

AlessandroB wrote on 2024-07-28, 10:01:

This is the result with the compact flash connected inside the XT-CF card

Can you try to shadow the ROM and see whether it gets faster?
(Enable adapter shadow in BIOS)

ux-3 wrote on 2024-07-28, 12:57:

AlessandroB wrote on 2024-07-28, 11:27:

In my opinion it depends a lot on the Compact Flash... the one I tested is 512MB, therefore very old in technology.

I tested 1 GB CF. Two different brands, similar results.
I did suggest to check the transfer rate with a USB2.0 card reader, to see if the card is the limit.

sorry, you said you have a buffered transfer of 2200, in the case of my internal controller we are at 1700, on a 386sx, it could be consistent right?

AlessandroB wrote on 2024-07-28, 13:19:

you said you have a buffered transfer of 2200, in the case of my internal controller we are at 1700, on a 386sx, it could be consistent right?

Yes. What surprises me is the SCORE the tool gives. I get a hundred times more score than you. I wonder why?
Actually, even your two scores are... odd. Almost the same.

AlessandroB wrote on 2024-07-28, 11:26:

wierd_w wrote on 2024-07-28, 10:21:

Assuming they have a means to write the eeprom (etherlink III lacks flashing function, iirc), the xtide xub is a better option than using a ddo.

We did not have such fun stuff bitd, so had to make do with ddo's (that came free with drives, conveniently!), but the shenanigans ddos do to prevent the real boot track getting overwritten can cause problems with properly lba aware oses.

Xtide xub is native stuff.

You used too many abbreviations, I didn't understand...

XTIDE XUB == XTIDE eXtended Universal Bios Its the software that lives inside an XTIDE card. It can also live inside a network interface card with a boot rom socket, like your Etherlink III.

DDO == Dynamic Drive Overlay. This is a software solution to allow large disk support on a system that lacks an LBA (Logical Block Addressing) aware implementation of software interrupt vector 13. (The DOS handler that deals with hard drives, and is the source of the 504mb limitation.) Several of these were available back in the day, but the biggest names were Ontrack Disk Manager (DM), and EzDrive. Vogons driver library has a copy of EzDrive available, along with a few others.

http://vogonsdrivers.com/index.php?catid=19

DDOs use the physical boot sector to load, as if they were an operating system. They then HIDE the first track of the drive to protect themselves, and present the NEXT logical track, as if it was the one with the physical boot sector on it. Operating systems that use software interrupt 13 wont know that this is not really the boot sector, and will write their information and partition table there instead. The DDO looks for this location, and chainloads your actual operating system after loading into memory and providing its version of the int13 handler.

Operating systems that know how to deal with the disk controller directly and can perform LBA addressing on their own (XP, NT4, Linux, etc) will have "Issues" with the fact that their boot sector is NOT the actual boot sector, among other things.

These kinds of issues are why I would suggest using the XTIDE's XUB with your NIC instead, assuming you have a way to write it into an EEPROM. (Electronically Erasable Programmable Read Only Memory) Your Etherlink III lacks the circuitry to write/erase these chips. It can only read one that has been written to.

AlessandroB wrote on 2024-07-28, 10:00:

Here are the results with the CF connected to the internal controller

My experience is that speedsys does the physical drive tests (track to track, etc) on a cf instead of the solid state drive tests when something isnt performing as expected, like the bios isn’t shadowed.

If you do the report at the end, you get the screen shot in pcx format and you get a bunch of details about the ata setup. it would be interesting to see the CF firmware version.

ux-3 wrote on 2024-07-28, 10:20:

What amazes me here is that I get a vastly different result with a 486/40. And I don't mean to just quadruple the test score, it […]
Show full quote

What amazes me here is that I get a vastly different result with a 486/40.
And I don't mean to just quadruple the test score, it is more like adding two zeros.

I just looked it up:
with the 486 on deturbo, I get a HDD score of ~1700. That is a factor of 100. On turbo, I get 2700.
I get a buffered read speed of ~2200 KB/s, that is 10 times yours.
Yes, I know I have VLB, but iirc, the normal IDE controller wasn't that much slower.
I just wonder what makes the score go up by x100 when read speed goes up x10.

Have you checked the CF-card in a USB2 card reader?

A significant portion of the speedsys HDD score seems to be related to the “linear verify” test. It was an interesting test on physical disks back when all the firmware was well behaved because it would give you a pretty good idea for how fast the heads moved over the data, with little influence of the current ata transfer rate. Unfortunately, it became very common for the firmware on the storage device to just report success immediately when they see the ata verify command without actually checking the data. The “cheating” firmware throws off the hdd scores in speedsys quite a bit.

AlessandroB wrote on 2024-07-28, 10:01:

This is the result with the compact flash connected inside the XT-CF card

The numbers you are seeing here are about what I’d expect to see if you are using an 8bit ide controller and running your int13h code from a rom that is also stored on the same 8 bit controller.

Your best performance will likely come if you connect the drive to the 16 bit controller and shadow the XTiDE rom into ram.

Edit: and make sure you are using the 386 version of xub as well. (xub = xtide universal bios)

douglar wrote on 2024-07-28, 17:06:

A significant portion of the speedsys HDD score seems to be related to the “linear verify” test. It is an interesting test on physical disks back when all the firmware was well behaved because it would give you a pretty good idea for how fast the heads moved over the data, with little influence of the current ata transfer rate. Unfortunately, it became very common for the firmware on the storage device to just report success immediately when they see the ata verify command without actually checking the data. The “cheating” firmware throws off the hdd scores in speedsys quite a bit.

It is not just this.
Several SCSI drives perform a linear verify test (much) slower than a linear read test!

Disruptor wrote on 2024-07-28, 17:15:

It is not just this.
Several SCSI drives perform a linear verify test (much) slower than a linear read test!

Speedsys seems be designed to test ATA compatibile drives. It doesnt work with all SCSI controllers, or even all caching IDE controllers for that matter, since they don’t let the computer senf ATA commands directly to the drive.

But to get back on topic, for best performance:

• don’t connect your drive to an 8bit controller on a system that has a 16bit controller on the motherboard. this is a 2x performance gain.
• don’t run your code from a rom on an 8bit controller. shadow the slow rom into ram, either in the bios or by using a dos utility. this gives you a 3x performance boost becuase your CPU is no longer spending most of its time waiting for the next op code to arrive over a slow bus, 8 bits at a time.
• don’t pay too much attention to the hdd score or the linear verify score, since they are highly dependent on the firmware in the storage device being honest. Seek time and buffered read tell you the most about your system config. linear read tells you about the device. if you are seeing the “track to track” test on an ATA SSD, something in your setup is confusing speedsys.
• don’t expect the best performance on a 386 if you are using the 8088 version of XUB. Get the 386 build and use the config tool to optimize it for your system, even if you have a 386sx, there were enough new opcodes introduced that it helps. this should give you a 10-15%boost. might give you more if you had a dx instead of an sx.