DECNET PHASE IV - FLOW CONTROL

[Art Wiens]

NCP> help set line receive

SET LINE Subtopic? receive

SET

LINE

RECEIVE BUFFERS number

Specifies the length of the line's receive queue. Use a
number in the range of 1 to 32. A value in the range of 2
to 4 is adequate for line speeds of less than 56K bits.
Megabit line speeds may require 8 or more buffers depending
on the observed error rate.

Cheers,
Art

[Kevin Raven (UK)]

Thanks for the reply so far.
I have found the various buffers used by DECNET ...! phew ....
Logical Device
Physical device
Line
Exec
Logical link

The main question now is ...how often does OpenVMS tick , to sense that DECNET has data in a buffer to raise a AST to service the data.
Is it every millisecond or less ?
Our application logs , show data being pumped into the OpenVMS server once every millisecond.

We were seeing transaction rates at 680 trans per second, when flow stop/go messages were sent to the pathworks DECNET client.

[Hoff]

>Our application response times are measured in milli seconds.

As you're already well aware, you've some very tight timing requirements here. Alpha ticks over at 1000 tps or faster, but the clocks still chunk forward more slowly. The clocks on various OpenVMS boxes only get updated at roughly ten millisecond intervals.

>Does the Mailbox or Network Driver use an AST that fires on the millisecond boundary ?

As a rule, ASTs do not fire on boundaries by intention, they fire on an event. Depending on the priority involved, you can get your activity chunked behind somebody else. (And I don't know off-hand if DECnet honors priority here; I'd not assume it.)

I doubt that any of the timing boundaries here would be documented (and AFAIK, none are) and this whole area could thus be subject to change, which means you can go measure it and then choose to depend on the observed behavior at your own discretion. Changes probably would not be intentional, but I could easily see OpenVMS going off into Deep Thought over (say) a memory error, or DECnet getting distracted by routing topology changes.

DECnet would not be my choice for millisecond response time requirements, given how the protocol tends to respond to congestion and to transient errors, and particularly around how it back-pressures traffic.

IP and networking in general can inject considerations here, too. I'd not automatically expect a switch's spanning tree to run in a millisecond, for instance.

In practice, I'd probably look to get a controller out closer to or onto the target (whether an Arduino or more expensive) and work to push the timing-critical activities off of OpenVMS, Solaris or other multi-user multi-processing operating system. I'm sure you've thought of this, though, so I'd assume there are constraints that skew against local intelligent control of the task.

But we're getting deep into real-time system design here, and that's not something I design for free.

[Kevin Raven (UK)]

Hoff - Thanks for the answers on this.
I can't go into to much detail on a public forum, on how and what our current system is used for.

I would love to go into detail, but can't :-(

I could always e-mail you off-line if your interested.

Thanks
Kevin

[Hoff]

Well, if you want to share, send it along.

http://labs.hoffmanlabs.com/contact