How to set buffer on VAX 7.2 without LANCP

[Lachnitt_1]

Hi folks,

I want to set MIN and MAX_buffers on a Ethernet NIC on a Vax with VMS 7.2.
But seeting this with LANCP is only implemented (though displayed in Help) on Alpha and/or VMS 7.3, but upgrading is not an option!

Any ideas?

Thx & ciao, Kuddel

[Ian Miller.]

have a look at the I/O users manual chapter on the ethernet driver QIO interface in particular IO$_SETCHAR

[Lachnitt_1]

Thx Ian,

but how can a Not-Programmer uses this???

Kuddel

[Hein van den Heuvel]

>> but how can a Not-Programmer uses this???

By using the Not-Compiler ?


Seriously though....

- What makes you think there is a problem with the settings on your system? If it is bad enough, it make become a reason to upgrade. Or at least an other argument to the list.

1) Grab a Lancp image from a 7.3(-2) system, cross fingers, and try. It might just work, or it might not even start to run. It it very unlikely to crash your system, but I'd try at a 'slow' time.

2) Look around at the various free-ware / sig-tape depots for tools

3) By a friendly C/Macro/Fortran a beer and hope for the best?

Good luck!
Hein.

[Hoff]

I might ask why you want to do this. VAX systems tend to run 10 megabit network controllers, and these are, well, slow.

Per the V7.1 manuals, /MIN_BUFFERS and /MAX_BUFFERS are listed, and not listed as being restricted to Alpha. If it doesn't work, dig around for an ECO kit and see if that helps.

As for your case and your request, there are various options available for a non-programmer, including asking any of the various consultants here, by finding existing code that calls this $qio, by asking a programmer to code this $qio for you, or by upgrading. Or you could use this opportunity to learn how to toss $qio calls yourself. Which is the best approach depends on your budget and your inclinations and competing requirements.

Tuning VAX network performance as compared with that of more modern systems and more modern NICs is not going to provide what is now expected of network throughput. VAX boxes are old and slow, and no amount of tuning is going to help that. You might look to emulation, or to DECmigrate/VEST/AEST, or toward rebuilding your code on an Alpha or Itanium box.

(While upgrading is not an option, upgrading, replacement or retirement of any existing computer box is inevitable. Things hardware last forever not.)

Stephen Hoffman
HoffmanLabs LLC

[Robert Gezelter]

Kuddel,

I will agree with Hein, you may very well discover that LANCP from 7.3 works. Certainly it is worth a small amount of investigation. As has been mentioned, do this experiment at a safe time.

The MACRO code (every system has MACRO) is not particularly a heavy use of MACRO, it is almost a verbatim copy out of the examples in the IO Manual. Certainly a one-shot is not complex.

I do however, agree with Hoff. What is the evidence that there is a buffer shortage on your system. Before going through all of this trouble, it is worthwhile to verify that this indeed will address the problem.

And yes, I am fluent in all of the major languages, this is a straightforward operation in all of them.

- Bob Gezelter, http://www.rlgsc.com

[Lachnitt_1]

@Hein: On Vax 7.3 it is also not implemented (tried with one)!

Thx @ All so far!

[Graham Burley]

LANCP HELP SET DEVICE_Parameters on VAX and Alpha says "On Alpha systems, sets or modifies LAN device parameters."

I can't see anything in the I/O Users to indicate any control over the number of receive buffers other than at the port level.

[Lachnitt_1]

@All

Our need to adjust the NIC is cause we are receiving per hour between 5 and 30 Unavail station buffs on the NIC!

Kuddel

[Lachnitt_1]

....

we had the same on our AXPs in that cluster, and after increasing the buffers the errors went away!

Kuddel

[Wim Van den Wyngaert]

The info is stored in sys$system:lan$device_database.dat.

Generate an fdl, adjust the db using eve (compare with a alpha node what changed when doing the define dev /min command), convert the file back to indexed.

Could work.

Wim-without-vax

[Graham Burley]

Presumably, since LANCP on VAX can't SHOW or SET these parameters, the VAX LAN driver was never updated to support them. There's also no sign of them on VAX 7.3 in SDA> SHOW LAN/FULL.

There are a couple of old comp.os.vms posts re "System buffer unavailable" (which is how DECnet NCP reports them) which imply that the number of station/system buffers were either hard-coded at 16 or a function of the number of protocols in use. On the VAX I have access to SDA "Rcv buffers owned by device" is 16.

Increasing the number of *user* receive buffers (in NCP/NCL or ... depending on the protocols in use) *might* help.

[Jur van der Burg]

system buffers on VAX are hardcoded. You can't change them.

Jur.

[Volker Halle]

Kuddel,

instead of trying to address the symptom, try to analyse and - maybe solve - the problem.

There may be short multicast/broadcast 'storms' on your network and the slow VAX LAN interfaces will just suffer more than the Alpha systems.

It's unlikely, that the unavailable system buffer events happen due to directed traffic, it's more likely due to multicast traffic.

Collect the relevant counters (packets received, multicast packets received, unavailable system buffers) every couple of minutes and write them into some T4-style file. Then look at the data with TLviz. If there is some pattern, you'll see it immediately. Compare the VAX with the Alpha data and if my theory is correct, you'll see a common pattern over time.

Then look at the multicast data per protocol (SDA> SHOW LAN/FULL) and it should become obvious, which protocol is contributing most to that traffic.

Then use appropriate tracing tools to find the actucal traffic.

I've seen network switches sending ARP-who-is broadcasts to every IP address on the segment in millisecond increments every couple of hours.

Volker.