Xmodem thruput ?

I am current looking a Xmodem communication to and from HAAS using Hyperterminal.

Settings at HAAS 115.2 kbaud, 8 data bits, parity none, 1 stop bit, and obviously Xmodem which means no hardware, or Xon-Xoff, or DC codes.

Same settings at IBM PC in HyperTerminal and FIFOs disabled.

Sending from HAAS to PC the rate is about 2700 characters per second with no retries. The theoretical maximum thruput should be 115200/(1+8+1) = 11,520 characters per second. This has to be reduced by the overhead of header, checksum, and ACK --- 128 / (3+128+1+1) = 0.962 . So theoretical max is 11,520 * 0.962 = 11,082. Thus, thruput efficiency is 2700 / 11,082 = 24.4 %.

I do not remember the value but the other night I ran a test from HyperTerminal to HAAS. The efficiency was much better, but I believe below 50%.

My test file for transmission was about 170,000 bytes.

Is all the problem at HAAS, or partial, or not at all? How much of the problem is HyperTerminal?

Can anyone else confirm my results, and/or with a different communication program?

In non-Xmodem mode thruput is quite close to theoretical maximum using Cimco Edit.

.

Continued experiments:

The transfer rate from HyperTerminal to HAAS is about 4000 bytes/second or 4000/11082 = 36% efficiency. Much better than in the other direction, but not good.

With a different sending program my thruput was 6870 or an efficiency of 62%.

I believe the next step is to monitor with a scope and see how much delay exists from the end of a packet until HAAS sends an ACK byte to the sender. This should provide us with information on the maximum possible thruput with our 2000 HAAS receiving.

.

Monitoring data flow with a scope.

For thruput sending to HAAS all the problem of latency is at the sending end.

The theoretical time to send one packet is:
(1/11.52)(3+128+1) = 0.0868 * 132 = 11.45 MS. On the scope I measured about 5.8 x 2 = 11.6 MS which correlates very well.

The delay from the end of the packet to the ACK from HAAS varied from 0.4 to 1.0 MS. Thus, for the longest delay to ACK the total time is 12.45 MS, and for 128 bytes that is a maximum possible effective thruput of (1000/12.45)*128 = 80.23 * 128 = 10,281 bytes per second. Something is grossly wrong at the sending end.

.

Hyperterm is the worst possible terminal program to use in Windows, its a real mess. Try Teraterm, much more flexible and robust- and is a free download, google will provide the link.

Regards,

Greg

Greg:

You are correct that HyperTerminal is a mess. I have been testing it because a number of users seem to be using it. As a test tool it does have some value just because it comes with Windows and if I am talking with someone I do not have to have them try to download and apply something they may not want on their machine.

I will try Teraterm in my experiment and see how it performs. I believe some time in the past I tried it. I only directly use RS232 programs for testing and usually it is our own program or Cimco.

Have you done any Xmodem thruput tests at 115.2 kbaud with Teraterm or any other software? If so, what were the results?

.

I've done it in minicom under Linux, datarates up to 57kbaud (embedded system program loader, cpu clock was too slow for 115kb), I don't use Windows for anything more than word processing or web browing. Some throughput improvement can be had using 1k xmodem (sometimes called ymodem) if both ends support it.

You <might> be able to adjust the uart's fifo depths; suggest turning them off or making them very small, maybe there is a rx threshold issue on the PC end. I think I recall some stuff related to that in the serial port driver tabs in the control panel.

wrt datarates, xmodem is quite tolerant, the ACK protocol allowing the receiver time to process which is handy. I didn't note any material sending delays with minicom. My data was a S3 formatted binary image, gzip'ed to cut down on the # of bytes to transfer. xmodem to let the receiver decompress the incoming data before receiving more. Interestingly, minimum gzip compression was optimal- max gzip compression led to increased time needed to decompress beyond the the xfer time savings that compression provided.

Greg

Greg:

I almost never run with FIFOs enabled, with HAAS I do not believe there is a problem, although I do not know what their input buffer size is.

The computer sending UART FIFO is a real problem for at least some Fanucs. In these cases the 16 byte UART FIFO can overflow Fanuc.

In Windows it appears that you can change the FIFO depth, but in fact the standard 16550 class of UARTs can only have the FIFO on or off. Thus, in Windows they are doing some external processing outside the UART to limit the number of bytes in the FIFO.

At a UART divisor of 16 the input clock for 115.2 kbaud is 1.8432 MHz. How slow is your CPU clock? Any integer multiple of 1.8432 is a satisfactory basic clock frequency. For example 12.9024 MHz is not an uncommon value. This requires divide by 7.

On HAAS the only available flavor of Xmodem is the basic original form with a packet of 3+128+1 bytes.

.

The cpu was a 12mhz MIPS R3000 and the uart was very simplistic with a 1 byte receive register. Had to run polled even for 56k, ISR overhead was fairly high- but in a boot loader polled was more efficient anyhow.

The Windows serial comms stuff is an unmitigated disaster and has been since the old 3.x days. I wouldn't be surprised if the poor performance is caused by Hyperterm requesting broken features.

As far as uarts go I don't think any modern uart firmware would be using a ~1mhz clock, 10yrs ago or so 32x sampling was common even up at megabit rates. Strange that reasonably modern cnc controllers would persist in 80's vintage PC-style serial datacomm pathologies- but if its not too broken then why fix it I suppose.

Regards,

Greg

Greg:

I downloaded a version of TeraTerm, 3.1.3.0, and I did not get it to communicate with HAAS in Xmodem. I only attempted to send to HAAS. It does not look like a good program for me to try to explain to someone via phone on how to use the program.

I did some more controlled experiments with our DOS program sending to HAAS. Packet to packet time was 12.2 to 13.5 MS by scope measurement. If we assume an average of 13 MS, then the thruput is 1000/13 = 76.9 packets per second, or 128*76.9 = 9846 bytes per second. This is 11.45/13 = 88% of theoretical maximum thruput at 115.2 kbaud and 8N1 for setup.

Next I will run a timed test on a large file.

Our DOS program links with HAAS very quickly. A couple seconds. And you can start communication from either end. HAAS puts out a NAK every second until link occurs. HyperTerminal takes a very long time to link. Seems like minutes. TeraTerm never linked.

.

Yes, teraterm does have a bazillion options... There must be some other Windows terminal apps though.

88% is probably about as good as it will get, the pauses between packets being necessary to process what was just sent, the wasted time is the interval between the ACK and the next packet. It seems as if Hyperterm is waiting for the ACK to reach it- a software rx queue that flushes on a timeout when its not full could be a culprit. IIRC the Win32 api on which Hyperterm is written allows an app to select some buffering options for the serial datacomm, but I don't know how you might be able to influence Hyperterm to use different ones.

One option might be to try and run the old Windows 3.1 terminal program (which did run in Win95 IIRC). Its no gem either but nowhere near as braindead as Hyperterm.

Greg

Where are the users of Xmodem with HAAS?

A file of about 500,000 bytes and a stop watch are sufficient to get a measurement of thruput. Does anyone have some data for me?

Doing a search it appears that Seymour is using TeraTerm. Seymour what version do you use on what operating system and can you do a thruput measurement?

.