General discussion

  • Creator
  • #2297920

    slow network performance


    by inovermyhead ·

    Based on a speed test with a user:

    From user’s PC at one of our remote plants (one mile away from our Network Server ? IBM NAS 100). There is one (1) 10/100 switch between the user’s PC and the Cisco PIX VPN which is connected to the ADSL modem. Our corporate data center, where the netowrk server resides, has a full T-1 frame relay dedicated internet connection.

    737 kb Excel file took 25 seconds to open from I drive on Network Server
    737 kb Excel file took 62 seconds to save to I drive on Network Server

    737 kb Excel file took 37 seconds to copy from PC hard drive to I drive using Windows Explorer

    This user’s results are typical of all remote users, regardless of which remote plant the user is working from.

    Why does it take longer saving from within the application, than copying and pasting within Windows Explorer? And, how much of a difference should there be?

    The file size in question is 737 kb = .737 MegaBytes

    DSL downloads at .15 MegaBytes per second (1.2 megabits divided by 8)

    Therefore, if my math is right the file should move from one location in about 5 seconds plus overhead. Why then, does it take 37 seconds to copy, and 62 seconds to save?

    DSL claims to have DOWNSTREAM speed of approx 1.5 megabits per second. We normally get about 1.2 to 1.3 which is satisfactory. DSL claims to have UPSTREAM speed of 256 kilobits per second. When we are saving files from a remote location to our server via DSL / VPN, are we going downstream or upstream?

    How much can the VPN (Cisco PIX 501) slow down the process?

All Comments

  • Author
    • #2673459

      Tracert and Capture

      by bmn ·

      In reply to slow network performance

      Try running a extended or enhanced traceroute command and lookk for problems in the route. Also, get a sniffer app and run a trace on your example situaltion, prefereably during a quiet period on the network. Examine the captured packets for any indication of application/network client or protocol problems.

      This is all assuming that the local network works fine and that the problem only occures over the WAN.

      If you have multiple network clients and protocols on the end users machine that could be a source of frustration, it could also be that there is an inneficient routing issue with your provider or that the overhead of going from LAN, through VPN or FIREWALL, across the Internet, on to another providers semi-private network, through another firewall,framed and accross a DS1, etc etc…you get my drift. look at the overall latency, if simple packets are making the transit no prob, then it could be a client/server issue.

      Good luck with that! Cheers

    • #2671699

      Couple of Issues

      by oldefar ·

      In reply to slow network performance

      First off, check your math. Circuits are normally defined in bits, not bytes (little b) so your DSL is likely to operating at 1.5 Mbps towards the site (downstream) and and 256 Kbps towards the ISP (upstream). The byte rate is found by dividing these by 8, so traffic to the site is 187.5 kilobytes per second (KBps) and traffic from the site is 32 KBps. At corporate HQ, your T1 operates at 1.544 Mbps inbound and outbound for a rate of 193 KBps.

      Now keep in mind that these are raw transfer rates. So what would be the fastest 737 KB of data could move from the remote to corporate? I would say 23 seconds – limited by the small communications pipe segment of the ADSL circuit. Now from corporate to remote, the fastest time to move that much data is 3.9 seconds, again with the smallest segment being the ADSL circuit.

      Now we get into additional factors. First is the packet overhead which is 32 bytes per packet. How big are the packets? This is a function of the application and the protocol stacks on each node. The smaller the packet, the more overhead. Also, the protocol settings determine additional delay in transmitting packets. The flow of data may depend on the acknowledgements from the destination.

      On the communications side, the additional factors are bit latency – a factor of distance and physics, background traffic, and processing latency. It is this third aspect that comes into play with firewalls and VPN.
      So the reason it takes longer saving the file rather than opening the file is primarily the asymetrical bandwidth on the remote site.

      The actual distribution of total time is impacted by communications bandwidth, latency and load; client settings; server settings; and VPN.

      • #2671594

        application and protocol stacks

        by inovermyhead ·

        In reply to Couple of Issues

        Thank you, Ken, for your response. You confirmed my suspicions about the asymetrical bandwidth issues. Since it takes our user only 37 seconds to copy (using Windows cut and paste)the file from hard drive to network drive, and it takes the same users 62 seconds to save (using Excel save function) the same file to the same network drive, I suspect that the problem lies within the application somewhere.

        Can you geive me some specifics on what to look for in the application. ie. Can I change packet size or change anything about the protocol stacks, and how?

        Thank you.

        • #2670841

          First things first

          by oldefar ·

          In reply to application and protocol stacks

          Personally, I would not begin tweeking until I had a trace file of the traffic so I would know how the application is behaving from a communications perspective.

          For example, a copy and paste is moving cell data, while a file save is including all the application related file overhead. This alone could be significant. Save a blank 3 sheet Exel file and look at its size to get an idea. Using Excel 2000 the file is 13,824 bytes after giving it a name and doing a save!

          If the packet capture shows small packets, there are some basic tips for tweeking the stack for Windows at As with any registry changes, you want to be very cautious and keep a record of the original settings as a part of a backout plan. If you are using a Linux OS, try for tips on adjusting the stack.

          I haven’t found any references for MS Excel specific changes in the packet structure, so I am guessing all changes are made in the Windows registry.

Viewing 1 reply thread