On Tue, 10 Jun 2014, Brian Schenkenberger, VAXman- wrote:
$ MCR SYSGEN ;)
Seriously, edit MODPARAMS.DAT, set each of those recommendations as:
min_<SYSGEN-parameter> = <suggested-value>
and then @SYS$UPDATE:AUTOGEN and reboot.
Thanks. I just shoved them in the email so I had somewhere to refer to when I was in EDIT. ;)
Now to boot the cluster node!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
Cory Smelosky <b4 at gewt.net> writes:
On Tue, 10 Jun 2014, Dave McGuire wrote:
On 06/10/2014 02:32 PM, Cory Smelosky wrote:
What's the latest version of VWS/the workstation stuff? I've heard
DECwindows is a bit heavy for a VS2000. ;)
DECwindows is fine on a VS2000, FYI. (been there, done that...for YEARS)
Ahh, Okay!
I need to fix these before I can shove it on the cluster node, though. ;)
%DECW-W-BADVALUE, Free GBLPAGES is 11620, should be at least 30000
%DECW-W-BADVALUE, SYSGEN parameter GBLPAGFIL is 1024, should be at least
6024
%DECW-W-BADVALUE, SYSGEN parameter CHANNELCNT is 127, should be at least
255
%DECW-W-BADVALUE, SYSGEN parameter PQL_DPGFLQUOTA is 16400, should be at
least 32768
%DECW-W-BADVALUE, SYSGEN parameter PQL_MASTLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MBIOLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MDIOLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MPRCLM is 0, should be at least 8
%DECW-W-BADVALUE, SYSGEN parameter PQL_MFILLM is 2, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MBYTLM is 1024, should be at least
48000
%DECW-W-BADVALUE, SYSGEN parameter PQL_MENQLM is 30, should be at least
200
$ MCR SYSGEN ;)
Seriously, edit MODPARAMS.DAT, set each of those recommendations as:
min_<SYSGEN-parameter> = <suggested-value>
and then @SYS$UPDATE:AUTOGEN and reboot.
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
I speak to machines with the voice of humanity.
On Jun 10, 2014, at 2:39 PM, Dave McGuire <mcguire at neurotica.com> wrote:
On 06/10/2014 02:32 PM, Cory Smelosky wrote:
What's the latest version of VWS/the workstation stuff? I've heard
DECwindows is a bit heavy for a VS2000. ;)
DECwindows is fine on a VS2000, FYI. (been there, done that...for YEARS)
-Dave
I ve used both on the same hardware started on a VS2 (the first one with color graphics) running VWS, then switched to DECwindows when VWS was unceremoniously canceled. I m pretty sure that DECwindows was both functionally superior and a whole lot faster.
paul
On Tue, 10 Jun 2014, Dave McGuire wrote:
On 06/10/2014 02:32 PM, Cory Smelosky wrote:
What's the latest version of VWS/the workstation stuff? I've heard
DECwindows is a bit heavy for a VS2000. ;)
DECwindows is fine on a VS2000, FYI. (been there, done that...for YEARS)
Ahh, Okay!
I need to fix these before I can shove it on the cluster node, though. ;)
%DECW-W-BADVALUE, Free GBLPAGES is 11620, should be at least 30000
%DECW-W-BADVALUE, SYSGEN parameter GBLPAGFIL is 1024, should be at least 6024
%DECW-W-BADVALUE, SYSGEN parameter CHANNELCNT is 127, should be at least 255
%DECW-W-BADVALUE, SYSGEN parameter PQL_DPGFLQUOTA is 16400, should be at least 32768
%DECW-W-BADVALUE, SYSGEN parameter PQL_MASTLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MBIOLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MDIOLM is 4, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MPRCLM is 0, should be at least 8
%DECW-W-BADVALUE, SYSGEN parameter PQL_MFILLM is 2, should be at least 100
%DECW-W-BADVALUE, SYSGEN parameter PQL_MBYTLM is 1024, should be at least 48000
%DECW-W-BADVALUE, SYSGEN parameter PQL_MENQLM is 30, should be at least 200
-Dave
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
On 06/10/2014 02:32 PM, Cory Smelosky wrote:
What's the latest version of VWS/the workstation stuff? I've heard
DECwindows is a bit heavy for a VS2000. ;)
DECwindows is fine on a VS2000, FYI. (been there, done that...for YEARS)
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
Afternoon all,
What's the latest version of VWS/the workstation stuff? I've heard DECwindows is a bit heavy for a VS2000. ;)
I found JVWS044 (This...might be the Japanese version...) over on slave.hecnet.eu's archive...but I can't manage anything beyond 10K/sec there. Anyone have a newer version on a faster, more local link anywhere?
Thanks!
--
Cory Smelosky
http://gewt.net Personal stuff
http://gimme-sympathy.org Projects
I know Chrissie is/was a member of the HECnet list so hopefully I'm not stepping on any toes, but there might be some here interested by this announcement, even interested in taking over the project. In any case I thought some would like to know.
John H. Reinhardt
-------- Original Message --------
Subject: [Linux-decnet-user] All finished
Date: Tue, 10 Jun 2014 09:02:37 +0100
From: Chrissie <christine.caulfield at googlemail.com>
To: linux-decnet-user at lists.sourceforge.net
So this is it, I'm announcing the end of my involvement in all things
Linux/DECnet related.
I've orphaned all the Debian packages and I'm going to leave Sourceforge
and this mailing list. I'm not going to delete the project (if that's
even possible) as I think there's value in leaving the code online in
case people want it.
Thank you do everyone who has contributed to this project in the form of
code, documentation, help on the mailing list, and just general
encourangement. It's been fun.
But life moves on and this project has been almost dead for a while and
I need to stop pretending that it's something I'm doing.
XX
Chrissie
_______________________________________________
Project Home Page: http://linux-decnet.wiki.sourceforge.net/
Linux-decnet-user mailing list
Linux-decnet-user at lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/linux-decnet-user
On 2014-06-07 00:03, Mark Pizzolato - Info Comm wrote:
On Thursday, June 05, 2014 at 4:50 PM, Mark Pizzolato wrote:
On Thursday, June 05, 2014 at 4:33 PM, Johnny Billquist wrote:
On 2014-06-06 01:16, Mark Pizzolato - Info Comm wrote:
OK. So you sound like you really need a throttling option for the
LAN
devices. I'll look over the throttling logic in the bridge and fold
in something similar.
Well, I'm not so sure that code should be a model to pattern anything after.
Everything about my bridge is just a hack. Done just to fix an
immediate problem without any proper design at any corner. :-)
It definitely has more going for it then my first thoughts. Before looking at
your bridge code, I was merely going to create an option to measure the time
between successive packets. Your model allows for some bursting but then
starts throttling.
I'll make it an option and the control variables (TIMEWINDOW, BURSTSIZE,
DELAY) configurable. Default will be no throttle.
The current simh code base has Ethernet transmit throttling support for XQ and XU devices.
The default behavior is unchanged (i.e. no throttling).
Throttling for a particular LAN interface can be enabled with:
sim> SET {XQ|XQB|XU|XUB} THROTTLE=DISABLE
sim> SET {XQ|XQB|XU|XUB} THROTTLE=ENABLE
sim> SET {XQ|XQB|XU|XUB} THROTTLE=TIME=n{;BURST=n{;DELAY=n}}
Where:
TIME=n specifies an inter-packet gap (in ms) which can trigger throttling
BURST=n specifies the number of successive packets which sent with a gap < TIME will trigger throttling
DELAY=n specifies the number of milliseconds to delay when before transmitting the next packet
Defaults for these are TIME=5, BURST=4 and DELAY=10
The defaults were taken from Johnny's Bridge program. Since I don't have working physical systems to test with, I'm looking for feedback on good working choices for these default values.
Cool. I'll test this in a couple of days. This would actually be a big improvement for me.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Thursday, June 05, 2014 at 4:50 PM, Mark Pizzolato wrote:
On Thursday, June 05, 2014 at 4:33 PM, Johnny Billquist wrote:
On 2014-06-06 01:16, Mark Pizzolato - Info Comm wrote:
OK. So you sound like you really need a throttling option for the
LAN
devices. I'll look over the throttling logic in the bridge and fold
in something similar.
Well, I'm not so sure that code should be a model to pattern anything after.
Everything about my bridge is just a hack. Done just to fix an
immediate problem without any proper design at any corner. :-)
It definitely has more going for it then my first thoughts. Before looking at
your bridge code, I was merely going to create an option to measure the time
between successive packets. Your model allows for some bursting but then
starts throttling.
I'll make it an option and the control variables (TIMEWINDOW, BURSTSIZE,
DELAY) configurable. Default will be no throttle.
The current simh code base has Ethernet transmit throttling support for XQ and XU devices.
The default behavior is unchanged (i.e. no throttling).
Throttling for a particular LAN interface can be enabled with:
sim> SET {XQ|XQB|XU|XUB} THROTTLE=DISABLE
sim> SET {XQ|XQB|XU|XUB} THROTTLE=ENABLE
sim> SET {XQ|XQB|XU|XUB} THROTTLE=TIME=n{;BURST=n{;DELAY=n}}
Where:
TIME=n specifies an inter-packet gap (in ms) which can trigger throttling
BURST=n specifies the number of successive packets which sent with a gap < TIME will trigger throttling
DELAY=n specifies the number of milliseconds to delay when before transmitting the next packet
Defaults for these are TIME=5, BURST=4 and DELAY=10
The defaults were taken from Johnny's Bridge program. Since I don't have working physical systems to test with, I'm looking for feedback on good working choices for these default values.
- Mark
On Thursday, June 05, 2014 at 4:33 PM, Johnny Billquist wrote:
On 2014-06-06 01:16, Mark Pizzolato - Info Comm wrote:
OK. So you sound like you really need a throttling option for the LAN
devices. I'll look over the throttling logic in the bridge and fold in something
similar.
Well, I'm not so sure that code should be a model to pattern anything after.
Everything about my bridge is just a hack. Done just to fix an immediate
problem without any proper design at any corner. :-)
It definitely has more going for it then my first thoughts. Before looking at your bridge code, I was merely going to create an option to measure the time between successive packets. Your model allows for some bursting but then starts throttling.
I'll make it an option and the control variables (TIMEWINDOW, BURSTSIZE, DELAY) configurable. Default will be no throttle.
- Mark
