Hi!

I'm having problems with the de driver in -current since the changes to
the transmitter that were supposed to make it more stable. My system works
for some time (a couple of days, perhaps) and then the transmitter stops
functioning properly. Sometimes it stops and won't work anymore until a
packet is received. Here is an example, pinging from a remote machine
to the 164SX via the full-duplex interface:

ajo@pluto ~ >ping ymer
PING ymer.ulmerkott (192.168.0.1): 56 data bytes
[cut]
64 bytes from 192.168.0.1: icmp_seq=12 ttl=255 time=0.1 ms
64 bytes from 192.168.0.1: icmp_seq=13 ttl=255 time=0.1 ms
64 bytes from 192.168.0.1: icmp_seq=14 ttl=255 time=1000.2 ms
64 bytes from 192.168.0.1: icmp_seq=15 ttl=255 time=1.5 ms
64 bytes from 192.168.0.1: icmp_seq=16 ttl=255 time=0.2 ms
64 bytes from 192.168.0.1: icmp_seq=17 ttl=255 time=0.1 ms


My machine (a 533MHz 164SX) has two identical 21140 based cards from
Addtron. One is connected to a hub and the other is running full duplex
directly to another 21140 based card. The problem only seems to take place
on the card running full duplex or atleast it does much more frequently.
Full duplex is really working on both ends of the crossed cable, no
collisions are reported on any side.

I also have worse UDP transmitting performance than I do TCP:

ajo@ymer ~ >ttcp -tsu pluto
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  udp  -> pluto
ttcp-t: socket
ttcp-t: 16777216 bytes in 2.81 real seconds = 5835.56 KB/sec +++
ttcp-t: 2194 I/O calls, msec/call = 1.31, calls/sec = 781.45
ttcp-t: 0.0user 0.3sys 0:02real 12% 0i+0d 0maxrss 0+1pf 140+19csw
ajo@ymer ~ >ttcp -ts pluto
ttcp-t: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp  -> pluto
ttcp-t: socket
ttcp-t: connect
ttcp-t: 16777216 bytes in 1.43 real seconds = 11475.53 KB/sec +++
ttcp-t: 2048 I/O calls, msec/call = 0.71, calls/sec = 1434.44
ttcp-t: 0.0user 1.0sys 0:01real 75% 0i+0d 0maxrss 0+1pf 2792+77csw


Transmitting cpu usage seems unresonably high for TCP (and maybe for UDP
too). TCP transmitting cpu usage is much lower on the card connected to
the hub (33% for 9024KB/sec). Receiving performance is quite ok though:

ajo@ymer ~ >ttcp -rsu
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  udp
ttcp-r: socket
ttcp-r: 16777216 bytes in 1.40 real seconds = 11691.42 KB/sec +++
ttcp-r: 2050 I/O calls, msec/call = 0.70, calls/sec = 1462.86
ttcp-r: 0.0user 0.1sys 0:01real 10% 0i+0d 0maxrss 0+0pf 2042+25csw
ajo@ymer ~ >ttcp -rs
ttcp-r: buflen=8192, nbuf=2048, align=16384/0, port=5001  tcp
ttcp-r: socket
ttcp-r: accept from 192.168.0.2
ttcp-r: 16777216 bytes in 1.48 real seconds = 11044.93 KB/sec +++
ttcp-r: 11439 I/O calls, msec/call = 0.13, calls/sec = 7711.36
ttcp-r: 0.0user 0.3sys 0:01real 26% 0i+0d 0maxrss 0+1pf 11008+10csw



Another problem I'm experiencing is "bad interactivity" when logged into
the full-duplex interface using rlogin as opposed to ssh. This is,
however, the same on x86 machines too.

I'm not sure if these problems are related, but I would very much like my
full-duplex interface to function better. Right now I have to reboot my
machine once in a while when the transmitter stops working. Any ideas?

Should I send-pr this?

/Andreas