Grzyb wrote on 2024-05-28, 09:38:

Still, be careful - the slowdown resulting from duplex mismatch may be moderate on a quiet network, but much heavier when the network gets busy.

I'll think about how I could simulate such a thing. Unless I use coax there will always be somewhat modern store-and-forward network switch isolating that card from others, and I don't use any protocols that are broadcast, or even multicast heavy. In other words the only traffic to that card will be expected (like pulling data from FTP).
I do have one old 10Mb hub that I keep because it also has coax port, so that I can pretty easily connect such networks to my own. But I don't really see me building any traffic heavy network based on such solution. In fact I try not to use that hub often - it's not something easily found these days, I don't want to damage it with silly experiments.

The other end of my testing setup is Linux box with 2C/4T Atom chip running latest AMD64 Debian. It has only 4G of RAM but this is headless machine that does nothing else but provide services (and Internet) to my internal LAN. On a separate interface and network switches - full isolation (with packet filtering). I've been using such a setup for many years now (the Linux box got a few upgrades along the way), it always worked fine for me and I never really had any network congestion issues, even back in PS3 days when I used to download games from Sony store or play Fat Princess online for hours using that network. I just don't see how I could make the network "noisier" and not with artificial packet flooding - any ideas?

Grzyb wrote on 2024-05-28, 09:38:

BTW: 3C5X9CFG allows to set Half/Full Duplex on the 3C509B, but there's no such option on the original 3C509, right?

Yup. Plain 509 uses different, older chipset, apparently only has 4k of internal RAM for the packet buffers which is the limiting factor (if Linux HOWTO is correct). I need to test it further, on 286 and using proper 32-bit multitasking OSes. I would think the 286 performance might drop if I get many buffer overruns - that depends on how the DOS packet driver partitions the space, if it creates ping-pong double RX buffer and only allocates TX on demand then there should be no issues even on slower CPUs. These are in fact incapable of quickly switching into TX anyway, it takes time to process the RX packets. So frankly for DOS usage and TP uplink this card might be just fine not matter what CPU is used.

Deunan,

I use a synthetic test because I'm trying to find the absolute upper boundary of performance. That way I can tell if new code is better, "close enough" or has a significant new performance problem. Agreed though, for most people they just want to know how it works in their environment under practical conditions.

Even though DOS is single threaded full-duplex vs. half-duplex is going to make a difference. mTCP will put multiple packets on the wire to take advantage of the TCP sliding window. So even if the DOS PC is only doing one thing at a time, there are multiple packets in buffers and in flight at any given moment. Full duplex should always be preferred unless the hardware can't support it.

I've run some Linux benchmarks. Results from my K6-2 system convinced me to try some synthetics as well. Conclusions so far, in no particular order:

* I tested only early Debians (Buzz and Potato), with kernels 2.0.36 and 2.2.26 - it's very unlikely I'd be using ISA network cards with anything newer that has PCI slots
* I'm pretty much CPU and/or IDE limited on all the systems I've tried, including K6-2
* DOS+MTCP is actually pretty darn fast combo, I was expecting Linux to have a clear performance advantage but there isn't one
* MTCP can actually be faster in some scenarios, like sending data to FTP - my guess is Linux (at least these early kernels) allocates only one sending buffer on cards with limited RAM
* There is zero difference between FD and HD settings. I'd have to dig into the sources but I assume the FD setting is simply ignored by the driver in both kernel branches.
* On K6 both B and non-B 3c509 can pull ~950kbps from FTP when redirected to /dev/null
* I forgot to test non-B card on 486DLC in this way but the B one is also able to do ~950k when IDE is bypassed - the system was otherwise idle, so it's possible to build a simple router of such CPU (or even a slower 386DX) for older, less demanding systems

So I guess I'll have to try Win9x for the final verdict.

Do any of these 100mb/s ISA Ethernet cards work with 486 CPU ?

Intel486dx33 wrote on 2024-06-01, 21:16:

Do any of these 100mb/s ISA Ethernet cards work with 486 CPU ?

Of course - ISA-only and VLB+ISA 486 machines are the best match for such cards.
Also, later non-PCI oddballs like NexGen.

386 is too slow to take advantage of 100 Mbps.
Pentium almost always comes with PCI.

Which cards would you recommend for a ISA motherboard computer with Intel 486-dx4-100 CPU with 16mb or RAM ?
I am currently using a 3com 3c509b which is a 10mb/s card. Works great but there is always room for improvement.
I connect my old PC’s to a WIFI extender to give them network access on my home gigabyte lan.
Works fine with this old 3com network card so should also work with these Fast ethernet cards.
I am running DOS / Win3.11 for work groups.

Intel486dx33 wrote on 2024-06-02, 12:31:

