FTP Slow From Alpha to External Sites

[Robert Atkinson]

8MB text file breaks ITRC 1MB limits!

[Robert Atkinson]

U:\>tracert dropbox-mun.emea.compaq.com

Tracing route to dropbox-mun.emea.compaq.com [161.114.112.193]
over a maximum of 30 hops:

1 <10 ms <10 ms <10 ms 10.110.16.1
2 <10 ms <10 ms <10 ms 10.110.16.255
3 1 ms 1 ms 1 ms randhous02-gw-lan.pipex.net [62.190.210.62]
4 * * * Request timed out.
5 * * * Request timed out.
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 * * * Request timed out.


ALPHA_ROB$$$ tracerou dropbox-mun.emea.compaq.com
traceroute to dropbox-mun.emea.compaq.com (161.114.112.193): 1-30 hops, 38 byte packets
1 10.110.16.1 (10.110.16.1) 0.977 ms 0.976 ms 0.0 ms
2 * * *
3 * * *
4 * * *
5 * * *


Our firewall doesn't allow our Alpha to TRACEROUTE past it, but I'll see if I can alter this.

Not sure why I'm getting time-outs after the 3rd hop from the PC?

Rob.

[Wim Van den Wyngaert]

I guess that the nodes don't react on your requests or may be the firewall is blocking them. Did you notice the difference in timing to reach the first node ?

Could you post the first MB of the trace ?

Wim

[Robert Atkinson]

Full Alpha traceroute :-

ALPHA_ROB$$$ tracerou dropbox-mun.emea.compaq.com
traceroute to dropbox-mun.emea.compaq.com (161.114.112.193): 1-30 hops, 38 byte packets
1 10.110.16.1 (10.110.16.1) 0.0 ms 0.976 ms 0.977 ms
2 10.110.16.255 (10.110.16.255) 0.976 ms (ttl=128!) 0.977 ms (ttl=128!) 0.976 ms (ttl=128!)
3 randhous02-gw-lan.pipex.net (62.190.210.62) 0.977 ms (ttl=254!) 1.95 ms (ttl=254!) 0.976 ms (ttl=254!)
4 * * *

[Petr Spisek]

What does it mean the second hop? Is it a broadcast?
Petr

[Robert Atkinson]

I don't understand what you're asking.

Hops are literally 'hops' from one server to the next until the packet gets to it's final destination.

Rob.

[Petr Spisek]

1st hop to 10.110.16.1 - it's your default gateway (or router defined in route configuration).
2nd hop to 10.110.16.255 - what is it? I's range for all IPs in 10.110.16.x ... I'm not tcpip expert, but it looks quaintly.

Petr

[Robert Atkinson]

The server at 16.255 is W2K running Firewall-1. It's the last hop before our ISP.

Rob.

[Petr Spisek]

Hm so, routes looks well.

Next tips:
Try to check port setting on all ports to the Firewall.
Analyze system performance during the transfer (specially cpu interrupts and disk throughput).
Check the firewall saturation during the transfer.
Petr

[Robert Atkinson]

Remember, PC to remote server is OK, so looking for the problem in the firewall load is not going to help.

[Petr Spisek]

Rob, I discussed your firewall's IP with network admin - 10.110.16.255 is really bradcast. Check correct fireawall IP address (commonly x.x.x.254).
Petr

[Robert Atkinson]

Broadcast it may be but there still appears to be a server at 255 :-

ALPHA_ROB$$ ping 10.110.16.255
PING 10.110.16.255 (10.110.16.255): 56 data bytes
64 bytes from 10.110.16.255: icmp_seq=0 ttl=128 time=1 ms
64 bytes from 10.110.16.255: icmp_seq=1 ttl=128 time=0 ms
64 bytes from 10.110.16.255: icmp_seq=2 ttl=128 time=0 ms

[Petr Spisek]

... and it could be the problem, ping to x.x.x.255 to do the spray-ping to all subnet (in right configuration). I think it's not good idea set some server to x.x.x.255

Petr

[Wim Van den Wyngaert]

Petr,

Just as 0 in an IP address, 255 is also allowed. It is the network mask that decides which bits are the node part and it may be eny combination of 0 and 1.

Wim

[Petr Spisek]

Thanks for to correction :-)
And how works the broadcast in this subnet?
Petr

[Wim Van den Wyngaert]

Petr,

http://www.thinkingsecure.com/docs/TCPIP-Illustrated-1/introduc.htm#1_4
(range of each class)

I don't know in detail how the broadcast is done but maybe the mask is here 255.255.0.0 and then the last part may be 255 without any problem.

Wim

[Richard Brodie_1]

10.x.y.z is the private (RFC 1918) class A network; if it were a flat network 10.255.255.255 would be the broadcast address.
Even if the subnet mask were byte aligned, 255.255.0.0, as Wim says, would be more likely than 255.255.255.0.

As to the original problem: I'm not a great expert but I would guess that the TCP part of the stack is probably the key factor. There did seem to be an awful lot of retransmits, so maybe a more aggressive retry algorithm might win big. TCP retransmit tuning is a black art to me: see RFC 4015 or Google TBIT and blow your mind.

[Robert Atkinson]

Thanks for everyones help.

I'm not convinced I know a whole lot more about TCP/IP and the HP stack, but we do at least know what the problem is.

My timing tests were based on Mega-Bits per second for the PC and Mega-Bytes per second for the Alpha's, so the PC looked a lot faster.

Having talked this through with our Network Manager, we now know we have a physical cap on the bandwidth availble to external FTP, hence the fairly rubbish transfer rates.

Rob.