Try this: http://www.brutman.com/mTCP/download/ftp_2026-08-20.exe

Also, use MTU 492. You can try 504 but 492 should be safe.

mbbrutman wrote on 2026-08-20, 18:38:

Try this: http://www.brutman.com/mTCP/download/ftp_2026-08-20.exe

All uploads in BINARY mode from HDD, in KB/s:

MTU 492:

ARCPSF, ftp.exe: 73..82
ARCPSF, ftp_2026-08-20.exe: 66..72
SMCARCWS, ftp.exe: 77..83
SMCARCWS, ftp_2026-08-20.exe: 40..77

It probably doesn't make sense to struggle with this any further...
To compete with Windows, we would need a new PD - but I'm not able to write one, and can't see anybody else using Arcnet.
Also, circa 80 KB/s isn't that bad for XT-era technology, and already much faster than CUTCP and WatTCP.

I haven't struggled too much - most of the work has been on your side. ;-0 That last change allowed for more than 4 TCP/IP packets to be in the send or sent queue.

I'm assuming you are using 2.5Mb/sec Arcnet. The theoretical limit for that is around 305KB/sec, not counting the TCP/IP header overhead or any Arcnet needs. Those two headers alone reduce the maximum throughput by another 9%. And then you have the overhead of the extra layers of networking code to convert those protocols into the packet driver spec. ArcEther is probably the best bet for performance.

Grzyb wrote on 2026-08-21, 20:33:

All uploads in BINARY mode from HDD, in KB/s: […]
Show full quote

mbbrutman wrote on 2026-08-20, 18:38:

Try this: http://www.brutman.com/mTCP/download/ftp_2026-08-20.exe

All uploads in BINARY mode from HDD, in KB/s:

MTU 492:

ARCPSF, ftp.exe: 73..82
ARCPSF, ftp_2026-08-20.exe: 66..72
SMCARCWS, ftp.exe: 77..83
SMCARCWS, ftp_2026-08-20.exe: 40..77

It probably doesn't make sense to struggle with this any further...
To compete with Windows, we would need a new PD - but I'm not able to write one, and can't see anybody else using Arcnet.
Also, circa 80 KB/s isn't that bad for XT-era technology, and already much faster than CUTCP and WatTCP.

Hi, is that XT technology involving an 8088 or a higher CPU?
I'm probably stating the obvious here, but 8018x and V20/V30 do support INS/OUTS instructions which might help with allowing fast block transfers between I/O ports and memory.
Provided that software has support for it. Such as some builds of XT-IDE Universal BIOS, I think.
Many plain 8088/8086 software doesn't use it, unless it has 80186/80286 detection and two code paths in it.

PS: The Little Big LAN (LBL) had additional Arcnet Support (besides serial, parallel and Ethernet). Bitsavers might have documented it.
LBL was also known as $25 network. Or Kirschbaum Netz (in Germany).
Below are some excerpts from the v2 manual that cover Arcnet operation. Hope that's okay.

Jo22 wrote on 2026-08-22, 01:31:

Hi, is that XT technology involving an 8088 or a higher CPU?
I'm probably stating the obvious here, but 8018x and V20/V30 do support INS/OUTS instructions which might help with allowing fast block transfers between I/O ports and memory.

In ARCETHER.ASM there's no INS/OUTS instructions, only IN/OUT.
Other drivers may use newer instructions - I'm looking at TRXNET.COM from NetWare Client 1.21 (1996), and there's the message "This driver must run on a 386 processor or better".

But it probably doesn't matter...
Standard Arcnet cards have RAM buffer in the MEM address space, D0000..D1FFF - there's no large transfers between I/O and memory!

This might be an excellent case for AI. Give it drivers (or all binaries in the chain. driver + Packet Driver? + client?) and ask to pinpoint where the bottleneck is, or outright make it optimize it.

rasz_pl wrote on 2026-08-22, 07:06:

This might be an excellent case for AI. Give it drivers (or all binaries in the chain. driver + Packet Driver? + client?) and ask to pinpoint where the bottleneck is, or outright make it optimize it.

Which model would you recommend?
I'm thinking about using AI to port the Linux "com90xx" driver to PD API, but without much hope - there was an attempt at porting 3Com drivers from Linux to PD, using Claude, but it failed.

