The VPN/WAN is via TCP I believe. I don't know how to monitor the window size, and I don't think I can alter it anyway.
Kevin --- Gregory Woodhouse <[EMAIL PROTECTED]> wrote: > Do you run the VPN over TCP or UDP? I know that TCP > based RPC protocols > (like the one used by the Broker) are still > problematic over a WAN, > but this would at least take window size at the VPN > level out of the > equation. You can also monitor window size using a > tool like tcpdump. > > ==== > Gregory Woodhouse > [EMAIL PROTECTED] > On May 11, 2005, at 9:23 PM, Cable One wrote: > > > 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 > > Hardhats-members@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/hardhats-members > === message truncated === __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail ------------------------------------------------------- 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 Hardhats-members@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hardhats-members
