• Please review our updated Terms and Rules here

Can an XT benefit with 32KB NIC buffer?

luvit

Experienced Member
Joined
Feb 16, 2014
Messages
488
Location
east of Newark, Oh i;m luvit
I have some source for NICs in my XT's 8-bit slot, but almost forgot to consider memory built-into the NIC.
I've never worried about it in the past, because I never used ethernet in less than 16-bit system.
  • Is there a legacy ISA NIC with 32KB of memory?
  • Is it a make and model that may work in the XT and the XT can take advantage of or benefit from that 32KB?
i may be splitting hairs, but every dollar counts and I have the time on my hands.
The hardest part may be researching buffer sizes of legacy NICS.
 
Unless you are demanding the absolute best performance, the buffer size does not matter. Yes, big buffers are better. But you are on an XT class machine - by definition you are not terribly interested in getting something done quickly.

I would go for things that work. And if you can get a higher performing card, that's just a bogus.


Mike
 
Mike and Krille,
Abstract question.
Do you think, if I pay attention, do you think can "feel" the difference between 32K and 0K?
edit: (on an XT)
 
Last edited:
  • Is there a legacy ISA NIC with 32KB of memory?
  • Is it a make and model that may work in the XT and the XT can take advantage of or benefit from that 32KB?

Yes--at least one that is upgradeable--the Artisoft AE-2/T. The buffer RAM as provided is 16K socketed and a 64K SRAM can easily be substituted and a jumper changed. Whether or not it will lead to better performance in an XT, I have no idea.
 
With an XT, there's a point where larger buffers make no practical difference in transfer speed. I'd guess around 16 KB.
 
With an XT, there's a point where larger buffers make no practical difference in transfer speed. I'd guess around 16 KB.

Be careful with statements like that.

The primary use of the receive buffers is to smooth things out. With bigger buffers the card can continue receiving packets, even when the XT is hung up doing something else, like hard drive access. So while bigger buffers in general do not help transfer speed, they are extremely important in covering over the glitches caused by screen scrolling (glacial on a CGA), hard drive and floppy accesses, unresponsive code, etc.

In simpler terms - smaller buffers means more dropped packets if the application has to take a moment to do something else once in a while.
 
As Mike says, the same could be said about FIFOs and buffers for any device--if the demand for data exceeds the supply capabilities of a device, then you might as well have no buffering. (Caching is a different matter, however).
 
It depends what you're doing server side - the TCP window limit is six packets (8760 bytes) on NT 4, for example, so 16KB would be adequate in that case.
 
In this modern day, I think I'll lean towards over-doing it. I plan to spend a lot of time with my network.. I don't have 5.25 floppy stash at the present.
I really don't mind being a disk-jockey, but I'm afraid file transfers over the network may take away my vintage experience. lol. -- I'm just returning to the XT scene.
ISA NICs with 16 kbyte is pretty easy to find. Cards with more is not so easy.. I can always find NICs, but researching their specs can be a chore.
 
It depends what you're doing server side - the TCP window limit is six packets (8760 bytes) on NT 4, for example, so 16KB would be adequate in that case.

That statement does not take into account that a machine is never just dealing with one socket connection. And that it was common programming practice to increase the receive buffer window by using a set socket option call. Even the mTCP applications generally use larger TCP receive buffers.

It also doesn't take into account that any machine (a PC XT or something running a more advanced operating system) is constantly getting bombarded by broadcast traffic. Modern networks are very noisy and you have to have extra buffering capacity even if the packets are not interesting to you.
 
The buffer size is just one of many variables that determines the performance of a NIC. With an XT I'd be more concerned about what kinds of I/O can be used to move data to/from the card. A NIC that can only do port I/O is probably fine with a V20 CPU but if you've got an 8088 then you'd probably want a NIC that can do memory mapped I/O instead.

There are of course many other factors; many cards use the same type of chip but the overall implementation differs and there are also differences in the quality of the drivers etc. My point is that you shouldn't just look at buffer sizes.

BTW, do you have any ISA NICs (8 or 16 bit) now?
 
