These are interesting observations. Even more interesting is a story slowly rising to the top of the news, having been upstaged by run-away-bride, that the U.S. over the past four years has slipped from the leader in bandwidth to #15 in the world market. Some authorities now describe us as driving on dirt roads compared to Japan's Super Highway. ...tx/t
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:hardhats- > [EMAIL PROTECTED] On Behalf Of Cable One > Sent: Wednesday, May 11, 2005 10:23 PM > To: [email protected] > Subject: [Hardhats-members] Re: Slow CPRS performance over VPN > > After reading all of the interesting comments regarding the cause of the > slow CPRS I would like to throw in my 2 cents worth. > > I am not sure that this is a BANDWIDTH problem, but rather a problem of > the > WAN (wide area network) not being designed to handle the kind of network > traffic that it is being tasked with. I am rather new to Vista and CPRS, > but > I am a bit of an old hand with the design of wans for all sorts of network > traffic. > > The performance of a client-server relation pair is mostly dependant upon > the sort of network traffic that will travel upon it. Given that we are > running this on tcp/ip I will focus there. When we speak of bandwidth, > most > of use really mean THROUGHPUT or how much data can I move in some unit of > time. TCP uses the concept of a window to control the flow of data and > verify that all of the packets get to their destination. This window is > just > the number of packets (or bytes of payload data) that the sender will send > until it insists upon receiving an acknowledgement from the receiver. As > the > receipt of this ackknowledgement requires a round trip from sender to > receiver to sender, this throughtput can be described as: > > T = WINDOW(in bytes) / RTT(round trip time) > > The RTT is made up of 3 components: > 1. Propagation delay. Set by nature as in the speed of light or > electricity through a wire (60-80% C) > 2. Queueing delay. The waiting time in the tcp/ip stacks of routers, > interfaces, switches etc. > 3. Transmission delay. This is the BANDWIDTH. This is the speed with > which you can load the media. How fast can data be put into the end of the > wire/optical fiber etc. > > The window size is variable, negotiated by the tcp/ip stacks at either end > of the connection. The propagation delay is mostly out of our control. > The > queueing delay is mostly out of our control. The transmission delay we can > have some sort of control over bits of it....how fast is my ethernet > connection to the router? how fast is the DSL that I am paying for? Most > of > these parameters are not in our immediate control at all, and can only be > measured in aggregate with other parameters. We can buy more bandwidth on > our DSL connection and this will have the effect of lowering the > transmission delay (ie, increasing bandwidth) but this only has a limited > effect on increasing the throughput of the connection. > > This discussion has made the assumption that we are looking at the steady > state transmission of a data stream. You can see (I hope) that the > throughtput gets exponentially worse with increasing RTT. This REALLY > causes > problems when the nature of the client-sever traffic is not a steady > stream, > but rather a series of short transactions. In a network with highly > variable > RTT and lots of short transactions the transfer of data can be almost > unbearable. Welcome to the world of using Microsoft Access over the > internet > with a VPN. Its performance is terrible. > > If CPRS is communicating with lots of short messages, this can make VPN > over > the internet a less than desirable network design. Buying more bandwidth > will help some, but may not be a cost effective solution in your case. > Given > what was said about the configuration of the network described I would > want > to know more about what else was being done with Internet traffic in the > remote and local lans, ie how many people are doing streaming audio, video > etc. I do not think that bandwith monitoring would be of much value. I > would > be more interested in conversation monitoring.....or looking at the > individual tcp data streams between server and client (vista and CPRS) and > analyzing those in terms of delay times and retransmission requests. > > I hope that these ramblings have been of some value. I would be glad to > deepen this conversation privately or on the phone. > > By the way, software firewalls do not use any more bandwidth than hardware > firewalls. Under the covers they are exactly the same thing.....CPU > running > some program connected to a couple of NICs. > > Best regards, > > Donald R. Donigan > donigan technology, LLC dba > Desert CODE Works > [EMAIL PROTECTED] > [EMAIL PROTECTED] > > > > -- > No virus found in this outgoing message. > Checked by AVG Anti-Virus. > Version: 7.0.308 / Virus Database: 266.11.8 - Release Date: 5/10/2005 > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Oracle Space Sweepstakes > Want to be the first software developer in space? > Enter now for the Oracle Space Sweepstakes! > http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click > _______________________________________________ > Hardhats-members mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/hardhats-members ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7393&alloc_id=16281&op=click _______________________________________________ Hardhats-members mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/hardhats-members