Some people have good results with chatGPT P2B-B JumperFree BIOS
others with Claude https://fetzu.ch/blog/20260819_claudevsdrobo/
This requires paid subscription and preferably a spare clean computer you dont care if agent erases HDD or uploads everything to random website on a whim 😀 + another computer with hardware you want working with a way for agent to communicate with and instrument remotely so you dont have to keep sitting there manually uploading and typing in reports for stupid robot.
Personally havent done anything like this before. My extend of AI use is dropping in assembly I dont understand and having it explain it to me so I learn something.

I would start by just dropping all the drivers you have for one model and asking for analysis, comparison and to find shortcomings and bugs. You might get lucky with just that. The key is to not believe everything LLM produces and double check.

^let's maybe throw mTCP into the mix, was well, maybe it helps. ;)

Please don't ...

This is way off topic for this thread so I'll keep it brief. To somebody without technical experience AI looks like magic. To somebody with technical experience it can sometimes look like magic too. But it's not.

If AI enables you to do something that you could not get done because of time constraints, great - that implies you know how to judge its output and validate it. But if you are just going to use the magic black box to generate magic without being able to review it, then you are just wasting time and energy.

The performance issue described in this thread is probably one of two things: A flow control issue or an excessive amount of copying bytes is going on. It's also possible that something more subtle is happening, like interrupts are disabled when they should not be. AI is not going to find something like that. If it is worth doing, it needs real human experience and effort.

mTCP does not use AI. On occasion I have AI review a smaller piece of my code and it has flagged one problem correctly. But usually it either misses problems, or it claims there are problems where there are none. (I have no intention of using AI for my code; I'm just using it to assess the state of things. I enjoy the challenge, so I'm not going to outsource it.)

Grzyb wrote on 2026-08-12, 17:39:

So, the best system for the router seems to be Linux 2.2 - I will try it sometime.

I did it - here's how to downgrade Red Hat Linux 7.3 to kernel 2.2, so to add support for Ethernet-encap...

Download "linux-2.2.26.tar.bz2", and unpack it.

Download "kernel-source-2.2.16-22.i386.rpm" from Red Hat Linux 7.0, but no need to install it - only extract one file: "/usr/src/linux-2.2.16/configs/kernel-2.2.16-i686.config", or whichever seems the proper config for your machine.

make menuconfig
- Load an Alternate Configuration File: kernel-2.2.16-i686.config
- Network device support -> ARCnet devices -> modularize everything you can:

- Character devices -> Ftape, the floppy tape device driver -> exclude "Ftape (QIC-80/Travan) support" (this distro's compiler won't compile it)
- Exit, save

make dep
make bzImage
make modules
su
make modules_install
make install

Reboot to the 2.2.26 kernel, and then:

1insmod arcnet
2insmod com90xx
3ifconfig arc0 192.168.1.4 netmask 255.255.255.0
4ifconfig arc0e 192.168.2.4 netmask 255.255.255.0
5echo "1" > /proc/sys/net/ipv4/ip_forward
6dhcpd arc0 arc0e

Example /etc/dhcpd.conf :

1subnet 192.168.1.0 netmask 255.255.255.0 {
2    range dynamic-bootp 192.168.1.100 192.168.1.199;
3    default-lease-time 86400;
4    max-lease-time 86400;
5    option subnet-mask 255.255.255.0;
6    option broadcast-address 192.168.1.255;
7    option routers 192.168.1.4;
8    option netbios-name-servers 192.168.0.2;
9}
10
11subnet 192.168.2.0 netmask 255.255.255.0 {
12    range dynamic-bootp 192.168.2.100 192.168.2.199;
13    default-lease-time 86400;
14    max-lease-time 86400;
15    option subnet-mask 255.255.255.0;
16    option broadcast-address 192.168.2.255;
17    option routers 192.168.2.4;
18    option netbios-name-servers 192.168.0.2;
19}

ifconfig -a

