Windows/WfW 3.11 automatically disables SMARTDRV if you turn on "32-bit File Access", since that particular vxd handles disk caching in Windows..... and much faster since its a protected mode driver. Windows 3.10 lacks this option.

Perhaps I can checkout if smartdrive makes things better while using the "dos-hardfile" on my PM7300 with my Apple 166Mhz Pentium1 PC-Card.
Without smartdrv the sound sometimes hang/stutters/slowdowns.

smevans526 wrote:

Can SMARTDRV work with with files bigger than what's been allocated for the cache?

I think it doesn't work per-file, but rather per-sector or per-cluster.

And if I remember correctly, the bigger the cache, the more conventional or upper memory smartdrv eats because it has to keep track of what it has in the cache.
40 MB seems to be very big smartdrv cache. Normal sizes used back then were 1 or 2 MB.

Azarien wrote:

40 MB seems to be very big snartdrv cache. Normal sizes used back then were 1 or 2 MB.

Damn straight. That's why I wanna do it.

NJRoadfan wrote:

Windows/WfW 3.11 automatically disables SMARTDRV if you turn on "32-bit File Access", since that particular vxd handles disk caching in Windows..... and much faster since its a protected mode driver. Windows 3.10 lacks this option.

True. With both FastDisk+32-bit File Access enabled, WfW almost never falls back to real-mode.
If I'm not mistaken, it even intercepts int 21h calls to the DOS API (ABI).

Out of all 16-Bit Windows flavors, WfW 3.11 is perhaps the closest to a real operating system.

Tried to play Space Quest 4 on a 486 system upgraded with an IBM-Cyrix 5x86. Too fast. Turned off processor caching, too slow. Loaded SMARTDRV with 2mb, just right 😀

I only ever use smarydrive with disabling write back. i use for read cache only.

mostly, ncache2 is much better than smartdrive too!

If you have enough ram, a 16mb cache is fine for hd's. ncache2 lets you see the stats, which is interesting data.

I might be highjacking my own thread, but, what is 'write back'?

smevans526 wrote:

Tried to play Space Quest 4 on a 486 system...

You may also want to consider some of the patches from vogons member newrisingsun that alter the timing on certain parts of the game so they are less dependent on specific CPU speed.

smevans526 wrote:

I might be highjacking my own thread, but, what is 'write back'?

where writes are cached, thats when if the machine crashes, you get incomplete writes on disk, missing/corrupted data etc.

if you need to run smartdrive use /x to disable write caching.

CkRtech wrote:

smevans526 wrote:

Tried to play Space Quest 4 on a 486 system...

You may also want to consider some of the patches from vogons member newrisingsun that alter the timing on certain parts of the game so they are less dependent on specific CPU speed.

The game runs stable with the 5x86 running at full speed. I don't even get an error with my mt32. I just stand everyone's mouths and arms flapping around like humming birds. Quest for glory iv is unplayable though... 'not an object'

Jo22 wrote on 2017-09-03, 16:46:

SmartDrive can be counter-productive on slow systems. Especially if you've got a fast HDD or a flash medium already. […]
Show full quote

SmartDrive can be counter-productive on slow systems.
Especially if you've got a fast HDD or a flash medium already.

I think SmartDrive makes sense for single-speed CD-ROM drives, though.
150KB/s are barely enough for CD-ROM games with FMVs.

Sorry to reopen but again found a point that is making up my mind.

I read this statement already somewhere else but never could find a prove for this.

It could only be about cpu utilization. As i benchmarked on my 386sx DOMs, CFs and large 16MB Cached HDDs. Read/Write instructions where always faster with smartdrv. I timed various copy operations for that. My explanation is that access to memory ram is always faster than the access via PIO - even there is a fast hdd or large cache behind. It will still be behind the PIO I/Os

IIRC, DOS 6.2 fixed a bug with writing back incomplete data upon program exit but not if the program locks up. I can use SMARTDRV on a Win98SE tower in DOS mode but am wondering if there's a better choice.

Marco wrote on 2024-04-03, 19:32:

Sorry to reopen but again found a point that is making up my mind. […]
Show full quote

Jo22 wrote on 2017-09-03, 16:46:

SmartDrive can be counter-productive on slow systems. Especially if you've got a fast HDD or a flash medium already. […]
Show full quote

SmartDrive can be counter-productive on slow systems.
Especially if you've got a fast HDD or a flash medium already.

I think SmartDrive makes sense for single-speed CD-ROM drives, though.
150KB/s are barely enough for CD-ROM games with FMVs.

Sorry to reopen but again found a point that is making up my mind.

I read this statement already somewhere else but never could find a prove for this.

It could only be about cpu utilization. As i benchmarked on my 386sx DOMs, CFs and large 16MB Cached HDDs. Read/Write instructions where always faster with smartdrv. I timed various copy operations for that. My explanation is that access to memory ram is always faster than the access via PIO - even there is a fast hdd or large cache behind. It will still be behind the PIO I/Os

That should be right for most 386 class... the fly in the ointment is when any memory expansion is on the ISA bus, then you end up hammering that bus three times for one piece of data vs once to get it straight from disk.

Marco wrote on 2024-04-03, 19:32:

Sorry to reopen but again found a point that is making up my mind. […]
Show full quote

Jo22 wrote on 2017-09-03, 16:46:

SmartDrive can be counter-productive on slow systems. Especially if you've got a fast HDD or a flash medium already. […]
Show full quote

