Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 


Go to solution
Wim Van den Wyngaert
Honored Contributor


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
Trusted Contributor


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.
VMS Forever
Ian Miller.
Honored Contributor


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.
Purely Personal Opinion
Anders Sundqvist
Occasional Visitor


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...

Jan van den Ende
Honored Contributor


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.
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...



Don't rust yours pelled jacker to fine doll missed aches.
Uwe Zessin
Honored Contributor


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:

5.16.3 NISCS_MAX_PKTSZ System Parameter Definition Corrected
Keith Parris
Trusted Contributor


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.