Which cards would you recommend for a ISA motherboard computer with Intel 486-dx4-100 CPU with 16mb or RAM ?

ISA only?
The most common 100 Mbps ISA card is 3C515-TX.
There are others, but be careful - for compatibility with modern network equipment you need a 100BASE-TX standard card.
Many early 100 Mbps cards use different standards, eg. 100BASE-T4 or 100VG-AnyLAN.

Grzyb wrote on 2024-06-02, 13:01:

There are others, but be careful - for compatibility with modern network equipment you need a 100BASE-TX standard card.
Many early 100 Mbps cards use different standards, eg. 100BASE-T4 or 100VG-AnyLAN.

In my first job we used 100VG.
Yes there were nice ISA cards for it.

But at ~2001/2002 we fully migrated to Fast Ethernet because the migration even was cheaper than obtaining a bridge from 100VG to 100BASE-TX
I do not know what happened to the VG equipment tough.

I experienced same issues with the 515:

The auto negotiation wasn’t just not working it seemed to be even faulty.

When setting the card to 100FD my switch was always setting its port to 100HD. At the end I had to manually set the switchport to 100MB FD manually - always after! the card was initialized under dos. I forgot about the details but it was something like that.

Even then the real world performance for smb transfers was not really higher compared to the 509b. But this could also be related ty my former setup.

It’s unfortunate nobody made an ISA 10/100 with a UIDE/33 hd interface integrated with a bit of smart logic to automate file transfers to/from disk

I had always hoped vlb would have gotten
10/100
UDMA/33
3dfx voodoo.

Ah well

rmay635703 wrote on 2025-10-21, 19:05:

It’s unfortunate nobody made an ISA 10/100 with a UIDE/33 hd interface integrated with a bit of smart logic to automate file transfers to/from disk

Bypassing the ISA bottleneck that way would require more than "a bit of smart logic".
The card would need to handle the entire network protocols stack, and the filesystem - basically, a separate computer, with its own operating system.

Also, UDMA/33 was 1998, when PCI was already everywhere...

^Hi, by 1992 there was Ultra SCSI, though.
- SCSI still was relevant by mid-90s due to IDE still being unreliable, there also were VLB controllers for it.
The Fast 20 (aka Ultra Fast 20) variant could reach 20 MB/s and the Ultra Wide variant could reach 40 MB/s.

https://de.wikipedia.org/wiki/Small_Computer_ … e#Parallel_SCSI

Sorry for not linking to English Wikipedia article, but it's too messy.

Jo22 wrote on 2025-10-22, 14:31:

^Hi, by 1992 there was Ultra SCSI, though.
- SCSI still was relevant by mid-90s due to IDE still being unreliable, there also were VLB controllers for it.
The Fast 20 (aka Ultra Fast 20) variant could reach 20 MB/s and the Ultra Wide variant could reach 40 MB/s.

Irrelevant in the ISA context.
For ISA, there were only SCSI-1 (5 MB/s) and Fast SCSI (10 MB/s) cards.

I'm wondering how much actually faster is the Fast SCSI over SCSI-1, on ISA.
It's likely the difference is even lower than between Fast Ethernet and the original Ethernet...

Grzyb wrote on 2025-10-22, 14:57:

Irrelevant in the ISA context.
For ISA, there were only SCSI-1 (5 MB/s) and Fast SCSI (10 MB/s) cards.

My bad. I meant to reply to rmay635703's post.:

rmay635703 wrote on 2025-10-21, 19:05:

[..] I had always hoped vlb would have gotten 10/100 UDMA/33 3dfx voodoo. [..] […]
Show full quote

[..]
I had always hoped vlb would have gotten
10/100
UDMA/33
3dfx voodoo.
[..]

Grzyb wrote on 2025-10-22, 14:57:

I'm wondering how much actually faster is the Fast SCSI over SCSI-1, on ISA.
It's likely the difference is even lower than between Fast Ethernet and the original Ethernet...

Hi, I think it depends on how it's implemented.
Performance could be good if the SCSI controller was intelligent (on-board computer) or had used DMA.

But the right type, not the slow PC/XT type of DMA.
Better ISA cards had their own DMA controller that would access RAM, I vaguely remember.

The SCSI-1 controller chip (Trantor) on the PAS16 was very slow, on 1986 level, but fine for a single-speed CD-ROM drive (150 KB/s).

Edit: Chip was the infamous NCR 5380 (or a Zilog equivalent).

Last but not least, there also was EISA bus (besides things such as MCA or Opti bus).
EISA was more succesful among servers, so fast SCSI and Ethernet cards made sense here.
By contrast, SVGA cards for EISA bus were more of a niche.

