Mike's PCjr Page

Got 10 adapters, Jon? What for? I guess I should have taken two, after all!

Christian

Mike,

My flakey Xircom adapter is set to bidirectional mode, and I'm getting a transfer rate of about 16 KB/s when downloading a 140 KB file from my local FTP server to my PCjr RAM disk. Should I expect more speed? It is slower than INTERLNK, which doesn't even use the bidirectional mode. Why is that so? Is it the TCP/IP overhead that takes too much processing? By the way, There were dropped packets with the defaut settings, so I set MTU to 1400, which reduced the number of dropped packets to 0. I also tried to use IRQ 7 to see if it would speed up things. It works, but speed doesn't improve.

Christian

When I transferred the disk image from the PCjr to www.brutman.com I was getting 18+ KB/sec, which includes the over head for the disk I/O. My disk setup is a SCSI drive on a a parallel to SCSI adapter, so it's not a great performer. You should have gotten around 25KB/sec going to a RAM disk assuming that you are on a NEC V20 and the first 128K of memory is used for the RAM disk. (Things run faster when that first 128k is not used by DOS.)

MTU 1500 is standard for Ethernet - you should not have had to lower it. There are two environment variables for setting buffer sizes that might be interesting to play with - I don't have the code in front of me, but if you look at the strings in the executable you should see TCP_RCVBUF_SIZE and FILE_BUFSIZE, or strings like them. Set them both to 16KB and see what happens. (The default is 8K.)

Interlink is going to be faster for transferring files between two machines - no question about it. TCP overhead is horrendous - it is managing the 'sliding window' for the protocol, computing a 32 bit checksum, and a few other CPU intensive things. But remember that with TCP you can send to *any* machine in the world, not just the one you are directly connected to as with Interlink. For bulk file transfer between two machines use Interlink - for everything else use TCP.

The fastest I have ever clocked a Jr is at 60+ KB/sec when doing a speed test, which does no disk I/O. That was also with a WD8003 adapter tied directly to the bus. The Xircom maxes out around 25KB/sec using a bi-directional parallel port.


Mike

Well, I'm not too sure about the dropped packets. When FTP exits, it displays two lines of information; the first one begins with "Tcp:" and the second one, with "Packets:". I was reading the "Dropped:" value on the second line, but I suppose I should have read the value on the first line.

Yes, my RAM disk occupies all the lower 128 KB (and more). I set MTU back to 1500, but the speed is about the same; it takes roughly 11.5 seconds to transfer a 182-KB file.

There are two environment variables for setting buffer sizes that might be interesting to play with - I don't have the code in front of me, but if you look at the strings in the executable you should see TCP_RCVBUF_SIZE and FILE_BUFSIZE, or strings like them. Set them both to 16KB and see what happens. (The default is 8K.)

I found TCPRCVBUF, FILEBUF, and MLISTBUF. Gonna play with those and see what happens.

Christian

Boy, I'm always replying late to these threads!

Brutman wrote:'All 10 of my adapters' - stocking up?

hyperfrog wrote:Got 10 adapters, Jon? What for? I guess I should have taken two, after all!

I wouldn't call 10 Xircom adapters stockpiling. I call 7 PCjrs, 2 IBM 5160 XTs (one with a 5161 Expansion Unit), 1 8088-compatible XT, 1 286-compatible, 1 386-compatible and a Dell 486SX/33 stockpiling! Okay, I'll save all of this for another off-topic thread.

Back to the subject at hand, let me give you an idea of what I have set up for my main PCjr...maybe this might help you, Christian.

My Racore-DMA'd 736KB Junior has 2 LPT ports - one on the Racore sidecar (4-bit mode, set to LPT2), one on the IBM sidecar (bi-directional mode, set to LPT1 (which has the Xircom adapter connected)). I then connect a standard CAT5E (not crossover) cable to a 10/100Mbps switch. From there, it can access all of my P4 machines (running WinXP or Server 2003 x86-64). I've used Mike's mTCP routines on this machine, and it pings just fine. Even used FTP to copy some 100KB+ files to my B drive without a problem.

The big test I used was using my networking trick to get my Junior to access files on another computer with only 1 boot disk. I tested your adapter on 2 of my Juniors (one with the Racore setup, the other with only an Impulse (640KB) memory/clock/LPT sidecar) and my P3 laptop. I was able to run some old games on my systems just fine.