I do not have any ISA NICs right now. I'm replacing hardware I've lost in a flood 10yrs ago.
Since i've left my career, I have some cycles available to go back to this hobby. I really am starting on a blank slate.

For now, I would like to avoid the V20 CPU. -- I may implement V20 in another machine in the future.
I haven't been able to determine which NICs are memory mapped vs buffer RAM.. I've never networked an 8bit PC, i'm finding this information facinating.
I'm really struggling more that I realized.. I just put-up a WTB ad for a Artisoft AE-2/T, but perhaps that may not be as optimal as I need for the XT.
I will still want a AE-2/T for another PC in the future, though.

If you guys know of semi-common memory-mapped NIC make/models, I'll put my time into finding those.
I can find makes and models easier, based on your recommendations, -- easier than me researching specs of cards on eBay or classifieds..
 
Modern networks are very noisy and you have to have extra buffering capacity even if the packets are not interesting to you.

This reminds me... I've noticed that mTCP registers itself as the receiver of all packets instead of just ARP and IP. Is there a particular reason for this? If not, you would save some processing by just letting the packet driver throw away the unwanted packets. Also, it would allow mTCP to coexist with other protocols, right? Probably not a big deal since everything is TCP/IP these days but still.
 
This reminds me... I've noticed that mTCP registers itself as the receiver of all packets instead of just ARP and IP. Is there a particular reason for this? If not, you would save some processing by just letting the packet driver throw away the unwanted packets. Also, it would allow mTCP to coexist with other protocols, right? Probably not a big deal since everything is TCP/IP these days but still.

Originally it was for debugging - I needed to see not just ARP and IP, but everything on the network. My debug mode in mTCP is based on TCPDump and I did not want to install blinders on it right away.

Registering for specific packet types is possible. It would let you run a TSR that does IPX (or a different protocol) without interfering with the foreground TCP application. But that would be about the only reason to do it.
 
Re: NEC V20

There are few reasons not to do this. For about $10 you get a 5 to 10% improvement in performance on your machine. And unlike other speed modifications like messing with the DMA memory refresh rate, overclocking, etc. there is absolutely no risk. It just works.

Unless you want to play an unpatched version of Lode Runner. But all of the software that was ever reputed to be not compatible with the V20 has been patched. It is a well understood problem.

The second big reason for a V20 is that it gives you a lot of the additional 80286 instructions that are not related to protected mode. This lets you run things like the Iomega Guest drivers for Zip drives, which do not work on 8088 and 8086 processors. NCSA Telnet is another example of a program that requires an 80286 CPU, will not run on an 8088 or 8086, but will run on a V20 because of the extra instructions that are provided.


As for the rest of your quest, you are over thinking this. Find one of these cards:

  • NE1000 or compatible
  • Xircom PE3 10BT (parallel port attached)
  • 3Com 3C503
  • WD8003 series (* may need an AUI based transceiver)
  • Intel 8/16 series cards

Nearly anything will work for casual use.
 
Mike has a good point about the noisy networks. You might want to look into the 3C509-TP. They are EASILY available all over the place. It's a 16-bit card but it works in an 8-bit slot too, but needs a hacked packet driver to work on an 8088. (I can provide it if you get one, or if you just use a V20 I think the regular driver works)

I don't know the exact amount of buffer RAM, but it's a lot newer than most of the cards you'd find in an 8088. I suspect it's got a pretty large amount. Probably 32 KB. Another option is the Intel EtherExpress 8/16. It has 32 KB.

EDIT: I see Mike mentioned the Intel already.
 
Last edited:
MikeB, I disagree on the 'overthinking this' statement. It's a learning process and that statement is sometimes used in an over-generalized way, perhaps not written the same way as I read it. As you said in an earlier post in this thread -- if I demand best performance, I'll look for buffer. Your two posts are sort of contradicting posts.
I'll review your card recommendations.. at first glance, I don't think the NE1000 is more than 8kb.
In other threads, you state you have higher performing cards with higher buffers, can you please share the make and models you personally use?
I'm not sure if my use of the NIC will be casual.. so I'm choosing the best.
 
Back
Top