speed difference alpha<->hp

[Michael Schulte zur Sur]

Hi,

we currently have a strange phenomenum, where we have user in Switzerland connecting by wan to machines in Germany. When they connect to an Alphaserver, they have slow response(typing,login prompt), when they connect to an HP machine, it is fast. So, you might say, the Alpha is slow. When they connect to the HP and then telnet to the Alpha, it is fast too. !?!?!?
Both machines are in the same house.

Any idea?

Michael

[Johan Brusche]

What is the type of WAN-connection, X25 or ADSL VPN or .....async modem or....?
Different routers, gateways (traceroute) ?

Johan.

[Tan Hean Seng]

My suggestion:

Check the output of network parameters in your Alphaserver with this command (assuming it is running Tru64 Unix or Digital Unix):
/sbin/sysconfig -q inet

Adjust/specify the values (in /etc/sysconfigtab) to the corresponding values in your HP machine.

[Ravi_8]

Hi Michael

could u check n/w card in alpha server is configured as 10MBps instead of 100MBps, if so change the speed(netconfig) aslo look for default gateway you are using on alpha servers

[Michael Schulte zur Sur]

Johan,
it's all dedicated lines.

Tan,
when you take the detour via HP to Alpha, it is faster.

Ravi,
fastfd hardwired, wan route same.

thanks,

Michael

[Ralf Puchner]

it sound like a typical problem of path discovery. Btw. ftp is not a performance messurement tool.

[Mobeen_1]

Michael,
I know all the folks here have mentioned assuming that your Alpha is running on Tru64. Just in case your Alphas are running OpenVMS the quivalent tasks are

1. $ MONITOR NETWORK

2. SHOW NET/FULL

regards
Mobeen

[Johan Brusche]

It would have helped if you had answered eg:
a dedicated V24 async modem to a serial port on the AlphaServer or on a terminal server.

If on a serial line, does the getty initialise the line at the proper speed, is the modem syncronizing at that same speed, or is there a speed mismatch that forces the modem to use internal buffering ?
Was another line or modem tried ...etc..etc..

Johan.

[Michael Schulte zur Sur]

Ralf,

can you explain, what you mean by path discovery? The problem may have to do, that many go through an openvms machine before they go to Germany.

thanks,

Michael

[Ralf Puchner]

Michael,

type in "path discovery" in google and you will get an explanation. This mechanism sets the "don't fragment bit" which is very very ugly in case of different speeds and routers between the networks.

Disable the path discovery (search this forum) and check again, in case of vpn tunnels decrease the packet size to <= 1400 it will increase the network speed dramatically (inet: parameter section).

[Michael Schulte zur Sur]

Johan,
I thought, I made it clear. ;-) Dedicated lines means wan and ip, so no async modem.

Mobeen,
it is in the correct forum. ;-)

Ralf,
thanks for training my research capabilities. ;-) No vpn however, just straight foreward.

thanks,

Michael

[Hein van den Heuvel]

Just for sake of completeness... this topic is also being discussed from the other angle in the hp-ux forum under:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=469608

Hein

[Michael Schulte zur Sur]

Hein,

you have posted a wrong link. ;-)

Michael

[Hein van den Heuvel]

Arghh! And here I was wondering why the threadid's were so far apart, speculating that the forum number played a role in the threadid. I was overthinking... it was just me making a cut/paste&correct fat-finger action.


http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=479608

(Can you do -1 points? If not I'll take 0 :-)

Hein.

[Johan Brusche]

We can continue forever like that guessing what the network topology might be between the Swisse and German site, and what there is between the end of the direct(leased)line and the 2 destination systems. Knowing that would avoid cluttering this thread with random assumptions.

Johan.

[Ralf Puchner]

any news after switching off path discovery?

For your learning experiences:
depending on the type of network and physical connections, routers etc different tcp/ip stacks will use different methods and packet sizes leading to different performance impacts and communication behaviours. Tru64 do have one of the best TCP/IP stacks with most of the RFC implementations in the industry.

Customers have done some network testings with Sun and Tru64 seems to be 4-8 times faster. A general setup out of the box is optimized for LOCAL network traffic not for wan or subnets.

So an analytical process is to configure Tru64 for your needs and if this doesn't solve your problem to use tools to get a clue what the root cause is. Slow responses may depend on wrong high-water marks, slow packet transfers or packet loss.

If you prefer "frickling" or "guesses" let us know ;-)

[Michael Schulte zur Sur]

Hi everyone,

thanks for your participation and patience so far. I am working in a big company and to get info from another department, especially foreign can be quite tedious.

Here the topology as much as I understand it. We use mpls between our sites and here we use Cisco switches and routers.

One thing we discovered this morning was that the Alpha has gone into store_and_foreward mode and this variable had the value 0 even though set in /etc/sysconfigtab to zero.

I am still waiting for the telnet try result to come to me, so please bear with me. ;-)

thanks again,

Michael

[Michael Schulte zur Sur]

Hi everyone,

thanks for your thoughts, but this problem will not be solved so quickly, if at all, due to missing cooperation from within our company. :-(

Michael