From JNC at XX.LCS.MIT.EDU Wed Oct 26 00:00:00 1988 From: JNC at XX.LCS.MIT.EDU (J. Noel Chiappa) Date: Wed 26 Oct 88, 00:00 Subject: No subject In-Reply-To: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Message-ID: <12441656808.31.JNC@XX.LCS.MIT.EDU> It's actually in the back, inside the cabinet, on the CPU card, as I recall. (It might be next to the power switch, if I'm suffering brain fade.) However, it is in the back on the C/30's.... The right thing is actually to call the NOC; they keep stats on the number of random restarts to highlight problem hardware, and pushing the button a lot could get us a new box, all full of new bugs... Noel ------- From Moon at STONY-BROOK.SCRC.Symbolics.COM Mon Oct 24 20:46:00 1988 From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) Date: Oct 24 88 15:46 EDT Subject: MC In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU> Message-ID: <19881024194656.3.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Mon, 24 Oct 88 14:46:59 EDT From: David Chapman For what it's worth, I'm in favor of an immediate CPU swap. Maybe the problem is the power supply, not the boards. The errors it's getting are "impossible" in most cases, unless we are misreading the documentation. Swapping the CPU might only make things worse. From SRA at XX.LCS.MIT.EDU Mon Oct 24 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Mon 24 Oct 88, 00:00 Subject: No subject In-Reply-To: <470732.881024.ZVONA@AI.AI.MIT.EDU> Message-ID: <12441042264.12.SRA@XX.LCS.MIT.EDU> Date: Mon, 24 Oct 88 14:46:59 EDT From: David Chapman MC wasn't talking to the net for 34 hours because people kept booting it without fixing the IMP problem. I left a note on the console explaining how to win. As a result, LISTS MSGS is over 2000 blocks again. For what it's worth, I'm in favor of an immediate CPU swap. Since BBN has admitted that at least some of this is their fault (IMP software), a CPU swap wouldn't solve the urgent problem. The problem with swapping CPUs to "fix" the PAR ERR bug is that it would not solve the real problem (one of the KS CPUs being broken) but would remove the immediate cause for fixing the real problem. Sad but true. ------- From ZVONA at AI.AI.MIT.EDU Mon Oct 24 19:46:59 1988 From: ZVONA at AI.AI.MIT.EDU (David Chapman) Date: Oct 24 88 14:46:59 EDT Subject: No subject Message-ID: <470732.881024.ZVONA@AI.AI.MIT.EDU> MC wasn't talking to the net for 34 hours because people kept booting it without fixing the IMP problem. I left a note on the console explaining how to win. As a result, LISTS MSGS is over 2000 blocks again. For what it's worth, I'm in favor of an immediate CPU swap. From Moon at STONY-BROOK.SCRC.Symbolics.COM Sat Oct 22 01:28:00 1988 From: Moon at STONY-BROOK.SCRC.Symbolics.COM (David A. Moon) Date: Oct 21 88 20:28 EDT Subject: No subject In-Reply-To: <469253.881021.ZVONA@AI.AI.MIT.EDU> Message-ID: <19881022002858.8.MOON@EUPHRATES.SCRC.Symbolics.COM> Date: Fri, 21 Oct 88 16:05:33 EDT From: David Chapman MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.) Push the boot button on the front of the IMP (maybe it's labelled Reset). Then wait an hour. From CENT at AI.AI.MIT.EDU Fri Oct 21 22:20:59 1988 From: CENT at AI.AI.MIT.EDU (Pandora B. Berman) Date: Oct 21 88 17:20:59 EDT Subject: No subject Message-ID: <469383.881021.CENT@AI.AI.MIT.EDU> Date: Fri, 21 Oct 88 16:05:33 EDT From: David Chapman To: BUG-ITS at AI.AI.MIT.EDU MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.) i looked at the LH/DH lights, decided they indicated IMP wedgitude, and called the NOC, after Ty checked and found that XX (@ 0/44) was having no problems. the nice man (norm, i think he said) there put 3/44 into and out of loopback, and then once i ran NET in LOCK to impulse MC, we had arpanet again. the guy at BBN claimed that we are not the only people having this problem, that it seems to be cropping up in several places all over, and that it appears therefore to be software. i gather They Are Working On It. i gave him MAP's name as the official administrator here. he said that the next the this happens, we should try to call as soon as possible so they can try to catch it before it reaches the steady-state wedgedness, and thus perhaps learn something. the NOC is at 873-3070. From ZVONA at AI.AI.MIT.EDU Fri Oct 21 21:05:33 1988 From: ZVONA at AI.AI.MIT.EDU (David Chapman) Date: Oct 21 88 16:05:33 EDT Subject: No subject Message-ID: <469253.881021.ZVONA@AI.AI.MIT.EDU> MC isn't talking to the arpanet. Powercycling doesn't help. I gather this means I need to boot the IMP. I dunno how. Can someone show me? (I can't find anyone around now.) From CENT at AI.AI.MIT.EDU Fri Oct 21 03:42:07 1988 From: CENT at AI.AI.MIT.EDU (Pandora B. Berman) Date: Oct 20 88 22:42:07 EDT Subject: state of ML Message-ID: <468866.881020.CENT@AI.AI.MIT.EDU> alan said that last week he had you generate a repair PO for ML's disk drive, which was broken. when he called DEC back on sunday to complain that they had in fact not fixed the disk, he got the impression that DEC thought that last week's PO had been closed already. as of now, DEC is -still- working on that disk, and the latest notes they left to each other do not boost my confidence, as they suggest that in trying to use MD to help fix ML's disk, they broke MD's disk as well. if at some point they actually fix these things so they are really fixed, they may want another PO for the work this week. in which case we get to generate another repair PO. alan is on vacation and will return sometime next week; if this needs to be acted upon before then, i'll do it. note that AI should not be charged for any work to fix MD, which is LCS, and it's my guess that LCS shouldn't be charged for fixing MD either, since the Men From DEC say -they- broke it. From CSTACY at AI.AI.MIT.EDU Tue Oct 18 07:18:43 1988 From: CSTACY at AI.AI.MIT.EDU (Christopher C. Stacy) Date: Oct 18 88 02:18:43 EDT Subject: No subject Message-ID: <465449.881018.CSTACY@AI.AI.MIT.EDU> Someone seems to have deleted the default DDT init file from AI's USERSn directories. So I put them back. From CENT at AI.AI.MIT.EDU Tue Oct 18 06:12:33 1988 From: CENT at AI.AI.MIT.EDU (Pandora B. Berman) Date: Oct 18 88 01:12:33 EDT Subject: mc fall down go boom again Message-ID: <465405.881018.CENT@AI.AI.MIT.EDU> it crashed again, after alan had gone home. so i trucked upstairs to discover the same old bogus ?PAR ERR msg. i read the lights off the ACC box over the phone to alan, and he claims that the way the second row did not clear indicates that the problem has not been solved by swapping LH/DHs. in other words, the LH/DHs are not at fault. MC is currently up but not talking to the arpanet. From Alan at AI.AI.MIT.EDU Tue Oct 18 04:28:00 1988 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Oct 17 88 23:28 EDT Subject: Vacation. Message-ID: <19881018032823.2.ALAN@OTIS.AI.MIT.EDU> Due to the lossage with MC, there are a few things that I have done that you might all need to know about. Especially since I'll be out of town this from this Wednesday through next Monday. 1. I have swapped AI and MC's LH/DH-11s to see if this has any effect on the problem with the MC's IMP port. 2. I have left COMSAT on MC running in hyper-active mode. That is, I have patched all of its timeouts to very small values. This makes COMSAT eat new mail faster, so that people who haven't been able to talk to MC for days have a better chance of delivering new mail before timing out. Of course the flip side of this is that MC is growing a rather large queue of mail it hasn't been able to deliver. The COMSAT PDUMP file (COMSAT LAUNCH) has the fast timeouts, but the SBLK file (COMSAT IV) does not. So if it becomes necessary to undo what I have done, you should: [a] notice that the files on .MAIL. are all links to the corresponding files on .BULK., [b] load .BULK.;COMSAT IV into a job (J$J $L .BULK.;COMSAT IV), [c] start it at PURIFY (PURIFY$G), and [d] put the resulting PDUMP file into .BULK.;COMSAT LAUNCH (which is -not- the default you will be offered! Use delete, or type $ to change the offered default.). 3. I have changed the algorithm employed by the SMTP and Chaos MAIL servers to decide whether or not to accept new MAIL > files. The previous code tried to limit the number of MAIL files to 30. The new code looks at the .MAIL. directory and computes how full it is and refuses new MAIL > files if it is more than 75% full. If this has any bad effects, you can retract it by renaming DEVICE;CHAOS OMAIL to be DEVICE;CHAOS MAIL and renaming SYSBIN;FTPS OBIN to be SYSBIN;FTPS BIN. From geoff at Fernwood.MPK.CA.US Thu Oct 6 18:24:05 1988 From: geoff at Fernwood.MPK.CA.US (the tty of Geoff Goodfellow) Date: Oct 6 88 09:24:05 PST Subject: License plate curiosity... In-Reply-To: Your message of Wed 5 Oct 88 17:27:28-PDTFrom: Vince Fuller Message-ID: <8810060924.2.UUL1.3#948@Fernwood.MPK.CA.US> i still have California JFCL. i believe JRST 4 belongs to Ken Olum (kdo at lucid.com). g From barmar at Think.COM Thu Oct 6 17:01:00 1988 From: barmar at Think.COM (Barry Margolin) Date: Oct 6 88 12:01 EDT Subject: License plate curiosity... In-Reply-To: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM> Message-ID: <19881006160115.7.BARMAR@OCCAM.THINK.COM> A couple of weeks ago I was walking through the Lotus parking lot by Cambridge Gas & Electric and saw the license plate CAR-CDR. Anyone know whose this is? barmar From Ed at ALDERAAN.SCRC.Symbolics.COM Thu Oct 6 15:42:00 1988 From: Ed at ALDERAAN.SCRC.Symbolics.COM (Ed Schwalenberg) Date: Oct 6 88 10:42 EDT Subject: License plate curiosity... In-Reply-To: <12436116360.19.VAF@Score.Stanford.EDU> Message-ID: <19881006144203.6.ED@BLACK-BIRD.SCRC.Symbolics.COM> Date: Wed 5 Oct 88 17:27:28-PDT From: Vince Fuller The other day I saw a California licence plate that read "JRST 4" (I guess you can't get commas on licence plates...). Out of curiosity, who is the owner of this plate? --Vince ------- Hmm. I thought this was Geoff Goodfellow's, but SAIL:AIWORD.RF[UP,DOC] tells me he has JFCL. HIC got Massachusetts HLRZ (the PDP-10 instruction that implements the "car" operation of Lisp); I believe this vehicle and plate is still around in the possession of PGS. I had FOOBAR in Nevada and later in Massachusetts; I still have the physical plates from Nevada, though the vehicle which wore both sets is long since deceased. There used to be a rather extensive discussion of this stuff in the jargon file(s), but it seems to have evaporated, except for the single note about JFCL. From VAF at Score.Stanford.EDU Wed Oct 5 00:00:00 1988 From: VAF at Score.Stanford.EDU (Vince Fuller) Date: Wed 5 Oct 88, 00:00 Subject: License plate curiosity... Message-ID: <12436116360.19.VAF@Score.Stanford.EDU> The other day I saw a California licence plate that read "JRST 4" (I guess you can't get commas on licence plates...). Out of curiosity, who is the owner of this plate? --Vince ------- From SRA at AI.AI.MIT.EDU Wed Oct 5 19:23:26 1988 From: SRA at AI.AI.MIT.EDU (Rob Austein) Date: Wed, 5 Oct 88 14:23:26 EDT Subject: TCP/IP ior IMP weirdness Message-ID: <457481.881005.SRA@AI.AI.MIT.EDU> I got a call from BBN asking me to check out MC because they said it had first crashed then started spitting garbage onto its IMP (sic). The call was to tell me that until they hear further from us they will leave MC's port in loopback mode to keep from trashing the rest of the net. I found MC crashed with several messages from last night about the IMP crashing and the IMP interface being reset followed by: IMP: Interface reset PK: Node already on list and a PI 7 BUGHALT. There were no times on the last two message. Dump in CRASH; TCP.PK BUGHLT. Reloaded ok except that now it can't talk to the net, presumably because BBN still has the IMP in loopback. I'm going to try to get them to undo that now.... From ROLL%SESTAK.BITNET at MITVMA.MIT.EDU Mon Oct 3 20:12:22 1988 From: ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) Date: Mon, 3 Oct 88 20:12:22 +0100 Subject: subnet 6 Message-ID: <340A6Z@KICKI.STACKEN.KTH.SE> It might be so that, I did something wrong when we took away MX, i unplugged the transceivers, both where the KL was, and next to the chaos-11 3mbit ethernet gateway was. I don't knew if anyone has checked it out after that. From SRA at XX.LCS.MIT.EDU Mon Oct 3 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Mon 3 Oct 88, 00:00 Subject: Chaosnet, hardware In-Reply-To: Message-ID: <12435525680.49.SRA@XX.LCS.MIT.EDU> If I remember correctly, Moon's original CHAOSNET spec paper did specify a length limit derived from transmission speed and the retransmission algorithm. I haven't read the paper in a long time, so I can't quote chapter and verse. ------- From SRA at XX.LCS.MIT.EDU Mon Oct 3 00:00:00 1988 From: SRA at XX.LCS.MIT.EDU (Rob Austein) Date: Mon 3 Oct 88, 00:00 Subject: Agre's dropped tty problems In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu> Message-ID: <12435522000.49.SRA@XX.LCS.MIT.EDU> Or maybe it's just that the path from anywhere to subnet 6 is unreliable these days and sometimes the routing transients cause your packets to fall on the floor so that either ITS or your Lispm thinks the connection is dead. ------- From Gumby at MCC.COM Mon Oct 3 05:50:00 1988 From: Gumby at MCC.COM (David Vinayak Wallace) Date: Oct 2 88 23:50 CDT Subject: Chaosnet, hardware In-Reply-To: Message-ID: <881002235013.7.GUMBY@BRAHMA.ACA.MCC.COM> Date: Sun, 2 Oct 1988 18:33 EDT From: JTW at XX.LCS.MIT.EDU Presumably the limit is due to propagation delays screwing up the collision detection, rather than analog attenuation issues. This being the case, it should be pretty easy to calculate once you figure out exactly what a collision is. As a practical matter our subnet 1 was well over 500m at its peak, I think. The Chaosnet Memo said that the limit was around 1KM for the reason you said. From CSTACY at AI.AI.MIT.EDU Mon Oct 3 02:58:54 1988 From: CSTACY at AI.AI.MIT.EDU (Christopher C. Stacy) Date: Sun, 2 Oct 88 21:58:54 EDT Subject: dropping Message-ID: <455274.881002.CSTACY@AI.AI.MIT.EDU> The 7814 modem randomly dropped me a second ago; when I dialed it back up again, I was on the same session as before (I wasn't logged out.) There seemed to be alot of pinegoi&6se on the line too. From JTW at XX.LCS.MIT.EDU Sun Oct 2 23:33:00 1988 From: JTW at XX.LCS.MIT.EDU (JTW at XX.LCS.MIT.EDU) Date: Oct 2 1988 18:33 EDT Subject: Chaosnet, hardware In-Reply-To: Msg of Sun 2 Oct 88 17:14:21 +0100 from ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) Message-ID: From: ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) Re: Chaosnet, hardware What is the electrical characteristics? 75 Ohm coax. Traditionally, solid-sheath CATV cable was used for its low-loss and shielding properties, but more recently most short runs were done with boring old RG-59U, which seems to work fine. Termination is just a 75-ohm non-inductive resistor on each end. I've never seen any commentary on theoretical length limits, but perhaps someone who was around when it was designed will have more to say. Presumably the limit is due to propagation delays screwing up the collision detection, rather than analog attenuation issues. This being the case, it should be pretty easy to calculate once you figure out exactly what a collision is. As a practical matter our subnet 1 was well over 500m at its peak, I think. From ROLL%SESTAK.BITNET at MITVMA.MIT.EDU Sun Oct 2 17:14:21 1988 From: ROLL%SESTAK.BITNET at MITVMA.MIT.EDU (Peter Lothberg) Date: Sun, 2 Oct 88 17:14:21 +0100 Subject: Chaosnet, hardware Message-ID: <5401T5@KICKI.STACKEN.KTH.SE> What is the electrical characteristics? Cable impendance? Maximal cable lenght? Terminators? From Gumby at MCC.COM Sat Oct 1 03:58:00 1988 From: Gumby at MCC.COM (David Vinayak Wallace) Date: Sep 30 88 21:58 CDT Subject: foo In-Reply-To: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU> Message-ID: <880930215803.1.GUMBY@BRAHMA.ACA.MCC.COM> Date: Fri, 30 Sep 88 21:37 EDT From: Alan Bawden (It is a weird phenomenon that people always blame the machine at the farthest end of a network connection first. I've seen people go and boot AI because their terminal concentrator crashed.) Yea, I once booted XX because the IRS lost my tax rebate From agre at wheaties.ai.mit.edu Sat Oct 1 02:56:44 1988 From: agre at wheaties.ai.mit.edu (Philip E. Agre) Date: Sep 30 88 21:56:44 EDT Subject: foo Message-ID: <8810010156.AA16581@wheat-chex.ai.mit.edu> That's probably because networks are supposed to be transparent. Even when they break it doesn't immediately come to mind that they even exist. But then people don't usually clean off the world when their glasses get dirty. From Alan at AI.AI.MIT.EDU Sat Oct 1 02:37:00 1988 From: Alan at AI.AI.MIT.EDU (Alan Bawden) Date: Sep 30 88 21:37 EDT Subject: foo In-Reply-To: <8810010048.AA15907@wheat-chex.ai.mit.edu> Message-ID: <19881001013734.1.ALAN@PIGPEN.AI.MIT.EDU> Date: Fri, 30 Sep 88 20:48:48 EDT From: agre at wheaties.ai.mit.edu (Philip E. Agre) I talked with Alan about the problem a little and he thinks that AI is losing all its Chaos connections now and again. That's not quite what I said. I think that it is the Chaosnet itself that is the problem (probably subnet 6 being jammed). The problem is not AI or ITS. (It is a weird phenomenon that people always blame the machine at the farthest end of a network connection first. I've seen people go and boot AI because their terminal concentrator crashed.) From agre at wheaties.ai.mit.edu Sat Oct 1 01:48:48 1988 From: agre at wheaties.ai.mit.edu (Philip E. Agre) Date: Sep 30 88 20:48:48 EDT Subject: foo Message-ID: <8810010048.AA15907@wheat-chex.ai.mit.edu> >From agre Fri Sep 30 20:47:14 1988 Return-Path: Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT Date: Sep 30 88 20:46:33 EDT From: MAILER-DAEMON at wheaties.ai.mit.edu (Mail Delivery Subsystem) Subject: Returned mail: User unknown Message-Id: <8810010046.AB15897 at wheat-chex.ai.mit.edu> To: agre Status: R ----- Transcript of session follows ----- 550 bug-its... User unknown ----- Unsent message follows ----- Return-Path: Received: by wheat-chex.ai.mit.edu; Fri, 30 Sep 88 20:46:33 EDT Date: Sep 30 88 20:46:33 EDT From: agre at wheaties.ai.mit.edu (Philip E. Agre) Message-Id: <8810010046.AA15894 at wheat-chex.ai.mit.edu> To: Gumby at mcc.com Subject: Re: connectionist problems Cc: bug-its 1. I am connecting through a telnet window on my lispm. 2. No, nothing about DDT BUG BLAH BLAH 3. I've never had my connection dropped while running any program but DDT. 4. Ditto. 5. Yes, my memory is quite consistent with the policy (which Alan told me about) of flushing over-an-hour-old detached jobs. I talked with Alan about the problem a little and he thinks that AI is losing all its Chaos connections now and again. From Gumby at MCC.COM Sat Oct 1 00:01:00 1988 From: Gumby at MCC.COM (David Vinayak Wallace) Date: Sep 30 88 18:01 CDT Subject: connectionist problems In-Reply-To: <453833.880930.AGRE@AI.AI.MIT.EDU> Message-ID: <880930180110.0.GUMBY@BRAHMA.ACA.MCC.COM> Date: Fri, 30 Sep 88 15:39:01 EDT From: "Philip E. Agre" Hi -- AI randomly drops my terminal connection a couple dozen times a day. In doing so it sometimes detaches me and sometimes flushes me altogether. Am I doing something to bring this on myself? If not it would be great if it stopped happening. o - Are you connecting from a terminal concentrator? If not, how? o - When you reconnect, do you get some message from ITS like "DDT BUG BLAH BLAH?" o - When you reconnect are you talking to DDT or to the program you were running when the connexion was dropped? o - Does this only happen when you're running some particular program? o - When "it sometimes detaches me and sometimes flushes me altogether" does it appear that you're logged out only if you wait a while? ITS's default behaviour is to keep jobs around if the connection is accidentally dropped, then GC them after a while if you don't reconnect. "We need BITS, nothing but BITS" -- Chuck E. Dickens.