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.