Louthrax wrote on 2023-12-22, 21:50:

Thanks to the kind help on this site, I've finally managed to have a fully working network setup for my old Windows 98 PC. I can […]
Show full quote

Thanks to the kind help on this site, I've finally managed to have a fully working network setup for my old Windows 98 PC. I can now backup and restore easily my different partitions (including the OS one) from my PuppyLinux CD to my NAS, everything is working well.

I just had a small doubt when I checked the "quality" of the connection during a big partition restoration. Linux reported lots of networking errors:

Copy code to clipboard

1root:~#ifconfig eth0
2eth0      Link encap:Ethernet  HWaddr 00:30:4F:27:C6:CA  
3          inet addr:192.168.1.16  Bcast:192.168.1.255  Mask:255.255.255.0
4          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
5          RX packets:1897565 errors:1521 dropped:5481 overruns:1019 frame:0
6          TX packets:884304 errors:0 dropped:0 overruns:0 carrier:0
7          collisions:0 txqueuelen:1000 
8          RX bytes:2588203718 (2.4 GiB)  TX bytes:297794961 (283.9 MiB)

Despite those errors (errors:1521 dropped:5481 overruns:1019), I know the restoration went 100% well thanks to the global 7zip CRC on the TARed file.

I'm just curious to know if those networking errors are kind of "expected" when using an old network card, of if there's something wrong with my network card ?

Let me know if you experienced something similar or have any hints. I'll probably order another PCI or ISA network card anyway...

EDIT: My other "modern" PCs connected on the same router always report 0 errors, even for very big data transfers.

Is the network cable in good condition? Basic, but worth considering.

If you are on an ethernet hub, then packets might have arrived for other machines on the LAN. You do say "same router", so I guess that is a contemporary ethernet switch in your domestic broadband router. So not a hub. Hubs repeat packets to all ports, switches send packets only to the port where the packet's address MAC can be found.

Is the NIC in promiscuous mode? Were you doing any traffic monitoring otherwise? eg tcpdump (hardcore), iptraf or maybe speedometer, they can force a NIC to accept any packets. I thought promiscuous mode was marked on the output of ifconfig though, but can't see it on any machines here right now.

What NIC is it? Which kernel module? Or more like, does modinfo module-name have any parameters documented? Some of those might address some errors.

To boot a Linux on 98 hardware, I guess the distro is a bit old? No probs there, but the whole promiscuous mode thing is nagging at me. Did old kernels, or plenty of old modules, run promiscuous by default? I think they might....

I googled and opened some tabs, and forgot about them. First kind of things that came up probably cover the reason. But I did forget IPv6 exists (I turn it off everywhere), and your interface is not configured for that. I now think the dropped packets will be IPv6 from other PCs, and the router itself.

https://unix.stackexchange.com/questions/2051 … opped-rx-packet

NIC ring buffers getting full and unable to cope-up with incoming bursts of traffic CPU receiving NIC interrupts is very bus […]
Show full quote

NIC ring buffers getting full and unable to cope-up with incoming bursts of traffic
CPU receiving NIC interrupts is very busy and unable to process
some cable/hardware/duplex issues
some bug in NIC driver

https://unix.stackexchange.com/questions/1846 … -and-frame-fiel

At last, dropped counts things like unintended VLAN tags or receiving IPv6 frames when the interface is not configured for IPv6.

Thanks for the reply !

progman.exe wrote on 2023-12-22, 22:58:

Is the network cable in good condition? Basic, but worth considering.

Yes, I checked with different cables, same results.

progman.exe wrote on 2023-12-22, 22:58:

If you are on an ethernet hub, then packets might have arrived for other machines on the LAN. You do say "same router", so I guess that is a contemporary ethernet switch in your domestic broadband router. So not a hub. Hubs repeat packets to all ports, switches send packets only to the port where the packet's address MAC can be found.

Yes, that's my main "internet box" on which the outside fiber cable is plugged. I have 5 RJ45 outputs, my Win98 PC is connected directly on one of them.

progman.exe wrote on 2023-12-22, 22:58:

