NISC_MAX_PKTSZ

[Wim Van den Wyngaert]

I have a cluster that is doing its cluster communications via FDDI. Therefore we limit the size of NISC_MAX_PKTSZ to 4468.
Autogen calculated a value of 8192.
Anyone any idea why autogen does that ?

[Åge Rønning]

This parameter is maximum size and PEDRIVER will automaticly adjust the size actually used.
From SYSGEN HELP: On Alpha, to optimize performance, the default value is the largest packet size currently supported by OpenVMS.

My advice is to use the default value and let PEDRIVER handle the different sizes for the different adapters and LANs.

[Ian Miller.]

I've got a cluster with ethernet and FDDI. NISC_MAX_PKTSZ is the max that can be used but PEDRIVER works would the max size for each link. AUTOGEN needs to pick a size at least as big as the max possible.

[Anders Sundqvist]

it does that in all versions after 7.3 (or so)
if you want an explanation, look in the 7.3 release notes (see http://h71000.www7.hp.com/DOC/73final/6637/6637pro_007.html )

there are also some caveats when you have mixed versions and satellites booting over fddi...

-anders

[Jan van den Ende · Accepted solution]

Hello Wim,

maybe things have changed since, but when we introduced FDDI (AXP VMS 6.2(-?), the party line was that to efficiently use FDDI you had to SPECIFICALLY specify the famous 4468.
Explanation:
the initial handshake trial is at NISCS_MAX_PKTSZ. If that fails, the next try is at 1498 (IMMSMW, at least something like that), being the 10MB ethernet "large" packet size. (and if that doesn't shake, go progressively less...).
Now , FDDI supports up to 4468.
So, try 8192, no shake, & land at LPSIZE (~1500) :=> two-thirds of your packet is unused :=> you need 3 times as many packets.

I never heard or read that for any 7.x it changed, but... ;-)

I don't suppose AUTOGEN checks whether you use FDDI...

fwiiw,

Jan

[Uwe Zessin]

Looks like it is to buffer Gigabit Ethernet and ATM traffic (I didn't find in on the first try, because the name is slightly wrong - it is NISC*S*_MAX_PKTSZ).

There is a table in that paragraph:
http://h71000.www7.hp.com/DOC/73final/6637/6637pro_007.html

5.16.3 NISCS_MAX_PKTSZ System Parameter Definition Corrected

[Keith Parris]

ATM is supported as a cluster interconnect, and ATM presently supports packet payload sizes up to the value of 9180 that is the maximum value for NISCS_MAX_PKTSZ under SYSGEN.

Actual maximum packet sizes supported by various Gigabit Ethernet hardware products vary from 2K to 16K bytes -- there is no single standard. (For example, details for various Cisco Catalyst models may be found at http://www.cisco.com/warp/public/473/148.html). And experts feel the CRC protection provided becomes insufficient in theory at about 10K bytes in packet size, so something on the order of 9K bytes is likely to become most common in practice, I'd guess.

At 7.3 and above, PEDRIVER probes for the actual maximum packet size which gets through a given path at a given point in time, so the only "hurt" involved in specifying a larger-than-necessary value for NISCS_MAX_PKTSZ is that there will be a bit of wasted memory as all packet buffers for PEDRIVER will be allocated at the larger size.

I've submitted a Problem Tracking Report to get the SYSGEN help and the documentation updated and corrected.