Gabe This is probably the result of packet optimisation on your WAN (I've seen this on X.25 based WANs - it looks like your problem even if not an X.25 WAN).
You need to look at the packet forwarding parameters on the WAN nodes - they are typically set to forward packets under the following conditions: * When full * On a timeout (configurable in milliseconds) * On receipt of specific characters - usually C/R, N/L, CTRL-Z and a few others of similar ilk. You need to crank the timeout WAY down and you may want to make sure that the packet forward parameters include backspace, ESCAPE, DEL and all of the above. You will need to do this on ALL nodes in the data link. You may also want to adjust the packet size - unfortunately I can't tell you which way - UP or DOWN. Large packets favour network throughput at the expense of response times (delays to fill packets). Small packets favour response times at the expense of network traffic. HOWEVER - under heavy load small packets cost you, because you occupy too much of the network bandwidth with packet overheads and not enough with your data. It's swings and roundabouts - you need to get the measure of your network parameters and usage to tell what's happening. Points to watch: * Packet consolidation - a good idea - up to the WAN provider. Watch the packet forwarding parameters though. * Bandwidth - do you have a guaranteed minimum? If not (for example) a SLA of 8MB average can be meaningless if you have to connect between 1am and 5am when the throughput is 500MB to get the average up to that level, otherwise it's 0.5MB due to high traffic and bandwidth sharing. What matters for you is the *MININUM GUARANTEED* bandwidth - check nd discuss with your WAN provider. * Are you getting lost packets requiring lots of re-transmissions? X.25 at least was poor here, I mean REALLY poor...... The fix is at the network physical and logical configuration level (L7 window size comes to mind as a point to watch). Hope it helps - it can be a long topic (you could tell I know).... If you want anything specific please drop me a note separately with some details of your configuration. If you are using UniData you can see if UDT.OPTIONS 109 ON helps (probably not though). Regards JayJay -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gabriel Green Sent: 20 May 2007 13:36 To: [email protected] Subject: [U2] Telnet server parameters, and latency... We just deployed a new nationwide WAN for our stores with DSL as the access method (not public DSL, DSL to a MPLS backbone, private, never touches the public internet)... I have noticed that latency is a bit of a problem in some locations. Now I am working with the provider to see what they can do on their end, but my users in a few locations have noticed that, as compared with the frame relay we replaced this new network with: * They will get disconnected sometimes too quickly * The typical latency-related problems of typing into their dumb terminals (Cisco 2500 series or Systech port servers contain the telnet program for the non-AccuTerm locations) and having unpredictable response time--IE, jitter. Is there anything in the telnet server portion of UniAdmin I should look into adjusting? Currently defaults are: Keep alive interval 1000; Keep alive time 72000000, Max Data Retransmissions: 5 Any suggestions until we fine tune this a bit? Besides replacing the serial terminal servers. Been there done that, boss isn't ready to buy 120 of them at once just quite yet... Thanks, Gabe ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/ ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
