Scott, Thread,
When it comes to sending image files...
Often, image files by their very nature are compressed in their native form from the application that produces them, and as such, they are "already compressed to near optimum ratios" by the time they are loaded on a platform and set to go over the medium.
In other words, there is usually no further compressing of these files, and you very often might run the risk of adding unnecessary headers, envelopes, etc., if you attempt to further compress them, and begin to defeat the purpose of compression, with each added attempt at further optimization.
Usually, once they are compressed into JPEG, ABIC, or whatever, they are regarded as payloads which are set for delivery, and they usually receive no further compression. Sometimes, due to architectural dictates in a larger universe of applications, it is necessary to add another layer of compression simply to keep all files uniformly packaged over the WAN (such as when image files are sent over IBM main fram channel extended faciliites), however, for the sake of uniformity, and the foregoing penalties would apply, but that's life.
---------
Also, when computing throughputs over T1s, it's necessary to take into account the type of framing used on the line itself. If it is using Bipolar 8-Zero Suppression (B8ZS), and does not involve any spoofing in this respect, then you very often have a line that is capable of no more than 1.344 Mb/s, for starters. On T3 and OC-n lines, similar forms of atrophy occur for other reasons [SONET Overhead, high speed serial interface <HSSI> penalties, etc.]. The main point is this: you very infrequently wind up sending at the rated speed of the line for a variety of reasons.
Beyond these factors, you must take into account TCP/IP overhead (or worse, ATM overhead), and the amount of time necessary for "normal error rates" and retransmissions, when line errors occur.
In a campus setting using fiber facilities, errors could be considered negligible under most properly engineered conditions, but over the WAN they could be considerable. For WAN purposes, using an total overhead factor (headers and occasional retransmissions) of 12-15% on IP links, and 30-40% for ATM links is not unreasonable.
BTW, I thought it was interesting that Mr. Kroll pointed out that an OC-12 interface [equivalent to a line rate of 622 Mb/s raw] was used on the SGI workstation. When SONET overhead is removed, and some of the other factors are taken into account, you are left with something like 500 Mb/s usable throughput capacity. These and other factors which I've enumerated above would account for the limited speed of the link, since you cannot drive the line faster than the I/O, itself, nor faster than the constraints imposed by other overhead sources of various origins.
Regards, Frank Coluccio |
