Networking the Prime emulators
Jim Wilcoxson
(Prime Network Controller) to showcase Prime's networking technology
on the public emulators. The public emulators are available here:
telnet prirun.dyndns.org 8001 for Primos rev 19
8002 for rev 20
8003 for rev 21
8004 for rev 22
8006 for rev 24
then login guest, password is pr1me.
The emulators are networked in a simulated Prime token ring that is
implemented over TCP/IP. The nodes are named em19 - em24, remote
login is enabled, and each node has remote disks from the other
nodes. Rev 21 is not quite functional because I didn't have any Prime
networking software and tried to use rev 20. Outbound access from rev
21 seems to work okay, but inbound access is flaky. If anyone has rev
21 versions of PRIMENET* and the utilities for CMDNC0 like
START_NET.RUN, I'd like to get this node running correctly.
So, a little background. Okay, a lot of background! :)
Primenet was the name used for Prime's networking in general. It
allowed remote disk access, remote login, and there was an API (the X$
routines) for programmers to write their own servers and clients.
Many commands could also be used over the network by adding the -ON
option. For example, M SYSTEM -ON <node> would send a message to the
system console on a Primenet node. Remote login allowed a terminal
connected to node A to login to node B by saying LOGIN JIMMY -ON B.
Remote disks were added with the AD command, like local disks, but
using the disk name and node name: AD USER19 -ON EM19 for example.
Primenet was available over many different networking technologies:
- Prime's token ring
- point to point full duplex synchronous
- point to point half duplex dial-up synchronous
- X.25 packet switches
The Primenet software worked exactly the same over all of these
physical network types.
Originally, Prime used a single system process, FAM (File Access
Manager), to handle all remote disk accesses. When you wanted to
access a remote disk, a message was sent to your local FAM, it sent
the message to the remote FAM, the request was processed, and the
results returned through the same chain. This was not particularly
efficient, and Prime replaced the FAM process with FAM II. In the
rewrite, each time you accessed a remote disk, a "slave" was created
for your own personal use on that remote node. If another user needed
access to that same disk, they got their own slave. If you needed
access to 5 nodes at once, you had your own slave on each node. The
concept is the same as NFS, but this was happening at Prime in the
late 70's; NFS was created in 1984 according to Wikipedia.
Primenet remote disks actually operated via remote subroutine calls.
If you called SRCH$$ to open a file on a remote disk, your local SRCH$
$ would see that the disk is remote, package up your arguments, and
send the request to your remote slave. The slave unpacked the
arguments, called SRCH$$ for you on the now local disk, packed up the
results of the call, and sent the response over the network. Your
local SRCH$$ unpacked the response, set the return values, and
returned to your program, without you even knowing the disk was
located on another node.
An interesting use of this was with Midasplus. The original MIDAS
product was Prime's indexed sequential software - mostly for COBOL,
though it was accessible from Fortran (the native API), RPG, Basic/
VM. Using MIDAS over the network was just asking for trouble, because
to insert 1 record required many file accesses and there was no
convenient way to lock the file while all of these file accesses
completed. So Mark Rees and Ian Reid, a couple of *marketing* guys at
Prime, took it upon themselves to rewrite the entire MIDAS package
(gobs of Fortran) in PLP. We were one of the early alpha testers, and
it was a huge success. Instead of doing remote file access, Midasplus
sent each ISAM call directly to the remote slave and let *it* add the
record, or whatever. This meant that only local locking mechanisms
needed to be created: shared semaphores in shared memory.
Another interesting twist on remote disks occurred with EPF's. An EPF
(Executable Program Format) was the Prime runfile format that allowed
paging directly from the filesystem like Multics. When you "ran" an
EPF, Primos used the DAM (Direct Access Method) file indexes to set up
the page maps and then as the program executed, it faulted pages into
memory as necessary. Of course, all modern OS's do this But what
happens when an EPF is on a remote disk? One solution would be to
implement remote paging, and I think Apollo did implement this on
their Domain OS. (Same guys that did Prime left to do Apollo). But
on the Prime, a remote EPF was handled by copying the remote pages to
the local paging disk; it didn't page over the network.
The emulator implements the PNC / ring controller. The Prime ring
allowed up to 254 nodes, each with a unique node id, in a 10Mbit (I
think) token ring. Node id 255 was reserved as the broadcast id: all
nodes on the ring would accept the packet and pass it on. Wikipedia
says IBM invented the token ring in the early 80's and released their
4Mbit product in the mid 80's. Prime's source code has references to
the Fall of 1978 for their networking software, and we were definitely
using it in the 1980 timeframe. We had a P400 and P650 in a ring.
The token ring cable was fat, like 3/4", and each node had a junction
box. If the computer went down, the junction box automatically closed
so that the node was isolated from the ring and the ring was still
intact.
Token rings are simple in concept: a single token cirulates around the
ring. When a node sees the token, it can send data followed by the
token. As packets go by, each node accepts packets addressed to it
and sets a bit saying it has seen the packet. *All* packets are
passed on to the next node. The sending node takes packets it sent
off the network and checks the ack byte to see if the packet made it
to its destination.
I haven't run any performance tests with the emulator token ring. Of
course, it should be faster than a real Prime ring, but as I was
developing it, it's clear that many buffers and timers Prime used were
designed with efficient limits in mind. For example, since most
terminals ran at 9600bps or slower, the remote login buffers and
packets were relatively small, and timers were set up to fill the
buffers at rates that made sense for a terminal. Trying to use these
same parameters for a terminal running at 1MB/sec ain't gonna cut it,
and you'll see a lot of jerkiness. I'd like to get a ping program
working to benchmark the response times and throughput numbers.
Have fun with the new toy!
Jim
prirun at gmail.com
Dennis Boone
> (Prime Network Controller) to showcase Prime's networking technology
> on the public emulators. The public emulators are available here:
Hey, fun! Also impressive, considering what you had to work with in
terms of documentation.
> Using MIDAS over the network was just asking for trouble, because
> to insert 1 record required many file accesses and there was no
> convenient way to lock the file while all of these file accesses
> completed. So Mark Rees and Ian Reid, a couple of *marketing* guys at
> Prime, took it upon themselves to rewrite the entire MIDAS package
> (gobs of Fortran) in PLP. We were one of the early alpha testers, and
We had a ringnet between the two machines in our office, but none
at customer sites. We had the usual problems with staff not paying
attention and running whole application builds on remote files and
such, but somehow I don't recall ever having much trouble with them
accessing MIDAS files remotely.
In '87-'88ish, we did have some larger sites that had MIDSASPLUS
locking problems even without a network involved, though. Enough
users adding records to several large files each, and you got MIDAS
40 errors. The lock timeouts (30 sec?) expired before they got
their turn.
> The token ring cable was fat, like 3/4", and each node had a junction
> box. If the computer went down, the junction box automatically closed
> so that the node was isolated from the ring and the ring was still
> intact.
The cable was twinaxial, with screw-on connectors. The junction box
had a locking chrome bat toggle switch (lift, toggle, release) on it
that let you take the node out of the ring forcefully if it went nuts.
Seems like there was an LED on the box as well.
I didn't remember ringnet being as fast as 10 Mbit -- maybe 1 or 2.
You think it really was that fast? I recall it seeming slow to access
remote files on the Prime compared to remotely loading e.g. the word
processor over the Novell network that they installed in administration
around the same time. The Novell network loaded software over 10
Mbit ethernet faster than you could load it from local MFM disk.
Ok, granted, MFM disk was abysmally slow. :)
De
Jim Wilcoxson
> Seems like there was an LED on the box as well.
Yep, red I think! :)
> I didn't remember ringnet being as fast as 10 Mbit -- maybe 1 or 2.
> You think it really was that fast?
Yeah, I have a doc that says it was 10Mb and that a PNC could do 400
packets/second. Packet sizes were 256 or 1024 words, just for the
data w/o any framing, so even at the smaller size that's over 1Mb. I
need to do some experiments with the packet size too. I remember at
Ford we hacked Primos to use the larger packet size, but when I tried
it here, it still used 256 words. There was a symbol in the Primos
load map, BRINGS, that was changed from 256 to 1024. I'm guessing
there's something else that needs to be changed too. Either that, or
we only *thought* we were changing the packet size - it was a lot
harder to verify back then! :)
Another thing I forgot to mention about slaves that was kinda cool:
they ran as your userid on the remote node. So all access checking
happened automagically in the regular filesystem code. This worked
great for systems that had similar userid setups, ie, JIMMY on system
A was the same as JIMMY on system B. When configuring the network
nodes, you disabled remote validation. This is how I have the
emulator ring setup. If you had systems with different userid
administration, remote validation would be enabled. Then, if you
tried to access a remote disk, you'd get a validation error. To make
it work, you used the ARID command: ARID -ON B KANG PASSWORD. Then
whenever you accessed a remote disk on system B, Primenet would verify
that there was a valid user KANG on that system and check the login
password. Assuming it worked, you got your remote access. Your slave
on B would be listed as KANG, not JIMMY.
Another tidbit: it was common to see diagrams with a train of packets
traveling around the ring and a token as the caboose. But actually,
the ring was so fast that there had to be at least 16 nodes, each
introducing a propagation delay of 6 bits, before the smallest 6-byte
packet would be completely "on the cable".
There was a shortcoming of the design when a node went offline. The
junction box shunted, keeping the ring intact, but now the physical
distance between the two nodes on either side of the failed node
increased, because the failed node was not regenerating the signal.
At 750 ft, the signal degraded enough to cause packet corruption.
Ford had a campus-wide ring in Dearborn, but I'm pretty sure they had
a fiber optic network and ran the Prime ring over that.
Dennis Boone
> Ford we hacked Primos to use the larger packet size, but when I tried
> it here, it still used 256 words. There was a symbol in the Primos
> load map, BRINGS, that was changed from 256 to 1024. I'm guessing
> there's something else that needs to be changed too. Either that, or
> we only *thought* we were changing the packet size - it was a lot
> harder to verify back then! :)
Sure BRINGS was packet size, not node count?
> tried to access a remote disk, you'd get a validation error. To make
> it work, you used the ARID command: ARID -ON B KANG PASSWORD. Then
I'd forgotten about ARID. We had essentially identical SADs on both of
our machines, so we didn't use it much.
> Ford had a campus-wide ring in Dearborn, but I'm pretty sure they had
> a fiber optic network and ran the Prime ring over that.
I've always wondered about that setup. Did they get Prime to do a
special to have fiber? Or was that a standard option? Those were
mostly 2250 machines, right? System administration must have been fun.
The Internals class I attended in Dallas was also attended by a couple
of people from Dearborn.
De
matt weber
>
>I didn't remember ringnet being as fast as 10 Mbit -- maybe 1 or 2.
>You think it really was that fast? I recall it seeming slow to access
>remote files on the Prime compared to remotely loading e.g. the word
>processor over the Novell network that they installed in administration
>around the same time. The Novell network loaded software over 10
>Mbit ethernet faster than you could load it from local MFM disk.
>Ok, granted, MFM disk was abysmally slow. :)
the regional com specialists commenting that in reality, it was pretty
hard to get link between any two systesm going faster than about
300kbytes/second.
Unlike Ethernet, there are tokens circulating the Ringnet even if
there is no traffic. The good news is that the Ringnet performance
remained pretty constant regardless of load. The bad news was you
could never get all of the available bandwidth because of the empty
tokens circulating.
Jim Wilcoxson
> > need to do some experiments with the packet size too. I remember at
> > Ford we hacked Primos to use the larger packet size, but when I tried
> > it here, it still used 256 words. There was a symbol in the Primos
> > load map, BRINGS, that was changed from 256 to 1024. I'm guessing
> > there's something else that needs to be changed too. Either that, or
> > we only *thought* we were changing the packet size - it was a lot
> > harder to verify back then! :)
>
> Sure BRINGS was packet size, not node count?
Yeah, I guess I goofed something up the first time I tried patching
it. Here's how:
OK 19, l
UFD=<SYS192>PRIRUN 0 OWNER
PRIMOS *COLDS VERSION_STAMP.CPL RING0.MAP
RING3.MAP
PR0000 PR0004 PR0005 PR0006 PR0010 PR0011 PR0012 PR0013
PR0014
PR0015 PR0032 PR0034 PR0033 PR0037 PR0040 PR0067 PR0070
PR0141
PR0142 PR0401 PR6000 PR6003 PR0016 PR0031
OK 19, copy pr0012 pr0012.orig -dtm
OK 19, ed ring0.map
EDIT
l BRINGS
BRINGS 0012 020603 OTHER
q
OK 19, rest pr0012
pOK 19, m
SA,EA,P,A,B,X,K=
100 176721 1000 0 0 0 0
PB,SB,LB,XB:
4000(0)/1000 0(0)/0 4000(0)/2216 0(0)/0
OK 19, vpsd
$a 20603:d
4000/ 20603 00256 1024!
$q
OK 19, sa pr0012.bigring.patch 20603 20603 0 0 0 0 0
OK 19, rest pr0012
OK 19, rest pr0012.bigring.patch
OK 19, sa pr0012 100 176721 1000 0 0 0 0
OK 19, sh all
REALLY? yes
WAIT,
PRIMOS NOT IN OPERATION
Then it worked. It also pointed out a flaw in the emulator PNC design
when a packet has to be truncated because it's too big for the
receiver to handle. :) Now when that happens, the link goes down
between the incompatible systems. I'm going to try to patch the
public emulators today.
> > Ford had a campus-wide ring in Dearborn, but I'm pretty sure they had
> > a fiber optic network and ran the Prime ring over that.
>
> I've always wondered about that setup. Did they get Prime to do a
> special to have fiber? Or was that a standard option? Those were
> mostly 2250 machines, right? System administration must have been fun.
> The Internals class I attended in Dallas was also attended by a couple
> of people from Dearborn.
I'm not sure who did the fiber interface. I'm guessing it was the
fiber networking people, not Prime. When companies as big as Ford say
jump, vendors just say "how high?" !
In the beginning, Ford used Prime 150/250 machines. Not sure about
the exact model, but they were in the same (large!) box as the 550,
650, 750, and each supported 2 design engineers. They were configured
with those CMD disk drives, with a fixed part and a removable disk
cartridge thingy. It had 1 standard disk (300mb/80mb size) platter
inside the cartridge and was about 2 inches thick. I think it held
something like 68MB. They went with these because Ford was using 32K
CDC systems with a removable drive. Design engineers literally
carried their work around with them, and I think the idea was that it
would make the transition easier. This was in 1980. With the Prime
and Primenet, Ford was able to network all their machines together and
wrote a custom file server program to store the design data on "Data
Collectors". Once that got going, there was no need for the removable
drive setup and Ford did switch to the 2250's, aka Rabbit. It was a
pretty cool setup: all of the design systems were connected in a ring
to the data collector machine. The data collectors on campus were
connected over the fiber network. Hmm, now that I think about it,
maybe that fiber network was just an X.25 network and not a ring. I
dunno exactly. And the data collectors were connected to a packet
switch via the MDLC (synchronous) board running X.25. I'm sure about
that part, because I got to debug one that was having trouble with
long file transfers.
Okay, so - file transfers. One of the problems with X.25 was that
when things got screwed up, it was allowed to do a "circuit reset",
which means "things are screwed up and I don't know how to recover,
but your connection is still there". As you can imagine, getting one
of these is not useful. The Ford code closed the connection and
started the file transfer over, which is about all you can do. When I
went back to Ford in 85 to do contract work, this was my first job:
international file transfers don't work because a circuit reset almost
always happens on long file transfers. It was sometimes taking days
to get parts transferred because of the reset/close/restart
recovery. So I wrote a file transfer program with a sliding window
network protocol above the X.25 network that could recover from
circuit resets and continue the part transfer. One thing that was
really useful is that this not-so-important design group was having
problems with their file transfers too, even to nearby machines. I
put a fancy-dancy protocol scope on their MDLC board and watched it.
After a while a pattern of failures emerged, I started looking at some
Primos MDLC driver code, and there was a bug in their MDLC error
recovery code, ie, they didn't do the right thing when a CRC error
occurred. So, fixed that, but were still getting lots of errors.
That turned out to be a bad MDLC board. Fixed that, and now only
getting errors at 7am for about 10 minutes, or something like that.
No kidding! So some Ford guys started asking the building crew if
anything unusual happened around 7am for 10 minutes, and it turned out
that there was some kind of a generator test. The synchronous cable
was running in parallel to a power cable from this generator, so when
the generator kicked on, it corrupted everything on the sync cable.
Generator off, X.25 good again. The useful part of all this was it
gave me a fantastic test bed for generating lots of X.25 circuit
resets to test the new file transfer program under extreme
conditions. I told some Ford guys they needed to save that broken
MDLC board that generated random CRC errors, to use for testing!
matt weber
I am sure Fiber Optic Ringnet wasn't a standard product.
There was a lot of empty real estate on the PNC board, and I know
several specials existed to utilize the avalailable real estate. I'd
be very surprised if a fiber optic version wasn't one of the specials.
I know there was an NSC Hyperchannel version of the PNC board
available as a special.
IRRC Ford has 2250's for the actual work, and much larger machines to
act as 'collectors'..
Dennis Boone
> with those CMD disk drives, with a fixed part and a removable disk
> cartridge thingy. It had 1 standard disk (300mb/80mb size) platter
> inside the cartridge and was about 2 inches thick. I think it held
> something like 68MB.
We had a couple of CMDs, and a few of our earliest customers had
them, attached 250 systems iirc. Depending on where you look,
they were available in 32, 64 and 96MB versions (2, 4 and 6 surfaces
respectively), or 16, 48 and 81MB versions. The former details come
from the Prime doco, the latter from a list of CDC drives on Bitsavers.
The cartridge was 16MB, a single surface. The drives were CDC 9448
Phoenix drives.
Unlike most of the other similar drives in the industry, the Phoenix
cartridge slid into the drive via a rail system built into the top
of the pack case, and the front-loading door mechanism lowered it
into the pack well when the door was closed.
It was one of these drives that ate a pigeon feather in our so-called
computer room.
De
Jim Wilcoxson
> I know there was an NSC Hyperchannel version of the PNC board
> available as a special.
Oh ugh! I actually worked on this stuff too. Ford wanted to get
Hyperchannel working so they could talk to their Cray. As I recall,
what we had was based on the MPC4 - the programmable controller that
Ford also used for their Lundy vector tube interface. I think the
Lundy was the first use of the MPC4, because I worked with Will
Babetski, Doug Detroy, and Bill Huber from Prime and Marty Hess and
Jerry Damian (mainly) from Ford while they were developing it. The
Hyperchannel thing came a few months later, after the design had
stabilized.
All that Hyperchannel crap was written in Pascal, and the version we
had was full of bugs. Jerry Damian and I hacked on it to get it
somewhat working, if it felt like it, but even when it did run it was
nowhere near the data rates advertised. Some aerospace company (I
think!) in LA heard about what we were doing with it at Ford and flew
me out there to install the Ford mods at their site, since it at least
worked sometimes. We gave up on it after a week or two of hacking.
> IRRC Ford has 2250's for the actual work, and much larger machines to
> act as 'collectors'..
Thanks to Prime's compatibility across machines, and because of the
huge number of machines Ford bought, they had some of almost
everything. But you're right, the DC machines, at least at the large
sites, were usually "the biggest Prime that could be bought at the
time". The development group's machine was also a data collector,
mostly for testing, and the last one was a 6550. It's node name was
"D1D1". I think the naming convention went something like: the first
two letters were a ring name and the second 2 were related to the
machine's function. So B1D1 would be the first Body (Design Center)
data collector, B1D2 would be a second DC machine on the same ring,
B2D1 would be on a different ring. And they had some other suffix for
the actual design machines, but I don't remember how that worked. I
do remember G1D1 was in Germany!
Ford had NFS running on the Prime at the end, when stuff was being
converted to Unix. I don't know much about how that all worked
because I was working on converting Ford's code for Unix by that time,
so not much involved with the Prime side. Man, I wish I had the
foresight to write the emulator back then instead of waiting 15 years
later! Probably could have made some extra pocket change if it was
available in the early 90's!
Dennis Boone
> Hyperchannel working so they could talk to their Cray. As I recall,
> what we had was based on the MPC4 - the programmable controller that
> Ford also used for their Lundy vector tube interface. I think the
> Lundy was the first use of the MPC4, because I worked with Will
> Babetski, Doug Detroy, and Bill Huber from Prime and Marty Hess and
> Jerry Damian (mainly) from Ford while they were developing it. The
> Hyperchannel thing came a few months later, after the design had
> stabilized.
I remember hearing about MPC4 controllers back then. Just went and
looked in the price book from '87 and they're not listed there by
that name. Was the MPC4 the basis of the GPIB and DAC offerings,
with task-specific microcode?
While googling I did stumble across a mention of using an MPC4 to
acquire (and Primenet to transfer) image data from one of the Mars
probes for an exhibit at the National Air and Space Museum. It also
appears that support was available for them was available to federal
agencies from a third party as late as 2003.
De
Jim Wilcoxson
> I remember hearing about MPC4 controllers back then. Just went and
> looked in the price book from '87 and they're not listed there by
> that name. Was the MPC4 the basis of the GPIB and DAC offerings,
> with task-specific microcode?
Hmm... the MPC4 was developed in the first half of 1981. I left the
summer of 81 to finish school. Looking through some Primos source,
there is a T$MG Megatek graphics terminal interface and a T$GS Vector
General graphics terminal interface. But these look like very simple,
"dumb" interfaces that can read and write data, do DMC I/O, and wait
for an interrupt. I do recall Ford testing a Megatek display, but I'm
not sure what controller it used to interface to the Prime. It could
have been an MPC4 that wasn't loaded with anything. Could compare all
the I/O instructions between these and the MPC4 to see how similar
they are I guess...
> While googling I did stumble across a mention of using an MPC4 to
> acquire (and Primenet to transfer) image data from one of the Mars
> probes for an exhibit at the National Air and Space Museum. It also
> appears that support was available for them was available to federal
> agencies from a third party as late as 2003.
Pretty cool. Doing the microcode for an MPC4 was not something
ordinary mortals could do. Will Babetski worked on that. There was
an oscilloscope hooked up to it at all times while he was working on
it or debugging stuff. Yikes! Matt probably could have had an
interesting conversation with him, but it seemed otherworldly to me.
Andrew
> telnet prirun.dyndns.org 8001 for Primos rev 19
> 8002 for rev 20
> 8003 for rev 21
> 8004 for rev 22
> 8006 for rev 24
> The emulator implements the PNC / ring controller.
I get an error from netlink on the rev24 machine:
OK, netlink
[NETLINK Rev. 22.1.4 Copyright (c) 1990, Prime Computer, Inc.]
Fatal error linking to the internationalization system (SIT stage = 7)
No information. (SI$INI)
Please report this problem to your system administrator.
ER!
Jim Wilcoxson
> I get an error from netlink on the rev24 machine:
>
> OK, netlink
> [NETLINK Rev. 22.1.4 Copyright (c) 1990, Prime Computer, Inc.]
>
> Fatal error linking to the internationalization system (SIT stage = 7)
> No information. (SI$INI)
> Please report this problem to your system administrator.
> ER!
Hey Andrew! Consider it reported. :) I don't know how to install all
this new stuff; the rev 24 system is a cleaned-up tape dump of a
supposedly running system. If anyone knows how to fix this, I'll try
it.
If you connect to port 8006, instead of login guest, you can say login
guest -on em19 for example. So remote login works, just not netlink.
Agents Marlow
> > I get an error from netlink on the rev24 machine:
> > OK, netlink
> > [NETLINK Rev. 22.1.4 Copyright (c) 1990, Prime Computer, Inc.]
>
> > Fatal error linking to the internationalization system (SIT stage = 7)
> > No information. (SI$INI)
> > Please report this problem to your system administrator.
> > ER!
>
> Hey Andrew! Consider it reported. :) I don't know how to install all
> this new stuff; the rev 24 system is a cleaned-up tape dump of a
> supposedly running system. If anyone knows how to fix this, I'll try
> it.
I used to know about SIT, many years ago. I think the error might be a
permissions problem. IIRC, SIT holds the internationalisation data in
seg dirs under the directory SIT*. This means that everyone needs RU
access to that dir and R access to the segdirs. Worth a try....?
-Andrew
Jim Wilcoxson
> I used to know about SIT, many years ago. I think the error might be a
> permissions problem. IIRC, SIT holds the internationalisation data in
> seg dirs under the directory SIT*. This means that everyone needs RU
> access to that dir and R access to the segdirs. Worth a try....?
>
> -Andrew
Thanks Andrew, I'll give that a try over the weekend.
Seems the new ring stuff has a bug, because the 4 emulators with it
turned on are locked up. :( Rev 21 on port 8004 is the only one
getting to an OK prompt. My guess is that I've accidentally put
NETMAN into a loop, and since it runs at a higher priority than any
user, no one can log in. All of the initial login stuff still prints
because that is printed by login_server; it also runs at a high
priority. I'll take a look at that this weekend too; might have to
temporarily disable the ring code until it's fixed.