Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

FCIP compression at speeds beyond 45Mb/s

Hi Tim,

I remember seeing a document about the compression being less effective at speeds beyond 45Mb/s from Cisco somewhere. Can you point to the link? Tx!

1 ACCEPTED SOLUTION

Accepted Solutions
Cisco Employee

Re: FCIP compression at speeds beyond 45Mb/s

Between Tampa & Chicago, compression will probably be an extreme benefit to you but I would test it with the same dataset to verify. Depending on the capabilities of network, you might want use a 2300 MTU on all links along the way. Then use auto compression and this will cover all of the bases. Be sure to use 2.1.2b or later.

HP CA cannot be used with FCWA since CA does not use the transfer_ready SCSI command that WA traps on.

4 REPLIES
Cisco Employee

Re: FCIP compression at speeds beyond 45Mb/s

I'm not sure if this is posted to the webpage or not. I believe the sales organization might have some performance numbers documents that would show this.

Using SAN-OS 1.3, around the 45M bandwidth point, the time it takes to compress the data becomes more than the time it would take to just send the frame out uncompresses. There is the obvious issue regarding RTT, distance, data set, that needs to be considered but the 45M is a rule of thumb.

In 2.X and above, using auto mode can sense when the data needs to be compressed or not. Especially with the 9216i which can do hardware compression for mode1. So, it is possible to get 100M over a 9216i interface using auto mode. However, there is a bug in 2.0.3 and resolved in 2.1.1a dealing with the interface going down when using auto or mode1.

The mode2 and mode3 settings are meant for low bandwidth links, while mode1 is meant for high bandwidth links. The mode1 uses hw compression in the 9216i and the 14+2 line card, and sw compression in IPS-8 and IPS-4 line cards.

For a number of WAN bandwidths, using a combination of the compression modes may be better than using a single compression mode, to get better throughput. The auto mode attempts to use a combination of compression modes to increase the throughput.

The SW compression mode1 in IPS-8 and IPS-4 can sustain traffic up to 100 Mbps over the WAN link. So, for a WAN links above 100Mbps, it is beneficial to compress certain packets with mode1, and transmit the remaining packets without compression.

Therefore, the auto mode in IPS-8 has 4 possible compression schemes: mode1, mode2, mode3, and no-compression.

Auto mode in the 9216i and the 14+2 has 3 possible compression schemes: mode1, mode2, and mode3.

Based on the WAN bandwidth configured, the auto mode picks two compression schemes that are appropriate for that bandwidth, one scheme is a lower cost scheme (compression cost), and the other is a higher cost scheme, relatively for that bandwidth. The auto mode selects one from the two schemes based on the current TCP shaper queue size. The TCP shaper queue is the list of packets that are queued by the shaper, as a result of throttling for the WAN bandwidth. When the TCP shaper queue is above a high watermark threshold, the auto mode switches to the higher cost scheme, and when the queue goes below a low watermark threshold, the auto mode switches to the lower cost scheme. This scheme works because when there are a lot of packets queued, there are more idle CPU cycles (that are available for compression), and when there are fewer packets queued, there are few idle CPU cycles. Hence, using the auto mode, we are able to effectively utilize the CPU cycles, and to get a better utilization of the WAN bandwidth.

For example,

- For a T3 link, using a combination of mode1 and mode2 may be better than using either mode1 or mode2 alone.

- For a 200 Mbps link, in IPS-8, using a combination of mode1 and no-compression may be better than using either one alone.

This flexibility would allow us to demonstrate real time adjustable compression on a WAN link as opposed to 1.X or our competition which would turn on compression even if it wasn't needed.

New Member

Re: FCIP compression at speeds beyond 45Mb/s

Tx Tim for the great info! For my specifice situation, the setup is a pair of 9261i in Tampa and Chicago sharing a dedicated OC-3, which has a measured RTT of 45ms. The application is HP's Continuous Access XP Journal (aka Hitachi TrueCopy). Is compression recommended in this particular setup? How about write acceleration? Can Continuous Access take advantage of write acceleration? I read that write acceleration is dependent on the application. Tx a bunch!

Cisco Employee

Re: FCIP compression at speeds beyond 45Mb/s

Between Tampa & Chicago, compression will probably be an extreme benefit to you but I would test it with the same dataset to verify. Depending on the capabilities of network, you might want use a 2300 MTU on all links along the way. Then use auto compression and this will cover all of the bases. Be sure to use 2.1.2b or later.

HP CA cannot be used with FCWA since CA does not use the transfer_ready SCSI command that WA traps on.

Bronze

Re: FCIP compression at speeds beyond 45Mb/s

Compression and FCIP WA work with HDS Truecopy. FCIP WA should help if the RTT is 45ms. Compression should help if your pushing too much traffic for the OC-3 bandwidth.

Dallas

Sydney TAC

264
Views
8
Helpful
4
Replies