Meaning of output from scacp

[MarkOfAus]

Dick,
">>See attached sho lan/vci output. I couldn't find any reference to buffers.

The field is "Max xmt size"."

Got it, thanks.


">>Note, that with jumbo frames enabled on ewb AND the switches it was connected to at both ends incapable of jumbo frames, it still became the prefered path during a copy operation even though its priority was lower than ewa. Hence this discussion.

It is hard to tell without being there. But priority wouldn't necessarily override lossiness of a channel when forming an ECS."

So, I am at the point where the hardware seems to be at fault as, apparently, VMS has done its utmost to "tune" the connection.

Regards
Mark

[MarkOfAus]

Is there any way I can diagnose why ewa is not negotiating jumbo frames with the remote server? lancp sho dev ewa/intern shows that the frames are enabled, but doesn't give any clues as to why it isn't using them.

[Richard Stockdale]

>>Why is not ewa negotiating jumbo frames? ewa is connected remotely to the other server via media converters and a fibre connection. Do I need a capable switch in-between? Seems odd if so.

The switch doesn't matter, as far as whether PEDRIVER does size probing. It only matters that PEDRIVER sees the local and remote channels with a max buffer size larger than it is currently using. Then it will try to probe for a larger size since there is a possibility of increasing to a larger packet size.

>>More info.
>>Remote ewa is DEGXA-TB, local ewa is DEGXA-TB.
>>Remote ewa is 5703 LOM, local ewb is DEGXA-TB.

These devices are equivalent, all Broadcom BCM5703 Gigabit.

>>So, I am at the point where the hardware seems to be at fault as, apparently, VMS has done its utmost to "tune" the connection.

It is a bit difficult to trace what has gone on and figure out a solution off the cuff.

I'd suggest getting both sides set up the way they should be with jumbo frames enabled as you want and then go from there.

>>Is there any way I can diagnose why ewa is not negotiating jumbo frames with the remote server? lancp sho dev ewa/intern shows that the frames are enabled, but doesn't give any clues as to why it isn't using them.

LANCP SHOW DEV EWA/INT shows they are enabled. Then verify that PEDRIVER thinks they are enabled with SCACP SHOW LAN and SHOW CH/ALL and SHOW VC/ALL. Then LANCP SHOW DEV/INT would show jumbo transmits and receives. And verify the switch has jumbo frames enabled as well.

Escalating the problem to support might also help.

Regards,

- Dick

[MarkOfAus]

Dick,

"I'd suggest getting both sides set up the way they should be with jumbo frames enabled as you want and then go from there."

Ah, this was the key point. I had been concentrating on the machine that was shut down and moved, stopping and starting the lan on it via scacp.

Once I went to the other machine and stopped its ewa and restarted, it immediately picked up the new buffer size of 8120 and began sending/receiving jumbo packets.

Regards,
Mark.

[MarkOfAus]

The buffer size correlates to the frame size of the packets on the connection. 8120 indicates jumbo frames.

Jumbo frames only get enabled when both sides of the connection agree and the way to achieve this, if they get "confused", is to use scacp to stop and start that lan device after you have enabled jumbo packets via lancp or lan_flags.

Everyone gets 10 points because you are all very helpful and all answers lead to the correct solution.

Once again, thank you all for your time and efforts: Volker, Wim, Bob and Dick! You're champions.

Regards
Mark