SmartDrive can be counter-productive on slow systems.
Especially if you've got a fast HDD or a flash medium already.

I think SmartDrive makes sense for single-speed CD-ROM drives, though.
150KB/s are barely enough for CD-ROM games with FMVs.

Sorry to reopen but again found a point that is making up my mind.

I read this statement already somewhere else but never could find a prove for this.

It could only be about cpu utilization. As i benchmarked on my 386sx DOMs, CFs and large 16MB Cached HDDs. Read/Write instructions where always faster with smartdrv. I timed various copy operations for that. My explanation is that access to memory ram is always faster than the access via PIO - even there is a fast hdd or large cache behind. It will still be behind the PIO I/Os

Hi there! I believe at the time I was thinking mainly about SmartDrive on slow 286s and SmartDrive on 386/486s in conjunction with the usual memory managers (v86 can slow them down).

Because, to be really useful, SmartDrive requires lots of memory for buffering/chaching data.
So either EMS (fast via chipset/dedicated board) or Extended Memory is being required in some form.

I really recommend trying out the cloaking-enabled SmartDrive versions (Helix products).
They don't require EMS or help of v86 based memory managers.

Another factor to consider is linear reads vs random reads.
Playing back a wave file or movie is different to reading a couple of data files.

That's like with the issue with modern NCQ enabled hard disks (native command queueing).
In theory, NCQ is great (elevator principle, in which every floor is being reached in most efficient way), but it can also slow down linear access.

So it really depends on how the caching algorithm works, I guess.
Some programs are sector based (SmartDrive?), while others are FAT/file based (FastOpen).

The 150KB/s CD-ROM drive are (were) sort of a dilemma, I think.
They can't buffer any meaningful data and do always "squeak around" a lot (thinking of the Mitsumi LU005S here):
There's always lots of head movement involved, for each file being accessed.

So at this point, I think, SmartDrive can't hurt performance anymore here.
Any type of caching being done (be it reading ahead in a linear fashion or be it reading random, nearby sectors etc) reduces erratic head movement, even if there's little actual performance being gained.

The use of a cache makes it effectively slower sometimes, maybe, but at least the erratic head movement goes away.
The drive will operate more smoothly, all in all.

My theory on why CD drives run slower with caching:
1- It is reading ahead data that probably won't be used.
2- If the cached data was indeed being used, the CD won't be accessed, which sounds good, but then the drive might have the time to trigger spin down, which makes the next uncached access waaaay slower.

It is all circumstantial, but with the above I can see how it could lead to very annoying stutters.

wbahnassi wrote on 2024-04-06, 14:18:

My theory on why CD drives run slower with caching: 1- It is reading ahead data that probably won't be used. 2- If the cached da […]
Show full quote

My theory on why CD drives run slower with caching:
1- It is reading ahead data that probably won't be used.
2- If the cached data was indeed being used, the CD won't be accessed, which sounds good, but then the drive might have the time to trigger spin down, which makes the next uncached access waaaay slower.

It is all circumstantial, but with the above I can see how it could lead to very annoying stutters.

That makes sense, though the early CD drives never spun down (or if they did, merely after some notable idling).
They rather kept rotating steadily on same speed like an ordinary CD player.

That's also when things like CAV and CLV come into play, I think.
Modern drives to spin up and down a lot.
So utilities like CD-Speed can be very useful, I think.
They do allow some drives to keep running at, say, 4x speed all time.

Blood and Shadow Warrior benefit greatly from SmartDrv in my experience. Far less HDD access (and noise) and much less stuttering specially when things explode.

With regards to Smartdrv in general my experience is that it’s not really not Game specific. Each I/O operation benefits from it. Whether it’s ingame or just for starting same.

BitWrangler wrote on 2024-04-06, 01:49:

Marco wrote on 2024-04-03, 19:32:

Sorry to reopen but again found a point that is making up my mind. […]
Show full quote

Jo22 wrote on 2017-09-03, 16:46:

SmartDrive can be counter-productive on slow systems. Especially if you've got a fast HDD or a flash medium already. […]
Show full quote

SmartDrive can be counter-productive on slow systems.
Especially if you've got a fast HDD or a flash medium already.

I think SmartDrive makes sense for single-speed CD-ROM drives, though.
150KB/s are barely enough for CD-ROM games with FMVs.

Sorry to reopen but again found a point that is making up my mind.

I read this statement already somewhere else but never could find a prove for this.

It could only be about cpu utilization. As i benchmarked on my 386sx DOMs, CFs and large 16MB Cached HDDs. Read/Write instructions where always faster with smartdrv. I timed various copy operations for that. My explanation is that access to memory ram is always faster than the access via PIO - even there is a fast hdd or large cache behind. It will still be behind the PIO I/Os

That should be right for most 386 class... the fly in the ointment is when any memory expansion is on the ISA bus, then you end up hammering that bus three times for one piece of data vs once to get it straight from disk.

That's why I think that it's okay to levitate ISA bus performance a little bit.
A 286 or 386 is being hindered by the standard bus frequency of ~8MHz.

If it's being allowed to run at 10 or 12 MHz (or 13 MHz, some boards don't like 12),
ISA has about enough bandwidth to not to be such a bottleneck for the system and expansion cards all the time. 😁

That being said, I try to make an exception here, as I'm not so much a fan of overclocking all the time.
It's rather about getting free of bottlenecks. Wait states included.
Sometimes having a slower clock frequency and no wait states can be smoother in overall.