17 Jul
2024
17 Jul
'24
11:25 p.m.
The weird thing about that is that Thomas said he had the following line
in SYSTEM:7-1-CONFIG.CMD:
DECNET BUFFER-SIZE 1476
That does not look like a line specific parameter (which line would that
be for then, by the way?).
Anyway, yes, it do indeed seem that this buffer size is shown on the
lines. Oh well. Probably another mystery that I'll never figure out. :-)
Johnny
On 2024-07-16 15:05, Paul Koning wrote:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Jul 15, 2024, at 10:09 PM, Thomas DeBellis
<tommytimesharing(a)gmail.com> wrote:
Yes, that's the other thing that bothered me, that NML was not reporting what is in
the config file
Apparently it is, as a line parameter -- a TOPS-10/20 OS specific parameter. The
executor parameters are not the same thing, the details of the definition are different
and they serve a different purpose. The trouble is in those details: the executor
parameters are, in effect, the routing data packet payload size (NSDU size) plus six,
while the line parameter is the datalink payload size (DSDU). Since routing data headers
on Ethernet are 21 bytes rather than 6 bytes long, using the same value for both is a
problem.
An additional bit of confusion comes from the fact that I seem to have forgotten to do
adjacency buffer size checking when forwarding packets, so RSTS forwarding to TOPS20 was
correctly complaining but PyDECnet was not. That made it look like RSTS was wrong, when
in fact it is right and PyDECnet is wrong.
paul
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se