Tue Oct 28 21:51:23 PST 1997 — We had some problems with busy signals this evening, and are working to fix the problem. When it was happening, we found a few people with multiple dialup connections and some that had been online for longer than most people are awake each day, and we’ve removed them. Tomorrow PacBell will be here to install 64 new lines, and equipment is also on the way, so we should be okay in the near future. In addition, we’ve got 96 out of 128 ports of the X2 group with some sort of problem in the modem – eg, and 16 port modem will have 2 or 4 bad ports. USR has shipped us replacements, and so far four in a row have had similar problems, so we haven’t been able to get them online. Brian has been working on this all day both Monday and Tuesday. This is diminishing the capacity of our hunt group overall by about 16 lines. It’s possible for users to experience a fast busy or reorder tone even when lines are available if they use caller ID blocking. Currently some of our equipment is refusing calls from ID blocked originators. If you hear a fast busy, add ‘*82,’ to the beginning of the telephone number you are dialing for Sonic to turn off caller ID blocking for that call. -Dane

Sun Oct 26 17:51:24 PST 1997 — Thunder’s kernel has been modified for dual CPU operation, and the new 100Mbps Ethernet card driver is online and running in full duplex mode. This means we’re ready for a test data copy of the web directories over to the NetApp. Once we’ve got a handle on how long it will take, we’ll schedule the real deployment, probably Tuesday or Wednesday early morning. The reason for testing copy time is that Thunder’s filesystem must be mounted read-only during this time so that users don’t change their pages. If a change was made during the copy, it wouldn’t get moved to the new filer. Meanwhile, as Thunder now has twice as much CPU to work with and has been quite stable since the upgrade, I’m trying to generate an ht://Dig index. Scott setup the kernel stuff for dual CPU and for the 100Mbps networking, and he’s posted something about full duplex Ethernet to the news:sonic.net newsgroup. -Dane and Scott

Fri Oct 24 11:53:50 PDT 1997 — I’m pleased to report that Ultra’s transition to 100Mbps full duplex Ethernet went quite well, and news is now running at this speed. The networking on this motherboard is an Intel EtherExpress Pro 100, aka the ‘Speedo’ chip. This on board fast Ethernet is the same as the one on Thunder’s new motherboard, and we’ll be working on Thunder next. For those who have an interest in the full duplex aspects of this, I’ll make a post about CSMA/CD networks on news:sonic.net shortly.

Fri Oct 24 07:55:12 PDT 1997 — We’ve been working on upgrades of Thunder and Ultra this morning, so you may have noticed a bit of downtime in the early AM. Thunder’s large disk array was inconsistent, so currently Thunder is doing a filesystem check and is mounted read-only. Users cannot maintain their webspace until this is complete, and some web tools and cgi programs will not function because they cannot write to the disk. This should be complete shortly.

Thunder did get moved into a new chassis, and has had a motherboard upgrade. The new board has more cache per CPU, and that’s active now, but the SMP (dual CPU) support is not turned on, as we need to build a new kernel. During that reboot we’ll also be turning on the rest of the memory, going from 128M to 256M of ECC EDO RAM. We will also be working on Ultra’s on board 100Mbps full duplex Ethernet adapter today. If that works well, we’ll do the same on Thunder. Next will be a test copy of Thunder’s RAID array to the NetApp filer, and then deployment to the NetApp. -Dane and Scott

Fri Oct 24 17:54:15 PDT 1997 — Thunder now recognizes 256M of ECC EDO RAM, and it’s humming along quite nicely. Unfortunatly, the SMP dual CPU support hung on boot, and we’ll need to work on that and the networking further. I suspect Scott will probably work on this in the early morning hours this weekend. -Dane

Tue Oct 21 11:58:32 PDT 1997 — Maintenance is scheduled for Wednesday morning between 1am and 6am. We’ve solved the problem with Thunder’s (www) new motherboard, and we will be finishing that upgrade. This gets us twice as much CPU power, four times as much on-chip cache and twice as much memory. In addition, the new motherboard has 100Mbps Ethernet on board, and as our network is switched, we can run that at 200Mbps full duplex. This enables the deployment of the NetApp NFS filer for web storage. In addition, we will be doing further upgrades on Ultra (news) including a BIOS update and faster networking. -Dane

Mon Oct 20 11:19:31 PDT 1997 — Ultra’s huge RAID disk array became inconsistent during a reboot this morning, and was offline for a filesystem check. As it’s very large, this took a little while, and during this time, Usenet news was unavailable. -Dane

Mon Oct 20 09:03:23 PDT 1997 — Ultra’s huge RAID disk array became inconsistent during a reboot this morning, and is currently offline for a filesystem check. As it’s very large, this may take a little while, and during this time, Usenet news is unavailable. We’ll get it back online just as soon as we can. -Dane

Mon Oct 20 08:52:35 PDT 1997 — Brian and I have just finished a set of upgrades and fixes. Some services were offline between 2:30am and 7am. Notably, web services were offline from 3am to 6am. The FTP server’s filesystems were available for read only use between 2:30 and 4am, and at the end of this time, we put the NetApp filer online for ftp. All terminal servers got a RAM upgrade between 6am and 7am. This will fix short memory problems which were causing inconsistent connection performance last week. Unfortunately, due to problems with the new motherboard, Thunder’s CPUs, RAM and networking were not upgraded, and we were unable to move the filesystems to the NetApp. This was a major goal of this maintenance, and we’ll be doing some preparation today in hopes of trying again tomorrow. -Dane & Brian

Fri Oct 17 12:01:08 PDT 1997 — We recently upgraded all of our Livingston terminal servers to a new OS version, 3.7. This version fixes quite a few problems which we were having, and it’s been quite stable. Unfortunately, it uses a bit more RAM than the old version, and many of the terminal servers need to be upgraded. The RAM is here, but the devices are always in use, so it’s difficult to schedule the work. This became a problem this morning when two of the devices (out of 18) ran short on memory and started behaving erraticly. We have rebooted them, and things look much better now. Observed behavior included failure to authenticate users, termination of connections and slow performance. The affected devices were pm2.sonic.net and pm4.sonic.net. -Dane