frame-relay payload-compress

[ktripp]

When using this in a frame environment what does this gain? I know it increases the CPU load. Does it offere any benefit to bandwidth?

Thanks,

KT

 

[routerman]

It should offer an improvment but is dependent on link speed, spare cpu capacity and memory. Having looked at this several times in the past I came to the conclusion that the best way to check is try it and see.

The command `sh compress' should give you an idea, if the compression value is less than 1 you are delaying traffic and there is no point in using the compression.

It compresses the data payload.

 

[ktripp]

So given the following input, no real point in having compression then. It just adds latency and higher cpu.


---------------
Serial0/0
Software compression enabled
uncompressed bytes xmt/rcv 57782164/22812659
compressed bytes xmt/rcv 0/0
1 min avg ratio xmt/rcv 0.417/1.590
5 min avg ratio xmt/rcv 0.224/1.639
10 min avg ratio xmt/rcv 0.105/1.647
no bufs xmt 0 no bufs rcv 0
resyncs 0
Additional Stacker Stats:
Transmit bytes: Uncompressed = 251888375 Compressed = 29409407
Received bytes: Compressed = 13046735 Uncompressed = 0

 

[routerman]

Got it in one! I found a document on cisco.com ages ago that described how to read the counters on various compression methods, and <1 indicates no adavantage.

In my experience you always get a better figure for Rx bytes, as they are expanded and anyway the the remote router suffered the pain of compressing them.

As a matter of course I remove this from customers networks unless I see an advantage.

 

[ktripp]

So based on my previous output of the router:
show compression

does the rcv of ~1.5 justify having the compression turned on? Since it is above 1 then it is doing it's job but at a cost of memory/cpu/latency.

 

[routerman]

I would say no, at your router the processor intensive bit is the xmt side, and from the stats that is showing poor performance. I'd take it off.