On Mon, Feb 13, 2012 at 02:50:13AM +0100, Peter Olsson
wrote:> Desktop: FreeBSD 9.0-RELEASE amd64, generic kernel,
> running Openbox. My WAN is about 1.2 Mbps, and I try
> to run RDP to windows servers beyond my WAN.
>
> RDP to a Windows Server 2003 SP2 is fast and works
> without problems.
>
> RDP to a Windows Server 2008 R2 is very slow,
> and sometimes just disconnects.
>
> I tried changing a couple of net.inet.tcp sysctl:
> net.inet.tcp.recvbuf_max=10485760
> net.inet.tcp.recvbuf_inc=65535
> net.inet.tcp.sendbuf_max=10485760
> net.inet.tcp.sendbuf_inc=65535
> net.inet.tcp.recvbuf_auto=0
> net.inet.tcp.sendbuf_auto=0
> net.inet.tcp.sendspace=65536
> net.inet.tcp.ecn.enable=1
> net.inet.tcp.delayed_ack=0
> net.inet.tcp.tso=0
> net.inet.tcp.sack.enable=0
> net.inet.tcp.path_mtu_discovery=0
>
> Some in combination with others, and some by themselves.
>
> I also tried net.link.ifqmaxlen=1024 in /boot/loader.conf.
>
> Nothing has helped, do you have any ideas what I
> should tune?
The above things you've tinkered with have probably done more damage
than good. I strongly recommend you not "flail around" when it comes
to
adjustments like this; just guessing at seemingly random sysctls is a
really bad idea. Please don't do this, for your own sake.
You should probably engage a networking resource within your company or
upstream from you, and provide them packet captures taken from both the
FreeBSD machine as well as the Windows machine.
Also, you specify 9.0 -- does using 8.2 to RDP to the same W2K8 R2
server work/behave fine, and thus the problem started with 9.0?
The only thing I can think of is possibly RFC1323 "quirks" causing
some
kind of problem across a WAN link, or some very bizarre behaviour in the
Ethernet/NIC driver on FreeBSD. You should probably try to reproduce
this problem on a LAN, because I can assure you if you're using RDP
across the Internet, you will have zero (I repeat: ZERO) chance of
figuring this one out without every peering provider getting involved
(both forward path and return path). Remember: the Internet is broken
24x7x365, and dedicated links/circuits are often neglected by providers
regardless of who they are or where they are.
You really didn't give any hard evidence or technical information
besides "I see this problem, what is the cause?" Engaging network
engineers on your side would probably be a good first step.
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, US |
| Making life hard for others since 1977. PGP 4BD6C0CB |