On Wed, Apr 08, 2009 at 11:18:14PM -0400, Sridhar Ayengar wrote:
Sampsa Laine wrote:
So if I have two dual port PCI cards, one in machine 1, one in machine
2, I wire them:
1.A. -> 2.B
2.A -> 1.B
No,
1. A -> B
2. B -> A
Which is exactly what Sampsa said in the first place.
Ignore him, Sampsa, you have the right idea.
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
Sampsa Laine wrote:
On 8 Apr 2009, at 21:34, Paul Koning wrote:
Sampsa> Anybody know how I would go about cabling such a beast, there
Sampsa> are four fibre optic ports on these things?
Wow, that takes me back a bunch of years...
Well I do try, I'm going to wire up a CBM 128D running CP/M as the OPA0: on one of these eventually :)
There are two basic FDDI cabling approches: dual ring, and tree of
concentrators. The DEFPA can be hooked up either way because it has
the two ports (type A and B ports).
If you have other FDDI devices that also have A or B ports, just plug
A to B in a circular fashion, and you have a dual ring. This is the
topology that FDDI originally started with early in its development.
So if I have two dual port PCI cards, one in machine 1, one in machine 2, I wire them:
1.A. -> 2.B
2.A -> 1.B
No,
1. A -> B
2. B -> A
to make a circle.
Peace... Sridhar
Sampsa Laine wrote:
Guys,
I've just received a DEFPA-DB PCI-FDDI adapter from ebay, my plan is to install it in CHIMPY and then connect CHIMPY to CHIMP via this for clustering.
Anybody know how I would go about cabling such a beast, there are four fibre optic ports on these things?
Also, can I route DECNET traffic over this interface - I assume not as bot machines are Alphas and they don't do routing...
http://www.siliconsamsara.org/OLD/PracFDDI/index.html
Peace... Sridhar
On Wed, Apr 08, 2009 at 04:34:06PM -0400, Paul Koning wrote:
Sampsa> Guys, I've just received a DEFPA-DB PCI-FDDI adapter from
Sampsa> ebay, my plan is to install it in CHIMPY and then connect
Sampsa> CHIMPY to CHIMP via this for clustering.
Wow, that takes me back a bunch of years...
Yeah, no kidding. I just recently picked up a pair of VAX 4000/500 boxes
and each one had a DEFQA-SA in it. Now I either need to pick up a cheap
NP-1F-D-MM for one of my Cisco 4700 routers or dust off the Sun Ultra1
that has the FDDI card in it.
Hmmmmm. No, must be good. Must move first before setting up VAXen. :)
-brian
--
"Coding in C is like sending a 3 year old to do groceries. You gotta
tell them exactly what you want or you'll end up with a cupboard full of
pop tarts and pancake mix." -- IRC User (http://www.bash.org/?841435)
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
If you have other FDDI devices that also have A or B ports, just
plug A to B in a circular fashion, and you have a dual ring. This
is the topology that FDDI originally started with early in its
development.
Sampsa> So if I have two dual port PCI cards, one in machine 1, one
Sampsa> in machine 2, I wire them:
Sampsa> 1.A. -> 2.B 2.A -> 1.B
Sampsa> To create a circle? Do I HAVE to do this, i.e. can I just
Sampsa> wire one cable between machine 1 and 2 (the cables are
Sampsa> EXPENSIVE, like 3x what the adapter cost me)?
One connection is fine.
As I mentioned, the standard topology for A/B stations (Dual Attached
stations) is A to B in a circular fashion. That creates a pair of
rings. And that topology can handle single faults: the loss of a
single port or single cable.
If you just connect the two stations with a single cable, what you
created is a dual ring with a single fault -- one of the two cables is
missing. That will work just fine.
paul
On 8 Apr 2009, at 21:34, Paul Koning wrote:
Sampsa> Anybody know how I would go about cabling such a beast, there
Sampsa> are four fibre optic ports on these things?
Wow, that takes me back a bunch of years...
Well I do try, I'm going to wire up a CBM 128D running CP/M as the OPA0: on one of these eventually :)
There are two basic FDDI cabling approches: dual ring, and tree of
concentrators. The DEFPA can be hooked up either way because it has
the two ports (type A and B ports).
If you have other FDDI devices that also have A or B ports, just plug
A to B in a circular fashion, and you have a dual ring. This is the
topology that FDDI originally started with early in its development.
So if I have two dual port PCI cards, one in machine 1, one in machine 2, I wire them:
1.A. -> 2.B
2.A -> 1.B
To create a circle? Do I HAVE to do this, i.e. can I just wire one cable between machine 1 and 2 (the cables are EXPENSIVE, like 3x what the adapter cost me)?
Sampsa
"Sampsa" == Sampsa Laine <sampsa at mac.com> writes:
Sampsa> Guys, I've just received a DEFPA-DB PCI-FDDI adapter from
Sampsa> ebay, my plan is to install it in CHIMPY and then connect
Sampsa> CHIMPY to CHIMP via this for clustering.
Sampsa> Anybody know how I would go about cabling such a beast, there
Sampsa> are four fibre optic ports on these things?
Wow, that takes me back a bunch of years...
There are two basic FDDI cabling approches: dual ring, and tree of
concentrators. The DEFPA can be hooked up either way because it has
the two ports (type A and B ports).
If you have other FDDI devices that also have A or B ports, just plug
A to B in a circular fashion, and you have a dual ring. This is the
topology that FDDI originally started with early in its development.
It has single-fault tolerance, but it doesn't support hierarchical
wiring (wiring closets). The single-fault tolerance means you can
make a chain instead of closing the ring, that's equivalent to the
ring with a single cable busted.
If you have a concentrator (a box with either A/B ports or S port,
plus a number of M ports) plug either A or B into an M port and leave
the other unused.
Finally, if you have another device with an S port (a "single attached
station") you can plug that into either the A or the B port, leaving
the other port available for another S port, or another A/B port. I
don't think you should have S to A and B to M, but I don't remember
for sure. If you have concentrators, the rule is that any single
attached devices plug into M ports, while dual attached devices plug
either into an M port or into the root dual ring.
paul
Guys,
I've just received a DEFPA-DB PCI-FDDI adapter from ebay, my plan is to install it in CHIMPY and then connect CHIMPY to CHIMP via this for clustering.
Anybody know how I would go about cabling such a beast, there are four fibre optic ports on these things?
Also, can I route DECNET traffic over this interface - I assume not as bot machines are Alphas and they don't do routing...
Sampsa
Marc Chametzky wrote:
You have two (well, three) potential problems here.
Of the problems you list, most of them aren't actually the kinds of problems you'd expect. ESXi is very good about presenting multiple virtual interfaces to its guest operating systems over a single physical interface. ESXi creates a virtual bridge to handle this. It's even possible using VLANs to set up different LAN segments to isolate traffic between guests.
There are more things to it than might appear to the eye here. The problem is that TCP/IP, by its design, don't care about them, but DECnet do. And so, virtual machines can work fine with OSes that talk TCP/IP, and most likely the implementors of the virtual machine have only tried TCP/IP, and possibly something like IPX, but most likely not DECnet.
I'll expand a little more below.
In this case, the Windows and the Linux system can see each other on the same LAN segment just fine. ESXi takes care of that very well.
Hmm. I have a problem understanding the topology and hardware, so you really should be more explicit. Is either of the Windows or Linux system here on a virtual host? Or both? When you say LAN segment, are we talking about a physical cable or just a virtual LAN within a host?
I'm able to configure the two VMS systems' hardware address to reflect their DECnet-computed addresses, so that's not an issue.
Don't be too sure...
What I failed to mention in my previous post (I realized it after I sent it), is that DECnet is very picky about *both* source and destination MAC address of ethernet packet.
TCP/IP couldn't care less about the source address (heck, it don't even care about the destination address, as long as the packet enters the bottom of the IP stack, TCP/IP is happy). If you have a virtual bridge in your host, it becomes very interesting to verify that the source MAC address really is set correct when a packet comes out from the machine. A bridge should be totally transparent, and so source MAC addresses should be different depending on which virtual machine actually sent the packet.
I know for a fact that there are ethernet controllers that don't allow you to set the source address of the ethernet packet at all, and instead the controller inserts its own address when the packet is being sent out. Admittendly, the controllers I know do this are the DEC controllers for Unibus and Q-bus, but there could very well be others that do this as well. These cannot be used to bridge DECnet no matter what you do.
However, they work perfectly fine to bridge TCP/IP.
If you have the wrong source address for ethernet packets I seem to remember that you will get a situation where on one side the adjacency is up, while the other side thinks not. Or if it were that adjacency look as if it was up, but if you tried establishing a connection, you'd get a timeout and failure.
Third - is the actual machine running windows, or did I misunderstand something?
The guest OS that's running the Alpha is Windows XP. I don't know what games Personal Alpha plays to make its networking work, but it's conceivable that there's some sort of issue there. I've dedicated the Windows network adapter to Personal Alpha's protocol interface, so Personal Alpha gets exclusive access to it. (This Windows system doesn't need TCP/IP connectivity anywhere... that makes it more secure anyway.)
I remember from when playing with CHARON that you needed to set the MAC address of the adapter first, and then you'd get some long identifier that was used to connect the virtual machine with the adapter. And this had to be done outside of the virtual machine, since the virtual machine itself could not actually change the MAC address of the adapter, even though VMS thinks it's doing that.
There are two potential failure points that I can imagine. One is ESXi. I don't think that this is the problem since DUSTY (on the Linux guest) is able to see LULU's packets and establish adjacency. ESXi is at least passing those packets in one direction, so it should be able to do it in both.
I wouldn't make that assumption. First of all see all my comments above. Second, adjacency just means that packets have come in one direction. It don't mean that both sides see each other. Basically it's just a case of seeing the broadcast hello packets (if we talk ethernet).
The other potential point is in Windows, and perhaps Personal Alpha's network interface. It may be dropping packets it doesn't recognize, so DECnet routing packets don't make it. Maybe. When I get a chance to use Wireshark, I'll at least see what's going on from Windows' perspective.
One possibly additional thing here is that adjacency is based on broadcast packets. This is a rather loose requirement. Broadcast packets have a much higher chance of getting through here. Once you actually try a connection, then unicasts are used, and at that point we start getting into the issue of actually having correct MAC addresses on packets and interfaces. Adjacency can very well work when these things are wrong.
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
You have two (well, three) potential problems here.
Of the problems you list, most of them aren't actually the kinds of problems you'd expect. ESXi is very good about presenting multiple virtual interfaces to its guest operating systems over a single physical interface. ESXi creates a virtual bridge to handle this. It's even possible using VLANs to set up different LAN segments to isolate traffic between guests.
In this case, the Windows and the Linux system can see each other on the same LAN segment just fine. ESXi takes care of that very well.
I'm able to configure the two VMS systems' hardware address to reflect their DECnet-computed addresses, so that's not an issue.
Third - is the actual machine running windows, or did I misunderstand something?
The guest OS that's running the Alpha is Windows XP. I don't know what games Personal Alpha plays to make its networking work, but it's conceivable that there's some sort of issue there. I've dedicated the Windows network adapter to Personal Alpha's protocol interface, so Personal Alpha gets exclusive access to it. (This Windows system doesn't need TCP/IP connectivity anywhere... that makes it more secure anyway.)
There are two potential failure points that I can imagine. One is ESXi. I don't think that this is the problem since DUSTY (on the Linux guest) is able to see LULU's packets and establish adjacency. ESXi is at least passing those packets in one direction, so it should be able to do it in both.
The other potential point is in Windows, and perhaps Personal Alpha's network interface. It may be dropping packets it doesn't recognize, so DECnet routing packets don't make it. Maybe. When I get a chance to use Wireshark, I'll at least see what's going on from Windows' perspective.
--Marc
Windows have a very weird and appearantely unreliable
interface for programs that want to talk raw ethernet.
And for virtual machines, you do want to talk raw ethernet.
But these are all just potential problems. To really diagnose all of this, you'd have to be physically by the machine to test various things.
Depending on system, as well as virtual machine, these problems can be solved, but I wouldn't bet money on anything here. :-)
Johnny
