At 10:20 24/01/02 +0000, you wrote: >Date: Thu, 24 Jan 2002 13:00:28 +0000 >From: [EMAIL PROTECTED] >Subject: Re: MTU > >Chris, >can you clarify your reply please.
No problem. Bear in mind that this may not be the cause of your problems..... >On 24/01/2002 11:35:20 Chris Jaecker wrote: > > > To test for this try sending out pings with 1500 mtu and df set (client > to server or vice versa). >...so that would be > ping -l 1500 -f remote_host > - correct ? Yes. You need to sweep a range of sizes to see what MTU works. Try 1400, 1420, 1450 etc. I'd also send a lot of pings in the test, by using the -t option (which means the ping goes till you press CNTRL-C) as the intervening devices may benevolently ignore the df bit, and also to simulate the congestion overhead. > >If it is the problem, try this: > > > > The solution was to reduce the MTU of the VNC host. This can be done in > the registry permanently with: > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\<adapter>\Tcpip\Param > eters\MTU > > > > which should be set to 1400 > >[Under NT4 system] I couldn't find any Tcpip\Parameter names under >Services and couldn't really match <adapter> to my actual adapter >can you advise how to create an appropriate "<adapter>" name please. You don't create the adaptor name, it's created as part of the NIC install process. On my Compaq ML370 running ipconfig in a DOS window revealed I had the Ethernet adaptor N1001, and in the Registry, it was there as HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\N1001 I had to create the Tcpip parameters myself. Actually I prefer the option below, because it worked better. > > The NT server can also be forced to discover the MTU of a path by setting: > > > > > HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\Enab > lePMTUBHDetect > > >On my system, this did not exist, so presumably requires creation. Yes, you need to create it. >a) what is the behaviour when entry does not exist? The system will default to 1500 MTU >b) can you confirm that "discover" means "discover and use" Yes. It means that the connection begins a little more slowly as the server will actually check for the path MTU by setting DF and waiting for "should have fragmented, but couldn't" messages from intervening routers. Even if the router doesn't send the "Could not Fragment" message (as it may well do because it is in "black hole" mode), the NT box will wait for the acknowledgement of the packet and if it is not received it will drop the MTU and try again until it gets an ack and therefore knows the "true" MTU of the path. >c) As a normal "end-user", when would you NOT want "discover and use" ? > I assume it is useful when investigating performance and setting up a > network. It does slow down session connect time, so you wouldn't use it if the path between hosts was homogenous and transparent. For me, because all connections are through VPN, it's compulsory. I suppose I could force the MTU and avoid the session negotiation overhead, but I wasn't too happy setting up the interface registry either, and in any event, any local connections under the detection scheme will go at 1500. I hope this is helpful. I'm really a router guy, and strictly empirical with MS. Best wishes Chris --------------------------------------------------------------------- To unsubscribe, mail [EMAIL PROTECTED] with the line: 'unsubscribe vnc-list' in the message BODY See also: http://www.uk.research.att.com/vnc/intouch.html ---------------------------------------------------------------------