What I wonder, though, is how good Fast Wide SCSI (20 MB/s) could perfom on a 16 MHz ISA bus.
Because, not too few higher end 286 systems ran at 16 MHz natively (10 or 12 MHz was the bog standard frequency).

So it might have been possible that their slots might have been able to be allowed to run at this clock frequency .
Either if the 286 motherboard was old (mid-80s design, no chipset) and runs off 286 FSB timings
or because it was higher-end and might have had a flexible chipset (late 80s/early 90s).

Also, I vaguely remember, the help file of the venerable MOD4WIN mentions ISA slot overclocking.
So it wasn't being too uncommon in 286/386/486 era (before PCI bridges were introduced).

Edit: This older thread is an interesting read.
Especially the part about the bus timings (16-Bit ISA needs 2 clock cycles)..
16 bit ethernet card in 8 bit ISA

Grzyb wrote on 2025-10-22, 14:57:

I'm wondering how much actually faster is the Fast SCSI over SCSI-1, on ISA.

Some data point from my Am386DX-40 system, with an Adaptec 1542CF running at an ISA DMA transfer rate of 8MB/s. The hard drive in that system is a Fireball 1080S, which is not necessarily known for its superior speed. With the ASPI driver loaded in plain DOS (no cache), I get these performance values in speedsys:

• Fast SCSI: Buffered reads: 6.2MB/s, Linear read up to 4.5MB/s
• Sync SCSI-1: Buffered reads: 4.2MB/s, Linear read up to 3.6MB/s
• Async SCSI: Buffered reads: 2.9MB/s, Linear read up to 2.6MB/s

I don't have the Seagate Cheetah at hand at the moment, and I generally don't want to modify that system, so the values of the Fireball need to suffice for now. I remember the Cheetah to go up to 6.4MB/s in the buffered read bench, so that value does not seem to be severely bottlenecked by the slow hard disk. These values show that at least if your system is one of the unicorns that manage to run stable at an Adaptec burst rate of 8MB/s, the difference between Fast SCSI (up to 10MB/s) over synchronous SCSI-1 is clearly visible.

mkarcher wrote on 2025-10-22, 19:34:

Adaptec 1542CF running at an ISA DMA transfer rate of 8MB/s

You mean bus master DMA, right?

Anyway, your results look nice, indeed - I would like to see such throughput on the 3C515... but how?
On my Slot 1 test machine, ISA bus mastering doesn't seem to work.
On my pre-PCI machines, CPU is the bottleneck - for network benchmarking I use FTP over TCP/IP, sometimes SMB over TCP/IP, and TCP/IP is known to be heavy.
I guess I would need some raw Ethernet benchmark...

Grzyb wrote on Yesterday, 01:02:

mkarcher wrote on 2025-10-22, 19:34:

Adaptec 1542CF running at an ISA DMA transfer rate of 8MB/s

You mean bus master DMA, right?

Yes. I'm sorry for the confusion "ISA DMA" may have caused. Well, technically busmaster DMA it still is DMA, and it happens across the ISA bus, so it is "ISA" "DMA" (that's indeed what I was thinking when I was writing the sentence, without noticing that "ISA DMA" strung together could imply 3rd-party DMA managed by the 8237). The 1542 series adapters do not work at all without (ISA) busmaster DMA.

Grzyb wrote on Yesterday, 01:02:

Anyway, your results look nice, indeed - I would like to see such throughput on the 3C515... but how?
On my Slot 1 test machine, ISA bus mastering doesn't seem to work.

If your want ISA bus mastering, my recommendation is to use pre-PCI systems, as these systems are less complicated. Also note that the way these numbers were generated are how you would generate marketing material. It's nearly the best case scenario. While I could happen to have a system that supports 10MB/s (maybe a 16MHz 0WS 286 system?), 8MB/s busmaster DMA rate is not achievable on every system. Furthermore, this is raw "Int 13h" performance. This means the data is received from the SCSI bus, goes through a small FIFO buffer on the 1542 and directly into exactly that memory location that was requested as read target. If I would have smartdrv loaded, smartdrv would copy the data into XMS. If I would benchmark DOS file read performance, the Int 13h transfer would (at least for small transfers, don't know about big transfers) be performed into a dos "BUFFER", not the application target memory, first and then copies from DOS memory into application memory. These extra copies will degrade performance.

Grzyb wrote on Yesterday, 01:02:

On my pre-PCI machines, CPU is the bottleneck - for network benchmarking I use FTP over TCP/IP, sometimes SMB over TCP/IP, and TCP/IP is known to be heavy.
I guess I would need some raw Ethernet benchmark...

If you have a Linux machine you can use as server, try ethdosfs. While this will definitely also not max out performance, because it does not do read-ahead, it is a slim protocol avoiding IP or even TCP overhead.