Page archived courtesy of the Geocities Archive Project https://www.geocitiesarchive.org
Please help us spread the word by liking or sharing the Facebook link below :-)


PPP Compress Tests.

The Compress Control Protocol is explained in RFC1962. It handle the negotiation and compression options between the peer nodes. Also it have some options to restart the compress and decompress process when a problem ocurrs.

The BSD Compression Protocol is one of the protocols used to compress the PPP frames. The frames are procesed in the standard way, and before sending to peer, they are compressed. So you are compressing header and data bytes. The normal control packets like LCP are not compressed, to be robust, and because they are used ocasionally. The BSD Compression Protocol is defined in detail in RFC1977.

I did several tests with PPP  using BSD Compression. The dictionary size is kept in memory, and the size is defined by the bits negotiated by peers. Default bits value is 13 bits in this implementation, that needs arround 176Kbytes of memory. In the PPP Minix implementation, we have 2 process, so we use 88K in each process to handle the dictionary (one for transmit and other for reception). The problem in 16 bits machines is that we have no enough memory to have the dictionaries in memory. I tried using less compression bits, so it reduce the compress relation, but still I have problems allocation errors and core dumps. 

Compression speeds up the PPP link. I decided to do some tests to know the relation of the compression. I tested with an ASCII file of 281856 bytes, and the same file but compressed, being a binary file of 109364 bytes. I transfered the files using ftp in binary mode, and in the comparation I changed the negotiation bits.

This table shows the file transfer using PPP BSD compression. The file is ASCII without previous compression.

Bits

File Size

Time

KB/s

Relation

15 281856 46.8 6022.56 3.82
14 281856 50.5 5581.31 3.54
13 281856 58.5 4818.05 3.05
12 281856 68.1 4138.85 2.62
11 281856 76.9 3665.23 2.32

The following table shows the transfer of the compressed version of the file. The file was compressed with the standard compress command.

Bits

File Size

Time

KB/s

Relation

15 109364 48.3 2264.26 1.43
14 109364 53.4 2048.01 1.30
13 109364 65.2 1674.8 1.06
12 109364 65.9 1659.54 1.05
11 109364 63 1735.94 1.10

Testing link speed was 19200 baud. The raw speed transfer was 1920KB/s, the file transfer speed without compression using PPP frame was 1578,12 KB/s. Comparing with the previous tables, using compression in a compressed file have some advantage. This is because data packets have IP headers, that sometimes they are compressed with the VJ compression, but sometimes they are uncompressed. So an IP+TCP header have 40 bytes that you can save if you compress the frames. The first table (with uncompressed files) shows a good link speed up, more than 200%. With compressed files, speed up is arround 10%.

After this comparation, I made a relation between speeds in the following table 

Bits

Relation

15 2.66
14 2.73
13 2.88
12 2.49
11 2.11

The relation from uncompressed to compresed size in the file is 2.58. An interesting issue is that while transfering the compressed file, 11 bit compression shows better speed than 12 or 13 bits.

The tests shows that compression is important to be used, but you need CPU power and memory to have the dictionaries. It helps to speed up slow links, but may be very CPU demanding in high speed links (like 115K) . 

Memory usage is other problem. 15 bits compression needs 690Kbytes for dictionaries only. The total process needs arround 1Mbyte. I defined default 13 bits, so the compress relation is aceptable and we only use the default compilation stack of 128Kbytes. The previous tables shows a good compress relation for 13 bits.

Return to Home


The page's WebCounter count says that you are visitor number since

April 2000.


Copyright - Claudio Tantignone.

Last Modification: Sep 10, 2005.

1