The REALLY big test was to see if my diskette archival routine would work with your adapter and my systems. With this test, my systems would run old copies of IBM Antivirus, copy files to my server, create images using SAVEDSKF and zip files up using PKZIP (it's around 4MB of software accessed to archive 1 diskette). I was able to archive around 20 360KB diskettes or so per system and a few 1.44MB diskettes on my laptop with absolutely no problems.

Very interesting with the cooling trick. I noticed that all of the Xircom adapters I've tested do get a little warm after a while. You may be right...it could be a bad solder joint in there. When I tested the adapter, the A/C in my apartment wasn't working, so the temp in my place was pushing 90 degrees F (don't worry...it's been fixed since ).

If you don't mind doing me a favor, Christian, check your e-mail. I need you to test something for me...mainly, my networking article. I've e-mailed you a big .ZIP file - the article, a 360KB bootable diskette image, and additional instructions. I want to see if this will work on your setup, and it could help me determine what's going on with all of this.

Sorry...nothing personal...but I have "issues" when someone says something that I shipped them doesn't work even after I tested it. If the adapter is truly bad, we can work out a swap option or something.

Thanks!

Jon

Very interesting with the cooling trick.

Beware of the water condensation on the plastic bag, though. You have to keep it dry. You can also use a hairdryer if you need to check that something will start or stop working when heated. If you need the air to be very hot, just clog the air intake a little bit with your hand. I once spotted a poorly soldered BGA chip on a laptop motherboard using this method. If you know what a BGA chip is, you know it's nearly impossible to resolder at home. (You wouldn't believe how I did it!)

I noticed that all of the Xircom adapters I've tested do get a little warm after a while.

I believe it is normal. There's a microcontroller running at 20MHz in there, and this is 1995 technology.

You may be right...it could be a bad solder joint in there.

It is very likely, and the shocks and vibrations during the transportation may well have aggravated the problem.

If you don't mind doing me a favor, Christian, check your e-mail. I need you to test something for me...mainly, my networking article.

I still haven't received anything.

Sorry...nothing personal...but I have "issues" when someone says something that I shipped them doesn't work even after I tested it.

Listen Jon, I'm sure it was working when you tested it. There is no doubt in my mind about this. You went through a lot of testing -- much more than I would have expected. In fact, you didn't have to test it at all. On the other hand, I know it had issues when I received it, because it didn't work, and then it started working again, whitout my changing anything in the setup or configuration, except for opening the adapter and reworking almost all of the solder joints as well as I could. Did I really fix it for good? I don't know. Time and testing will tell.

I said I should have taken two because it would have doubled the odds of getting one that has no issue. Besides, it seems you already have a good number of them. That's all. Please don't see any bitterness behind that particular comment, because there was none.

If the adapter is truly bad, we can work out a swap option or something.

Thank you, but let's see how it behaves first. It's been running all night, but the temperature is cooler today. Besides, I don't know if I'm getting the transfer rates I should be getting.

Christian

Hey Christian. Like I said before, it's nothing personal against you...it just bugs me that the adapter has issues. And you're probably right...something could have occurred during shipping. Since you already took apart the adapter, how about this oddball trick...any way to put a heat sink on that thing? Just a thought. Yes, I remember trying to work with BGA chips when I was a kid. Not fun.

With the 10 adapters, I just pick them up whenever I find them cheap. Thanks to everyone's testing with the 8088 machines and Xircom adapters years ago, I fell in love with the idea of being able to network my old PCjrs to my modern machines (wthout having to use an ISA card). No bitterness was taken.

E-mail has been resent. Your e-mail account ran a virus scan and thought that the .EXE file inside the ZIP file was a virus.

For the transfer rate...are you using a network switch/router to connect both your Junior and your modern machine, or are you using a crossover cable between your two machines directly? Also, are you using a firewall on your modern computer? Those can affect your transfer rates pretty quickly. When I get home this evening, I'll test out my transfer speeds with Mike's mTCP programs to see how fast my all of my systems go (from 8088 to P4). Should be interesting, to say the least.

Thanks!

Jon

Well, I'm not too sure about the dropped packets. When FTP exits, it displays two lines of information; the first one begins with "Tcp:" and the second one, with "Packets:". I was reading the "Dropped:" value on the second line, but I suppose I should have read the value on the first line.

I track statistics at two levels - the raw packet level and the TCP/IP level. At the raw packet level we are talking about Ethernet frames coming in and out of the adapter. Those frames include ARP packets, TCP/IP packets, and whatever else might be on your network. If on the 'packet' stats you see dropped packets that is a bad thing - it means that the Ethernet adapter was feeding packets to the machine so fast that the machine could not keep up, and it wound up throwing packets away. I compile in room for 20 incoming Ethernet packets. A really long access to the floppy drive might cause you to drop packets.

