Help needed with mTCP and the Xircom PE3-10BT adapter

[hyperfrog]

Thank you, Mike, for doing all this testing.

Your FTP testing shows that Jr sends faster (23kB/s) than it it receiving (15kB/s). Apart from there being no latency due to polling, what do you attribute this to? Is reading from the RAM disk less demanding on the CPU than writing to it? Is the FTP protocol easier to handle for the sending computer? Or maybe there were no retries since the receiving computer was fast enough to handle all incoming packets?

As for the "warm weather", it is gone by now. Québec is a place where summer always seems to arrive too late, and when it's finally here, it ends abruptly within a month. I'm just slightly exaggerating.

Christian

[Brutman]

You know, I'm scratching my head about the transfer rate disparities.

Sometimes it is faster to receive than it is to send. Sometimes it is the other way. The only conclusion that I can draw is that when sending is just as fast as receiving that the adapter is probably the bottleneck.

Some possible factors:

• Memcpy is much more expensive on the 8088 than it is on later processors. Anything doing a lot of memcpy is going to benefit disproportionately on the better CPUs.
• The newer machines have the benefit of cache, which really makes them fly.
• The 8088 would often spend a lot of time just waiting for instructions to get to the processor. This doesn't happen on 80286s or better because the instruction fetch mechanism is so much better.
• Flow control varies greatly at different speeds. What works for the PCjr isn't optimal for the Pentium III.
• I think my Linux machine is sending far more ACK packets to my old machines than they are to it. Those represent extra processing for the old machines, without much benefit. (You can observe this by looking at the total packets transferred when sending a file one way or the other.)

To really figure out what is going on I'm going to have to run a trace on the Linux side and try to figure out what the spacing between packets is.

None of my tests have retry problems ... those would be very noticeable.


Mike

[Vorticon]

Mike, I'm having issues with the PE3-10BT adapter. It seems to connect via telnet or ftp for a few seconds, then the connection freezes and is dropped. I have no such issues when connecting to the Jr from my PC via the ftp server.
I have not changed any settings on the Jr, and I have tried a spare adapter with similar results. I replaced the power supply to a beefy 12V 1A one with no change.
This problem started happening a few months ago, and I initially attributed it to a flaky router. But I have recently replaced my router and I still have the same problem.
Any ideas at all what the problem could be?

[Brutman]

Just to make sure I understand, FTP and telnet die after a few seconds, but the FTP server running on the Jr is fine? How does it behave when the connection drops - is the machine hosed or does the program just exit gracefully and go back to DOS?

Another program you can try is netcat .. just use it to make a connection to something and let it sit for a while.

I really can't think of anything wrong at the moment. Mine has been stable. Just to be on the safe side, run the Jr through the diagnostics and memory tests. (Especially the memory ...) You might have a bad DRAM chip and of course we don't have parity memory so the machine will just keep chugging on.

Another thing we can do is take a trace using the trace facilities of mTCP, but on a floppy based system that slows things down a lot - the trace takes time to write to disk. Are you on a floppy based system or do you have a hard drive? Instructions for tracing can be found in debug.txt. Use SET DEBUGGING=127 to get a detailed trace, but not overkill.

Mike

PS: How did you manage to append to this thread three years to the day later? ; - 0

[Vorticon]

Yes, the FTP server runs just fine. With telnet and FTP, the program simply exits back to DOS without locking the machine.
I do have the IDE card and hardly use my floppy drive anymore.
Netcat locks up my machine...
I don't have a diagnostic disk on hand at the moment to test memory, but I don't seem to have any issues with other programs.
I ran a trace and attached it to this message. Its contents don't make much sense to me unfortunately, but maybe you can sort it out.
Regarding the message date, wow that is some coincidence

[Brutman]

This might not be it, but your version of code dates back to Jan 2, 2011. I've made a lot of fixes since then.

Each time one of the programs ends it is going to print statistics. Here are the ones from the bottom of your trace:

Code: Select all

Tcp: Sent 105 Rcvd 102 Retrans 7 Seq/Ack errs 86 Dropped 0
Ip: TcpRcv: 102 UdpRcv: 24 IcmpRcv: 0 Frags: 0 CSumE: 0 ProtE: 0
    Good: 0 Timeout: 0 NoSlots: 0 TooMany: 0 SizeOvr: 0
Packets: Sent: 115 Rcvd: 132 Dropped: 78 LowFreeBufCount: 0

So mTCP figured out that 7 packets were lost and retransmitted those. It also received 86 packets from the other side that had bad sequence numbers in them, implying the other side was seeing us drop packets.

Look at "Packets Dropped:" - that is 78. You are dropping more than half of the packets you received!

This might be a side effect of having the tracing on, so don't get too worried. But the next time you run look at the number of dropped packets. If you are on a really noisy network you might be just flooding the Jr with packets, and if the Jr doesn't process them fast enough it has to drop them on the floor.

(If you have a single connection to a mega-fast host the normal TCP/IP flow control will keep the PCjr from getting overrun. But if you have a lot of network traffic from unrelated machines the PCjr has to look at every single packet to make a judgement on whether the packet is important or not.)


Mike

[Vorticon]

Mike, when trace is off, I don't see any dropped packets. I updated my mTCP suite with no change.
HOWEVER, you had mentioned that there might be too many devices on the network, so I disconnected a couple et voila! Telnet and FTP started working again.
Let's hope this holds up. Thanks for your help

[Brutman]

The tracing adds quite a bit of overhead, so you can do it on a 286 or 386 but a PCjr is just not fast enough to keep up. Hence the dropped packets while tracing.

But if you were not getting dropped packets in normal use, then that points to a different problem. Are you sure that the DHCP IP address that you were getting (or the static IP address that you had set) was unique? If you have two machines on the network with the same IP address bad things like this will happen. You must always run DHCP when you first start using the mTCP applications. That should be good for a few hours to a day depending on your router.

Another possibility is an ARP conflict - had you been moving the Xircom adapter around to other machines? If so, the other machines on the network might have been associating the MAC address with a different machine. That's basically the same problem.


Mike

[Vorticon]

Thanks Mike. There might have been an IP address assignment conflict, but I think I solved it now.