|
|
| GeoCommunity Mailing List |
| |
| Mailing List Archives |
| Subject: | RE: [gislist] GIS and computer configurations |
| Date: |
10/13/2004 02:35:01 PM |
| From: |
Quantitative Decisions |
|
|
At 08:57 PM 10/13/2004 +0200, Luis Gon=E7alves Seco wrote:
>Depending of your network traffic if you have a 100 Megabits network
>connexion that means you can transfer, more and less 12.5 Mbytes (data) per
>second. So I think it's enough for the size of your images.
That's the right calculation, and correctly performed, too, but to get a=20
more realistic result, one has to accommodate differences between nominal=20
values and actual values. A 100 Megabit/sec network requires not 8, but=20
about 9.5, bits to transmit one byte (there are check bits and some=20
overhead involved). The actual rate of this network will top out at half=20
its nominal rate, but typical speeds are more like 20 megabits per second=20
(even for an unloaded network). If you are running through a hub rather=20
than a switch, this bandwidth must be shared by all traffic passing through=
=20
the hub, further decreasing the network's capabilities for fast=
transmission.
Accounting for these realities indicates the actual data throughput on the=
=20
network is unlikely to exceed 5 MB/sec, requiring four seconds at least=20
(and more like 10 seconds) to transfer just one 20 MB image.
For whatever reason, ArcView also tends to perform slowly--more slowly than=
=20
these kinds of calculations usually suggest--when accessing data over=
networks.
My basis for these statements consists of having monitored system and=20
network usage and performed formal timing studies on AV 3.1, 3.2, and 3.3=20
on machines running Win NT, 98, 2000, and XP using Intel and AMD=20
architectures with chip speeds ranging from 200 MHz through 2.4 GHz on a=20
100 Mb/sec network.
In response to the original query, consider maintaining local copies of=20
large geographic datasets (such as your images). That might not completely=
=20
solve the problem of poor performance--there can be plenty of other=20
causes--but it can help.
A good thing to do is systematically test potential bottlenecks. For=20
instance, if you think the problem is image transmission time, then view=20
some of the same images using different software to compare the times (and=
=20
monitor the network and the CPU while doing so). The bottleneck could be=20
in the network configuration, the OS settings, or elsewhere: it might not=20
be caused by ArcView at all.
--Bill Huber
Quantitative Decisions
_______________________________________________
gislist mailing list
gislist@lists.geocomm.com
http://lists.geocomm.com/mailman/listinfo/gislist
_________________________________
This list is brought to you by
The GeoCommunity
http://www.geocomm.com/
Get Access to the latest GIS & Geospatial Industry RFPs and bids
http://www.geobids.com
|
|
Sponsored by:
For information
regarding
advertising rates
Click Here!
|
