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

Attention: The Community will be in read-only mode on 12/14/2017 from 12:00 am pacific to 11:30 am.

During this time you will only be able to see content. Other interactions such as posting, replying to questions, or marking content as helpful will be disabled for few hours.

We apologize for the inconvenience while we perform important updates to the Community.

New Member

Prioritization on Frame to ATM

Here's the scenario: We have an ATM IMA group at HQ with several PVCs that are switched to individual frame-relay PVCs at each of our stub stores. We are using Wyse terminals to run critical services at the remotes, which rely on our central server echoing all typed characters back to the terminals. In other words, any latency will be apparent with every single keystroke, as the terminal has to wait for the server to echo the character. This is standard on our network, and is typically not an issue.

At one store, however, we have an accounting office which shares the 56k. This office uses actual PCs with browsing capabilities. The terminals often experience unacceptable delays when entering data, since it can take up to a second for each character to echo on the screen.

What is the most common method of making sure the services running on the Wyse terms gets through ASAP without eliminating the availability of web services to the PCs? My guess is Priority Queuing, but I know there's a chance that some of the web packets will drop altogether. Am I right? The default WFQ didn't seem to work all that well. Note that it's not really super important that the accounting PCs have 100% uptime for web browsing, but it would be nice to not have to field calls at the help desk all the time explaining that.

Also, all traffic can easily be distinguished by IP, and not just TCP port (the important machines do only the one task).

What would y'all do?


New Member

Re: Prioritization on Frame to ATM

ask the business what is more critical and build a corresponding queueing policy. I guess it will be the terminals. Priority queueing shouldn't drop any packets if you size the queue depths correctly. Anyway TCP will recover any loss, just make sure you don't loose too many as retransmittion is the network killer.

If PQ drops too many packets, resize your links.

oh yeah, try turning on service nagle. This is a different way of pushing small packets.

CreatePlease to create content