Have you experienced AutoSys Problems in WAN

[Q4you]

Guys,

We recently relocated a system which is a AutoSys Client. Now it is seprated from a Autosys Server by a WAN ( OC-3, which has negligible delay). We are expericing dreadfully slow performace on "jobscape" GUI to load the Data from Autosys Server. Any pointer would be of great help.

Before the move, the AutoSys Client and the server were part of the same subnet, did not have any problems. Nothing changed except for IP parameters. All other applications ( DB etc) are running as before.

Many thanks,

Q-4-U

[Bill Hassell]

"negligible delay" --I would check this with ping. On your local subnet, two machines pinging each other (assuming 100Mbit connected to a network switch) should show a single digit response time. OC-3 is very fast but as with all WANs, the turnaround time from transmit to receive can be 100's of ms and that is a BIG problem with some programs.

If you see 100's of ms delays, then I will guess that your GUI application was written using Java libraries, some of the worst code in the world for generating massive storms of tiny inquiries. Things like: do you have dark blue? Yes, I have dark blue. Can you display 8 bit color depth? Yes, I can display 8 bit... and so on--by the millions. These messages respond almost instantly on a switched network but each reply is delayed by 100's of ms over a WAN.

I first saw this with Lotus Notes for HP-UX. Transferring data using ftp ran a full speed (T3 link) but the GUI took 6 minutes to display (a 28k modem was faster). By analyzing the traffic, we found that there were 10's of thousands of tiny packets just to display the GUI.

Resizing an Xwindow GUI, especially written with Java code, will demonstrate the awful behavior. Rather than simply making the window bigger, the code writes a slightly large window, then a bit larger and so on, sort of like a guessing game.

Another application that is awful using a WAN is the VxVM (Veritas Volume Manager).

There is no fix at the OS level. If you can get your OC-3 line to reply in 1-3 ms, then it should be OK. Otherwise, you'll need to ask Autosys to rewrite their GUI handler to eliminate the inefficient network traffic.

[Ron Kinner]

Check your ethernet connection on the client. Perhaps it did not set up right and you have a duplex mismatch. Look at lanadmin for errors and lock both the switch and the NIC to the same speed and duplex.

Is your OC3 error free? If it's a new connection perhaps they didn't get the timing right and you have a lot of slips?

Ron

[Q4you]

Both of you are right on !

Before the move,( when they were in the subnet) ping delay was in order of 0 to 1 ms between server/client. Now (after the move) it shows around 8 to 9 ms delay over the wan. OC-3 is 15% loaded. There are some extra 5 to 6 hops involved now.

Client/Server both set to 100FD and Switch port is 100FD fix. No alignment errors, ftp transfers are awsome between both the servers over WAN ( 8 to 9MB/s over WAN)

Mostly the way AutoSys/Jobscape code (Java)is written is the suspect.

Now assuming that the application code could be the problem, is there any thing I can tune at the OS level to improve ( nbuf or tcp settings) the large numbers of smaller chunks of data transfers over WAN ?

Just before I give up on this one :)

Note : Client is 24 CPU, 24GB VClass and Server is K570, 4 CPU, 4GB mem. No CPU/IO/Mem bottlenacks seen in glance/Perfview...however network packet rate shoots up like crazy when the "jobscape" is started


Thanks !

[Bill Hassell]

Nothing will help in the OS. The application is telling the CPU to send a short packet and then waits for a response. This query/reply pair stalls the program until the reply is finished. There's no way to get the program's requests batched together as the program won't know what to do. Other than a rewrite of the program, you'll have to live with it.