Long delays accessing the printers at the VPN server

[lreyes]

Is it normal to have loooong delays accessing the shared printers of the server side from a remote client? It takes up to two minutes just to display them when printing from any application. The server (a 100Mhz Win98 machine) has a 512Kbps cable modem conection and the client (1.4Ghz WinXP) is either on a 56K modem or on the LAN at college (dual T1), but it makes no difference, the delay is roughly the same. Other operations don´t take nearly as long, displaying folders is quite fast and transferring files is not so bad. Is my slow server the culprit?

Thanks in advance

[Pascal]

Is it that slow when you first connect to the VPN and on any subsequent attempt to connect to the printer ? Or is it only on the first attempt ?

[lreyes]

It happens every time I attempt to connect to any of the two shared printers at the server, whether I have just joined the VPN or I've been there for a while.

Regards!

[adrien]

I think that this is something we all have to thank MicroSoft for.

If you look at the flashing lights on your modem or network adapter, you should see that your machine is actually doing quite a lot of work connecting to the printers.

This is due to the layered design that MS networking is based upon, basically DCOM over RPC over SMB over NBT over TCP or UDP over IP over ethernet. The number of layers (each one of which adds a wrapper to the packet, and reduces the available payload capacity) is quite large, and the protocols layered even above this still means that there are a lot of packets going back and forth.

For instance did you know when you browse a directory in explorer, it opens every file, and reads a small bit out of it in order to get the correct icon to display? This is fine normally over a fast local network, but over a slower link, such as a dialup, it can cause problems.

The other issue is packet latency. If packets take a long time to go back and forth, even though they are small, then things take a long time to happen, since each packet has to get there and back before the next packet is sent. This packet latency can have a bigger effect than even available bandwidth.

The amount of effect that packet latency has is dependent on the protocol being used - if you have a protocol that has a lot of transactions to set something up (lots of there and backs before anything happens), then latency will have a marked effect on it. Other protocols which have few transactions will be a lot quicker, since it gets down to the business of bulk transfer more quickly. HTTP for instance is designed to be fairly immune to latency, and there have been several advances in TCP to help this as well.

There are some registry tweaks you can do in your TCP/IP settings to improve performance in high-latency systems. You can measure your latency with a ping as well, since that reports the round-trip time. Any time latency gets over about 300ms you are going to start having issues with some protocols.