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
