pekka-r@obelix.liu.se (Pekka Akselin [The Mad Midnight Hacker]) (01/09/88)
Hello! Does anybody out there, in the netland, have any kind of information how well different data transfering programs does its job. I want to know how many bytes per second each program transfers, in either direction, and what buadrate gave the numbers. This should be counted for raw, 8-bit binary data. Some possible programs are KERMIT, XMODEM, UUCP, SAFT and so on. Thanks in advance. /pekka [The Mad Midnight Hacker Strikes Again] ______________________________________________________________________________ Inet: pekka-r@obelix.liu.se ARPA: pekka-r%obelix.liu.se@uunet.uu.net UUCP: pekka-r@obelix.UUCP | {mcvax,munnari,uunet}!enea!liuida!obelix!pekka-r Pekka Akselin, Univ Linkoping, Sweden (The Land Of The Mad Midnight Hacker 8-)
bird@kksys.UUCP (0000-Mike Bird) (01/12/88)
In article <1396@obelix.liu.se> pekka-r@obelix.liu.se (Pekka Akselin [The Mad Midnight Hacker]) writes: > >Hello! >Does anybody out there, in the netland, have any kind of >information how well different data transfering programs >does its job. I want to know how many bytes per second >each program transfers, in either direction, and what >buadrate gave the numbers. Unfortunately, Bytes/Second would only be applicable for the specific hardware/firmware combination being tested. There is such a difference between disk controllers (DMA vs CPU, clock speeds, etc.) disk drives, the BDOS and BIOS being run, etc. That two machines of supposedly the same configuration can be quite different. So, what your looking for is the comparisons for the different programs done on the SAME MACHINE, preferably near in time. This can best be expressed as in index number, with perhaps PIP being arbitrarily set to the index of 100. Then, each program would have to be tested against PIP on the same hardware/software configuration. Tests done on two different machines would almost be worthless. Also, the same program may behave differently depending upon the hardware, so if your particular setup has, for example, a DMA disk controller, you may be better off with a program that takes advantage of the controller, even if the index number is higher than a different program that doesn't. In other words, this is a VERY subjective test. -- ================================================================================ Mike Bird (These opinions are mine, dammit!) Mail paths: bird@kksys.UUCP -or- Void where prohibited by law. ...rutgers!meccts!kksys!bird
shaprkg@sdcrdcf.UUCP (Bob Shapiro) (01/14/88)
In article <531@kksys.UUCP> bird@kksys.UUCP (0000-Mike Bird) writes: <In article <1396@obelix.liu.se> pekka-r@obelix.liu.se (Pekka Akselin [The Mad Midnight Hacker]) writes: << <<Hello! <<Does anybody out there, in the netland, have any kind of <<information how well different data transfering programs <<does its job. I want to know how many bytes per second <<each program transfers, in either direction, and what <<buadrate gave the numbers. < <Unfortunately, Bytes/Second would only be applicable for the specific <hardware/firmware combination being tested. There is such a <difference between disk controllers (DMA vs CPU, clock speeds, etc.) <disk drives, the BDOS and BIOS being run, etc. That two machines of <supposedly the same configuration can be quite different. So, what <your looking for is the comparisons for the different programs done on <the SAME MACHINE, preferably near in time. This can best be expressed <as in index number, with perhaps PIP being arbitrarily set to the <index of 100. Then, each program would have to be tested against PIP <on the same hardware/software configuration. Tests done on two <different machines would almost be worthless. Also, the same program <may behave differently depending upon the hardware, so if your <particular setup has, for example, a DMA disk controller, you may be <better off with a program that takes advantage of the controller, even <if the index number is higher than a different program that doesn't. < <In other words, this is a VERY subjective test. < <-- <================================================================================ <Mike Bird (These opinions are mine, dammit!) Mail paths: bird@kksys.UUCP -or- <Void where prohibited by law. ...rutgers!meccts!kksys!bird I beg to differ with you. At 9600 baud you send at a rate of about 10 bits per character or a character about once a millisecond. Almost any computer on the market can send at that rate so I suspect the clock rate on the computer would have little to do with it. The following things affect performance in my opinion: 1. The amount of overhead in the protocol. 2. In certain protocols the distance between the sending and receiving computers. If the protocol has a "send-ahead" feature then this is not a consideration but if each message has to be "ACKED" before the next is sent then the turn-around time if you are going through a satellite link is quite a large delay. 3. The error rate on the line may affect you. There are three types of protocols. Those with large messages (which have a low overhead but are very susceptible to line noise), those with small messages (which have a high overhead but are not as susceptible to line noise) and a few protocols which adapt their message size according to the number of retransmissions which are required. Obviously the latter is the most efficient but it is also the most complex. 4. How much overhead is spent in the disk logic. At one extreme you can have the disks on both ends reading or writing single CPM sectors of 128 bytes in a non-DMA world. Thus you must delay on both the sending and receiving end for the disk. This delay is significant and may result in the overall time doubling or tripling. On the other extreme is a hard disk with DMA and very large buffers so any disk activity is rare. There may be literally no overhead at all in this type of environment. The bottom line is that the software is responsible for most of the delays in the transmission. I have written transmission programs which buffer 16K inputs from a floppy disk (without a DMA) and write 16K outputs to the floppy disk. They use very large messages and have few overhead characters in the message. When running "back-to-back" to transfer data from one computer to another I have run at 19200 and can move the data at better than a 95 per cent efficiency. Mind you because of the "back-to-back" situation there were very few "hits" on the line and the protocol was not very clever when "hits" occurred but the nature of a "back-to-back" situation is that the line tends to be error-free. Also since many of my files were less than 16K in length the transmission tended to be "memory-to-memory" with only the original read and the final write taking up any disk time. It would be my educated guess that the same transmission program would run at about the same speed on almost any computer on the market. Bob Shapiro