Is the NIC in promiscuous mode? Were you doing any traffic monitoring otherwise? eg tcpdump (hardcore), iptraf or maybe speedometer, they can force a NIC to accept any packets. I thought promiscuous mode was marked on the output of ifconfig though, but can't see it on any machines here right now.

Yeah, I had some extra traffic on the network during the test, nothing too heavy, just Internet TV.
My NIC was not in promiscuous mode. I enabled it and it did not change anything.

progman.exe wrote on 2023-12-22, 22:58:

What NIC is it? Which kernel module? Or more like, does modinfo module-name have any parameters documented? Some of those might address some errors.

My NIC is a Planet ENW-9503/04 PCI Fast Ethernet. I've posted the modinfo outputs below.
I also have the feeling that the modules or drivers might be involved in the problem... Maybe just tweaking some parameters could help. I'd like to check if those errors could be monitored under Windows 98 but have no idea on how to do that.

progman.exe wrote on 2023-12-22, 22:58:

To boot a Linux on 98 hardware, I guess the distro is a bit old? No probs there, but the whole promiscuous mode thing is nagging at me. Did old kernels, or plenty of old modules, run promiscuous by default? I think they might....

It's not so old (BionicPup32 19.03, with Linux 4.19.277). To my surprise, it's even working 128MB RAM (including GUI) !

Some extra notes:

• When downloading something from NAS "Errors" and "Dropped" are increasing.
• When uploading something to NAS, "Errors" is stable but "Dropped" is increasing.
• When doing nothing (even with external traffic like Internet TV), both "Errors" and "Dropped" are stable.

Here are the information about the NIC-related modules:

1root:~#modinfo 8139cp
2filename:       /lib/modules/4.19.277/kernel/drivers/net/ethernet/realtek/8139cp.ko
3license:        GPL
4version:        1.3
5description:    RealTek RTL-8139C+ series 10/100 PCI Ethernet driver
6author:         Jeff Garzik <jgarzik@pobox.com>
7srcversion:     05486AE38C565FD4208FD6E
8alias:          pci:v00000357d0000000Asv*sd*bc*sc*i*
9alias:          pci:v000010ECd00008139sv*sd*bc*sc*i*
10depends:        mii
11retpoline:      Y
12intree:         Y
13name:           8139cp
14vermagic:       4.19.277 SMP mod_unload modversions PENTIUMIII 
15signat:         PKCS#7
16signer:         
17sig_key:        
18sig_hashalgo:   md4
19parm:           debug:8139cp: bitmapped message enable number (int)
20parm:           multicast_filter_limit:8139cp: maximum number of filtered multicast addresses (int)
21
22
23root:~#modinfo 8139too
24filename:       /lib/modules/4.19.277/kernel/drivers/net/ethernet/realtek/8139too.ko
25version:        0.9.28
26license:        GPL
27description:    RealTek RTL-8139 Fast Ethernet driver
28author:         Jeff Garzik <jgarzik@pobox.com>
29srcversion:     3484D660EE0619AE90E4AAC
30alias:          pci:v*d00008139sv000013D1sd0000AB06bc*sc*i*
31alias:          pci:v*d00008139sv00001186sd00001300bc*sc*i*
32alias:          pci:v*d00008139sv000010ECsd00008139bc*sc*i*
33alias:          pci:v000010ECd00008129sv*sd*bc*sc*i*
34alias:          pci:v0000021Bd00008139sv*sd*bc*sc*i*
35alias:          pci:v00001743d00008139sv*sd*bc*sc*i*
36alias:          pci:v0000126Cd00001211sv*sd*bc*sc*i*
37alias:          pci:v0000018Ad00000106sv*sd*bc*sc*i*
38alias:          pci:v000002ACd00001012sv*sd*bc*sc*i*
39alias:          pci:v00001432d00009130sv*sd*bc*sc*i*
40alias:          pci:v000011DBd00001234sv*sd*bc*sc*i*
41alias:          pci:v000014EAd0000AB07sv*sd*bc*sc*i*
42alias:          pci:v000014EAd0000AB06sv*sd*bc*sc*i*
43alias:          pci:v00001259d0000A11Esv*sd*bc*sc*i*
44alias:          pci:v00001259d0000A117sv*sd*bc*sc*i*
45alias:          pci:v000013D1d0000AB06sv*sd*bc*sc*i*
46alias:          pci:v00001186d00001340sv*sd*bc*sc*i*
47alias:          pci:v00001186d00001300sv*sd*bc*sc*i*
48alias:          pci:v00004033d00001360sv*sd*bc*sc*i*
49alias:          pci:v00001500d00001360sv*sd*bc*sc*i*
50alias:          pci:v00001113d00001211sv*sd*bc*sc*i*
51alias:          pci:v000010ECd00008138sv*sd*bc*sc*i*
52alias:          pci:v000010ECd00008139sv*sd*bc*sc*i*
53depends:        mii
54retpoline:      Y
55intree:         Y
56name:           8139too
57vermagic:       4.19.277 SMP mod_unload modversions PENTIUMIII 
58signat:         PKCS#7
59signer:         
60sig_key:        