1arc0      Link encap:ARCnet  HWaddr 01  
2          inet addr:192.168.1.4  Bcast:192.168.1.255  Mask:255.255.255.0
3          UP BROADCAST RUNNING  MTU:1500  Metric:1
4          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
5          TX packets:0 errors:0 dropped:0 overruns:0 carrier:3861
6          collisions:0 txqueuelen:30 
7          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
8          Interrupt:9 Base address:0x300 Memory:d0000-d07ff 
9
10arc0e     Link encap:Ethernet  HWaddr 00:00:00:00:00:01  
11          inet addr:192.168.2.4  Bcast:192.168.2.255  Mask:255.255.255.0
12          UP BROADCAST RUNNING MULTICAST  MTU:493  Metric:1
13          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
14          TX packets:0 errors:0 dropped:0 overruns:0 carrier:3861
15          collisions:0 txqueuelen:100 
16          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
17          Interrupt:9 Base address:0x300 Memory:d0000-d07ff 
18
19arc0s     Link encap:ARCnet  HWaddr 01  
20          BROADCAST  MTU:507  Metric:1
21          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
22          TX packets:0 errors:0 dropped:0 overruns:0 carrier:3861
23          collisions:0 txqueuelen:30 
24          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
25          Interrupt:9 Base address:0x300 Memory:d0000-d07ff 

Windows 98 SE can also work as an Arcnet<->Ethernet router, with the following limitations:
- only one packet format
- no DHCP server included

To enable/disable routing, right-click on one of the attached INF files -> Install

To check current routing state, use WINIPCFG:

If you still want to try LLMs COMrade might be useful https://github.com/yyzkevin/COMrade
in use https://github.com/ahmadexp/Open-Source-PC110 … overy/Live-Dump
and win95 version COMR95.EXE https://github.com/ahmadexp/Open-Source-PC110 … oftware/COMrade
used by https://github.com/Mike1978uk/win95-intel-inboard-386pc to verify results of emulator debug sessions and https://github.com/ahmadexp/Open-Source-PC110 to help design hardware clone of IBM PC110

Grzyb wrote on 2026-08-11, 05:50:

In theory, Arcnet is 2.5 Mbps = 312 KB/s; actual measured performance isn't as close to the theoretical limit as with the Ethernet.
I guess it's due to shorter frames, and with NDIS+TCP/IP there's the additional overhead of "Ethernet-encap" - with both Arcnet header and Ethernet header transmitted, there's less room for payload.

A more precise explanation from "The Encyclopedia of Networking", Second Edition, by Werner Feibel:

ARCnet has the following disadvantages: […]
Show full quote

ARCnet has the following disadvantages:

• Its data transmission is inefficient.
  ARCnet sends three overhead bits
  for every byte. Also, administrative
  exchanges (such as ACK or NAK
  packets) between source and destina-
  tion are done on the data bandwidth,
  which degrades performance further.
• Actual throughput is much less than
  the maximum 2.5 Mbps. Even for
  small networks, the throughput is less
  than 65 percent of maximum, and this
  value decreases as more nodes are
  added to the network.

Xircom Pocket Arcnet Adapter II PA2-02B6

Most Arcnet adapters are BUS-only, STAR-only, or BUS/STAR selected by jumper.
But this one is different - works in either topology automagically.

There's no DIP-switches to select NODE ID - it's done via the setup/diagnostics program:

On the testing machine, the adapter works in two modes depending on the LPT port mode selected in CMOS SETUP:

SPP -------- Bidirectional
EPP1.9+SPP - Bidirectional
ECP -------- Non-Bidirectional
ECP+EPP1.9 - Non-Bidirectional
Normal ----- Non-Bidirectional
EPP1.7+SPP - Bidirectional
ECP+EPP1.7 - Non-Bidirectional

Benchmarks in the following setup:

CeleronClient <-> Arcnet <-> LinuxRouter <-> Ethernet <-> ModernLinuxServer
PA2ODI + "Existing ODI Driver"/ODIPKT
default MTU
all results in KB/s

Non-Bidirectional:

Win98SE FTP download to NUL: 112
Win98SE FTP upload from HDD: 129
mTCP FTP download to NUL: 94
mTCP FTP upload from HDD: 55 (unstable)

Bidirectional:

Win98SE FTP download to NUL: 147
Win98SE FTP upload from HDD: 129
mTCP FTP download to NUL: 113
mTCP FTP upload from HDD: 48 (unstable)

There's also NDIS 2.0 driver - works with Microsoft Network Client 3.0 for MS-DOS, can connect to Win98SE server, using NetBEUI protocol.
Fails to work with IPX or TCP/IP.

For comparision, benchmarks of a normal 8-bit ISA adapter in the same setup...

4DC ARCBOARD/8 PLUS

SMCARCWS + "Existing ODI Driver"/ODIPKT

Win98SE FTP download to NUL: 198
Win98SE FTP upload from HDD: 166
mTCP FTP download to NUL: 160
mTCP FTP upload from HDD: 75 (unstable)