The TCP stats line is interesting because it shows you the number of SEQ/ACK errors and the number of TCP packets that your machine felt it had to resend to the other side. A SEQ/ACK error is a sign of a dropped or duplicate packet, and it's not really terrible unless it happens more than 5% of the time. Retransmits are ugly - they ruin performance. On the other hand, they also demonstrate that TCP/IP is detecting packet loss and recovering properly.

TCPRCVBUF is the size of the incoming TCP/IP receive buffer. As packets come in off the wire they get dumped into that buffer. Bigger is better - I think you can go to 16 or 32K, although for FTP 8 or 16K is probably fine. FILEBUF is the size of the disk reads/writes that will be done - once again, 8K or 16K is a good size. Smaller buffers save memory, but start to affect performance. At 4K performance is tolerable. Around 2K things go to hell ... and below MTU size you are wasting bandwidth on the Ethernet and causing extra TCP/IP processing overhead.

MLISTBUF controls the size of the buffer used for holding multiple filenames when you do an mget or an mput. I think the default is 2K, which is quite a few names.

Jon,

I have a few Xircom adapters sitting here in reserve too. When I got the first one working I went on a buying spree too, and for exactly the same reasons you did. Everything I own has a parallel port, including the IBM 5140 Convertible (with the proper 'slice'), so that makes the Xircom a universal solution. And it runs with DOS 2.1 and my code, which is even nicer.

I've not had any Xircom's flake out of me, so that was slightly strange to read. I've had problems with Adaptec parallel-to-scsi adapters overheating and croaking, and probably for the same reason - a microcontroller in a cramped plastic enclosure in the back of a warm machine. Besides the microcontroller in the Xircom it has a 32KB RAM chip and some amps for driving current down the twisted pair. The 300 to 500 milliamps that it draws is a lot for a small device in that enclosure. You guys just got lucky ..

You should see my collection of SCSI and Ethernet cards. I think I need to see a shrink.


As for performance issues - a crossover cable to a machine is the ultimate solution because you can't get a collision or a buffering delay. A connection to a real switch is fine too, as switches move packets fast enough that a Jr can't measure the latency. I actually do all of my testing on a system connected to a hub - as long as other systems aren't using the network at the same time you won't have collisions, so that should be ok. I might be shortchanging my performance by a few tenths of a percent by doing that, but the hub is so retro looking.

Here are some rough numbers using the 'speedtest' option on my netcat program:

• V20 Jr with a Xircom on a bi-directional parallel port: 25 to 30KB/sec
• V20 Jr with a WD8003 card grafted on: 60 to 65KB/sec
• 384-40 with NE2000 clone: something well north of 450KB/sec. (Maybe as high as 650 ...)

The speedtest options just does a throughput test - no disk I/O. I usually test using a 4MB file.

I think that on faster systems you are not going to see a linear boost in speed because the buffer space is too small. If I knew I was coding for a 386 or a Pentium I would burn more memory on buffering and advertise a larger TCP/IP window. That sliding window protocol really speeds things up, but it requires buffer space to avoid sending ACKs needlessly. If I knew I was on a better machine I would also start adding more tweaks to the code to cut down on ACK sending. And lastly, the 386+ processors can do 32 bit math in registers, something I'm not taking advantage of now. The TCP/IP checksum calculation is a pig using 16 bit math - it could be 2 or 3x faster with the extended registers.

I had originally coded the checksum calculation in C on the 8088. Having the checksum calculation like that was horrible, and decreased performance of UDP processing by about half. (Checksums are optional on UDP - if I ran without them the speed doubled.) Unfortunately checksumming is required for the IP header and TCP payload. I rewrote that code in assembler using 8088 instructions and it was like night and day, but it could still be faster.

Well, I'm still getting a maximum transfer rate of 16KB/s, and this is using a crossover cable plugged directly into the other computer. In addition, the only disk I/O involved is in writing the received data to the RAM disk, not to the floppy. Speed seems to be slightly slower when I connect Jr to the modem/router, but not significantly. I don't think the FTP server is to blame, because I get ridiculously fast transfer rates when FTPing from another modern PC to the server machine. I played with the buffer sizes, to little avail. Do I have to write SET TCPRCVBUF=16, 16K, 16KB or 16384?

I will try your boot disk, promised. Maybe things are faster under DOS 5.0.

As concerns the dropped packets on the second line (Packets: [...] Dropped: xx), I only get those when connected to the modem/router. It seems that if I start the FTP client, and just let it wait without transferring any file, there will be some dropped packets when I exit the client. The more I wait, the more dropped packets I get. Maybe the router is querying the machines on the network to determine if they are still alive or something.

Is it normal that when I start the FTP client from C:, and then issue a "lcd a:\" command, it replies "Directory changed to: C:\"? Can't the local directory be changed to another drive?

Christian