61sig_hashalgo:   md4
62parm:           use_io:Force use of I/O access mode. 0=MMIO 1=PIO (bool)
63parm:           debug:8139too bitmapped message enable number (int)
64parm:           multicast_filter_limit:8139too maximum number of filtered multicast addresses (int)
65parm:           media:8139too: Bits 4+9: force full duplex, bit 5: 100Mbps (array of int)
66parm:           full_duplex:8139too: Force full duplex for board(s) (1) (array of int)

progman.exe wrote on 2023-12-23, 01:18:

I googled and opened some tabs, and forgot about them. First kind of things that came up probably cover the reason. But I did forget IPv6 exists (I turn it off everywhere), and your interface is not configured for that. I now think the dropped packets will be IPv6 from other PCs, and the router itself.

I definitvely have IPv6 enabled on my network. I understand this could increase the "Dropped" count, but have some doubts about "Errors" count ? Also, nothing is moving if I do not upload or download from my Win98 PC (maybe that's expected, I'm not a network expert).

A Realtek 10/100 card isn't "ancient" by any means. Could be a bad cable. Really old 10BaseT cards are the ones that have problems connecting to modern equipment. The auto negotiation used on new switches trips them up.

I did some speed tests to compare Linux vs. Windows when copying a 1.4GB file from NAS to my vintage PC:
* Windows 98: 1m40s, that's 14MB/s, not so bad for an old machine !
* Linux: 4m13s.

It looks to me that hardware / cables are OK as the 14MB/s speed on Windows 98 is really good (I think ?).

Maybe I could blame the poor Linux performance on the lots of errors happening on it, but of course that could also be other OS differences...

I'm still intersted to have the same performance on Linux, as I'm using it for "big" partitions backup and restoration (when for Windows 98, I'm only transfering smaller saves or games), but that's probably more a Linux / Networking question.

Louthrax wrote on 2023-12-23, 01:56:

It looks to me that hardware / cables are OK as the 14MB/s speed on Windows 98 is really good (I think ?).

Using RTL8139, ie. 100 Mbps, right?
Then it's too good!
In theory 100 Mbps = 12.5 MB/s, in reality the max is about 11 MB/s.

Anyway, make sure that all NICs and switch ports and configured for Full Duplex.

Grzyb wrote on 2023-12-23, 02:44:

Using RTL8139, ie. 100 Mbps, right?
Then it's too good!
In theory 100 Mbps = 12.5 MB/s, in reality the max is about 11 MB/s.

You're right! It was late and I mismatched the file I copied from Windows : it was a backup file in the same directory and the same kind of of naming but with a size of 14GB (so far above the FAT32 4GB limitation), instead of 1.4GB.

The funny thing is that Windows copies the file without any warning ! It just results in a ~700MB or so file instead of 14GB 😀

Doing the test again with the good file this morning: 3m13s, that's 7.23MB/s (vs 5.51MB/s for Linux).