On 10/08/2012 10:51 AM, hvlems at zonnet.nl wrote:
Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
But VMS had the advantage that it and the processor (VAX) that ran it were designed in concert. x86 architecture and Windows are more a case of being cobbled together iteratively and separately.
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
Paul, so the makefile sets the compiler flags, right? So it might be worth figuring out how much effort the compiler puts in optimizing its output.
Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
Hans
-----Original Message-----
From: <Paul_Koning at Dell.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 14:28:45
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
In my case, gcc with the default makefile. I don't use VC (or the OS it runs on) unless serious force is applied...
paul
On Aug 10, 2012, at 3:02 AM, <hvlems at zonnet.nl>
wrote:
How was simh compiled? I used Visual C and the difference between running the compiler with optimization on or off made quite a difference for the generated code. And gcc might compile even faster codefiles.
Hans
-----Original Message-----
From: Sampsa Laine <sampsa at mac.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 09 Aug 2012 23:07:24
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
Why is SIMH so slow though?
As far as I can understand, one MIPS is roughly one VUPS, correct?
So how come I get 14 VUPS on the same host running SIMH whilst my Hercules install peaks at 180?
Are the architectures that different (obviously they are) or what is it?
Sampsa
On 8/10/2012 10:35 AM, Oleg Safiullin wrote:
Brian Hechinger wrote:
I've set up the bridge to start at boot on an OpenBSD machine and I am having some issues getting anything into a log file.
I start it like this:
/var/bridge/bridge -p 4711 -d /var/bridge/ > /var/bridge/bridge.log 2>&1 &
but bridge.log is always empty. At start, after sending SIGUSR1, etc.
Thoughts?
-brian
Try to apply the patch attached to shis message.
That did it, thanks!
-brian
On Aug 10, 2012, at 5:52 AM, Johnny Billquist wrote:
...
It might be worth understanding that there is nothing technical added by going to multiple areas. It is just a complication which allows you to have more nodes, but at the cost of more complex routing.
Even within one area, you can have a large number of hops between nodes. Makes no difference to DECnet. The rules for the topological layout is simple:
1. End-nodes needs to be adjacent to atleast one level 1 router.
2. All level 1 routers in an area must be able to talk with all other level 1 routers. And only level 1 routers route messages within an area, which means you cannot have an endnode in the chain.
Essentially right. But area routers include L1 router functionality (there is no such thing as an L2-only router). So for "L1 router" you should instead say "L1 or area router".
Also, endnodes and L1 routers can only talk to a router that's in the same area as they are.
Also, each area must not be partitioned, and the L2 net must not be partitioned. The L2 net is defined by the L2 routers and their direct connections, so a pair of L2 routers connected by an L1 router are not connected at L2.
Finally, an oddball case: if a LAN does not have any routers on it, then the endnodes on it can communicate among each other, even if they are in different areas. But as soon as there are routers on the LAN, the rules you mentioned apply. So suppose you have a two-area LAN, and you want to route away from it. The minimum change you need is to add one L2 router in the one area, and another L2 router in the other area.
paul
Brian Hechinger wrote:
I've set up the bridge to start at boot on an OpenBSD machine and I am having some issues getting anything into a log file.
I start it like this:
/var/bridge/bridge -p 4711 -d /var/bridge/ > /var/bridge/bridge.log 2>&1 &
but bridge.log is always empty. At start, after sending SIGUSR1, etc.
Thoughts?
-brian
Try to apply the patch attached to shis message.
--- bridge.c.orig Fri Jun 8 13:30:28 2012
+++ bridge.c Fri Aug 10 21:33:12 2012
@@ -636,6 +636,7 @@
h = h->next;
}
}
+ fflush(stdout);
}
In my case, gcc with the default makefile. I don't use VC (or the OS it runs on) unless serious force is applied...
paul
On Aug 10, 2012, at 3:02 AM, <hvlems at zonnet.nl>
wrote:
How was simh compiled? I used Visual C and the difference between running the compiler with optimization on or off made quite a difference for the generated code. And gcc might compile even faster codefiles.
Hans
-----Original Message-----
From: Sampsa Laine <sampsa at mac.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 09 Aug 2012 23:07:24
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
Why is SIMH so slow though?
As far as I can understand, one MIPS is roughly one VUPS, correct?
So how come I get 14 VUPS on the same host running SIMH whilst my Hercules install peaks at 180?
Are the architectures that different (obviously they are) or what is it?
Sampsa
I've set up the bridge to start at boot on an OpenBSD machine and I am having some issues getting anything into a log file.
I start it like this:
/var/bridge/bridge -p 4711 -d /var/bridge/ > /var/bridge/bridge.log 2>&1 &
but bridge.log is always empty. At start, after sending SIGUSR1, etc.
Thoughts?
-brian
That's a pity, because I've always wanted to know whether the same trick would apply. The white box trick worked for me on the 3300 and a couple of 5305's. A 7305 owner in Germany made it work too. The DS20L is a different beast, right? Enough not too spend money on it. Hans
-----Original Message-----
From: "John H. Reinhardt" <johnhreinhardt at yahoo.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 08:00:18
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation - 1U Alpha systems.
On 8/10/12 2:58 AM, hvlems at zonnet.nl wrote:
If the "fiddling" is similar to what is necessary to run VMS on the white box alphas then have a look at
http://home.zonnet.nl/hvlems
The white box alphas were tergeted at the WNT market. Adding two srm parameters works wonders for VMS. It does not involve hardware mods and AFAIK the mods are completely reversible.
Hans
PS
Sent from my cell phone which will undoubtedly upset some systems. Sorry, I'm 600 kms from home.
Yeah, I don't know. I've got a white box AS1200 (aka 5305) that I
twiddled to run VMS on and I know how that works. All I ever saw was a
vague reference on comp.os.vms once about the DS20L. I was never able
to acquire one so I didn't pursue the issue.
-----Original Message-----
From: "John H. Reinhardt"<johnhreinhardt at yahoo.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 01:30:11
To:<hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation - 1U Alpha systems.
On 8/9/12 11:00 PM, Dave McGuire wrote:
On 08/09/2012 10:54 PM, Gregg Levine wrote:
Dave did the Alpha family come in a 1U size?
Yes, the DS10L comes to mind. My HECnet node AXPEE:: is one of those.
They are EV6-based (nice and quick!) and are available clocked at
466MHz and 600MHz.
There are other 1U models, but that's the one I'm most familiar with.
If so could said system be considered to be a quiet one?
Eh, so-so.
From DEC, there was only the DS10L, in two processor speeds as Dave
mentioned, and the DS20L which was an 833MHz processor system in the 1U
size. The DS10L was supported for use with any of the DEC O/S while the
DS20L was only supported for Tru64 from DEC and Linux. VMS was not a
supported O/S, although it was purported to be possible to get it to
boot with some fiddling. Unfortunately, I was never privy to the
details of such.
http://h18002.www1.hp.com/alphaserver/archive/ds20l/http://h18000.www1.hp.com/products/quickspecs/10976_na/10976_na.HTML
Alpha Processors Inc (API) also produced a 1U system. Based on the
DS20L platform, they aimed for the HPC cluster market. Also purported
to be possible to boot VMS with some fiddling, but the usual O/S was
some form of Linux. http://youtu.be/RfowtlIk9Uc
All were fairly noisy for their size. Maybe not noticeable in a
computer center, but definitely in a home setting.
John H. Reinhardt
Brian, could you verify that you have the latest version? I did some work to try and get rid of warnings a while back, and even though I'm sure some issues might be because of 64 bit issues, I would have expected some of the warnings you reported to have been fixed already...
Johnny
On 2012-08-09 21:00, Brian Hechinger wrote:
I'm trying to get the bridge built on OpenBSD 5.1 64-bit but it keep
segfaulting. Anyone ever get this working?
# cc -O2 -Wall -o bridge bridge.c -lpcap
bridge.c:65:1: warning: "MAX" redefined
In file included from /usr/include/netdb.h:90,
from bridge.c:32:
/usr/include/sys/param.h:191:1: warning: this is the location of the
previous definition
bridge.c: In function 'add_bridge':
bridge.c:241: warning: implicit declaration of function 'inet_aton'
bridge.c:263: warning: format '%d' expects type 'int', but argument 2
has type 'char *'
bridge.c:263: warning: format '%d' expects type 'int', but argument 3
has type 'char *'
bridge.c: In function 'add_service':
bridge.c:276: warning: format '%s' expects type 'char *', but argument 3
has type 'struct BRIDGE *'
bridge.c: In function 'dump_data':
bridge.c:524: warning: implicit declaration of function 'inet_ntoa'
bridge.c:531: warning: format '%s' expects type 'char *', but argument 4
has type 'int'
bridge.c: In function 'main':
bridge.c:564: warning: unused variable 'port'
bridge.c:561: warning: unused variable 'len'
/tmp//cc69aRp2.o(.text+0x934): In function `add_bridge':
: warning: strcpy() is almost always misused, please use strlcpy()
# cp bridge /var/bridge/
# cd /var/bridge/
# ./bridge 4711
Adding router ''local''. 00000000:0
Adding router ''sampsa''. 0afc2a0a:4711
Adding DECnet bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding DECnet bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Adding LAT bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding LAT bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Host table:
Segmentation fault (core dumped)
-brian
On 2012-08-10 11:55, Sampsa Laine wrote:
Aargh just realised,
Those nodes should've been 52, not 5.
So:
52.555 LABVAX
52.556 KUHAVX
52.600 DEB390
Whoops. :-)
Updated now.
Johnny
Sampsa
On 10 Aug 2012, at 12:48, Sampsa Laine wrote:
I'm talking about the DECNET for Linux MULTINET UDP tunnelling..
Sampsa
On 10 Aug 2012, at 12:47, Rok Vidmar wrote:
3. I assume I need an area for that, or am I incorrect?
With Multinet you can run DECnet over TCP in the same
DECnet area.
--
Regards, Rok
