CompuServe Messages

Threehundred years later… Yes, amiga.lib is interesting. Please rp(e/OMD/ObjDump/) on all my previous statements. I forgot that OMD doesn't work on linked-libraries. Well, sorta worked on debug.lib. Anyway I was suprized to see so many Absolute references. These must just be the addresses of the pointers to the actual routines? End of listing was interesting also: _romstart ….. _bootrom ….. _cartridge F00000 _cartridge!? What do they have planned? Hardware manual simply says this address space is reserved for future use. ————– How do you estimate how big the file will be after it's downloaded and how long is it going to take? Why are there 2 file sizes listed? Good questions…and here's the answers: As part of the description of a file in our Data Bases, CIS shows you how a file is stored and shows how large the file is AS STORED ON CIS, and an approxitimation of the file size in binary (8 bit) data bytes. As you browse thru our files you will see a number or set of numbers after the filename. If there is only 1 number listed, then the file is stored as ASCII text and can be read on-line. The file size listed is correct and needs no modification to estimate how big the file will be after downloading. As an example, this file is shown as: TIME.HLP 5985 That means that this file is ASCII text, and is 5,985 bytes long. If there are 2 numbers listed for the filesize, the file is a binary file and one of the numbers will be listed in parenthesis. The first number is based on the way that CIS stores binary files. CIS uses a method known as Packed Intel Hex, and this always makes the file more than twice it's actual size. You can ignore this number. The 2nd number is an approxitimation of how big the file is in binary data. For some reason, this size is always about 10% too high; however, there is a way you can get a very close estimate. Again, lets take an example from our database. ASM101.ARC 250190(106752) This shows that this is a binary file, and CIS approxitmates it's binary size to be 106,752 bytes long. This number is too high and to convert to a useable number take the value inside the parenthesis and divide by 139. Then for every 100,000 bytes listed, add 1 block to the number you calculated. In this case, you would get 106752/139 = 768. Add the 1 block since the file shows over 100,000 and you come up with 769. In fact, to download this particular file takes 769 blocks, so the estimate is exact. To determine the approxitimate file size, multiply the 769 times 128 (the amount of actual data transfered during 1 Xmodem block) and you come up with 98432 bytes. This estimate doesn't take into account any chopping done of the last block but the estimate is very close to actual file size. Estimating time to download is a bit harder. There are lots of variables that can effect the amount of time to download. If you connect to CIS via a direct node, your time will generally be faster than if you connect via an intermediary service such as Tymnet or DataPac. System useage can also play a part in the amount of time it takes to download a file, if system usage is very high, then it can take longer to download a file and that is why we reccomend that you do all up/downloads at slow system times (usually after midnight Eastern Time). Your terminal software can also effect the amount of time it takes to download a file. If your terminal program writes out a block each time it receives one, it will take longer to download than if your terminal software buffers several bytes and only writes to disk every now and then. You can avoid some of this by downloading to RAM: and then copying the file to disk after the transfer is completed, but use caution downloading to RAM:. If you don't have enought free RAM to hold the file, the transfer will terminate due to lack of space, and you won't have the file you were trying to get. Taking all that into consideration, we have come up with a reasonable way to estimate file transfer time. The estimates below are based on using a 1200 baud modem….the estimated values for 300 or 2400 baud are shown in parenthesis after the 1200 baud estimate. Under absolutely ideal conditions, with no delays whatsoever it takes about 1.2 seconds to transfer 1 Xmodem block of data (2400 = .6 sec, 300 = 4.8 sec). That time can never be reached on a packet switched network like CIS due to the reasons above, so for estimation purposes, double it. That means that to transfer 1 block at 1200 baud takes about 2.4 seconds (2400 = 1.2, 300 = 9.2). Now take the estimate number of blocks and multiply by the number of seconds per block from about. Using our sample file, 769 blocks times 2.4 seconds equals 1845.6 seconds…or dividing by 60 = 30 minutes to transfer the file. Using 2400 baud would take about 15 minutes and using 300 baud would take about 2 Hours! I did 2 sample downloads, the first at 2400 baud in fact took 15 minutes. The download at 1200 baud only took 26 minutes so you see this is also a fairly accurate estimation. The 2 downloads were done at different times of the day, so system usage does play a factor. What about if you are using B-Protocol? B-Protocol transferusually takes about 10% less time than Xmodem transfers so at 1200 baud. Thus the estimate for B-Protocol would have been 27 minutes at 1200 baud. Also, B-Protocol blocks are 4 times as large as Xmodem blocks, so you will get approxitmately 193 blocks using B-Protocol, but do NOT use this block number to figure out the estimated time to download. Figure your estimates on Xmodem and then convert to B-Protocol estimates. Again, remember, these are ESTIMATES, and not guaranteed to be 100% accurate. They are a good guide, but whenever you do a download, time the blocks you receive by seeing how long it takes to get block #'s 10 thru 30. Divide that number by 20 and you will get your actual time per block. If it is significantly higher than the above times, abort the transfer and try again at another time when it won't take as long to download. Don't use the first 10 blocks to time your transfer rate. The terminal program has to not only open the disk file, it also has to do what is called "handshake" with CIS, this can add a few seconds to the first block transfered so your timing will not be as accurate. Don Curtis/SYSOP 76703,4321 Amiga Forum