:: 25-Nov-1999 01:56 (Thursday) ::

Moo. I’ve been making some new progress on the new nodezero server (it’s the
master web/dns/ftp server). Those of you that watch my projects list (and
who doesn’t?) have seen that getting a new nodezero into production is a huge
priority and that I’ve slowly and surely been making progress.

Completed tasks:

– Design hardware specs (Brief: PIII-500, 2x9gig UWSCSI, 256mb sdram, etc)
– Order parts
– Build box
– Install OS (FreeBSD!) and setup minimal services

TODO tasks:
– Setup htdocs stuff in CVS on current n0
– Setup CVS sycning on new n0 for htdocs stuff
– Convert services (bind8, “mirror”, proftpd, qmail, etc.)
– Get nugget/cow to dink with apache/mysql_auth kludge
– Convert users

– Arrange for conversion with VISI
– FedEX box
– Final cutover

– Arrange for CVS server move to nugget’s colo site.

I hope to get through the first set of “still to do” tasks over this long
weekend (The 25th is a United States holiday). I’ll post more updates as
I progress.

Have a good Thanksgiving, folks. Burn, CSC, Burn!

-dbaker

:: 24-Nov-1999 18:22 (Wednesday) ::

Ok more additions to the clients list

– dnetc-netbsd13-x86.tar.gz netbsd 1.3.x for x86 v2.8002.446
– dnetc-win32-x86.exe win32 self installer v2.8002.447

Enjoy!

:: 24-Nov-1999 15:30 (Wednesday) ::

Here’s some more info on what we’re seeing on statbox.

The problem that we’re running into is that as soon as we enable any
httpds, Sybase’s CPU load goes through the roof. With 5 httpds running,
we’re seeing CPU usage of 90% on a dual PII-300. Access to the database
is slow as hell, either from the web or locally.

The interesting thing is that this suddenly started after importing the
04 or 05 rc5 log yesterday. After doing some cleanup, the CSC run last
night was fine until the 07 CSC log, when things ground to a crawl. We
were seeing BCPs of ~50rows/sec, where they’re normally 1000s of
rows/sec.

So, the only theory I can think of is that the database has grown to a
size where we’re suddenly overflowing some cache or memory structure.
Unfortunately, sp_sysmon is of little value because it won’t run except
under the lightest of loads. With anything close to a normal load, it
just sits there, never returning from the call. When we do run it, we’re
seeing rather odd results, such as:

Task Context Switches Due To:
Voluntary Yields 10.0 1809.0 1809 47.3 %
Cache Search Misses 1.0 176.0 176 4.6 %
System Disk Writes 0.0 0.0 0 0.0 %
I/O Pacing 0.0 0.0 0 0.0 %
Logical Lock Contention 0.0 0.0 0 0.0 %
Address Lock Contention 0.0 0.0 0 0.0 %
Log Semaphore Contention 0.0 0.0 0 0.0 %
Group Commit Sleeps 0.0 0.0 0 0.0 %
Last Log Page Writes 0.0 0.0 0 0.0 %
Modify Conflicts 118.4 21323.0 21323 557.9 %
I/O Device Contention 0.0 0.0 0 0.0 %
Network Packet Received 1.5 265.0 265 6.9 %
Network Packet Sent 2.4 439.0 439 11.5 %
SYSINDEXES Lookup 0.0 6.0 6 0.2 %
Other Causes -112.1 -20196.0 -20196 -528 %

:: 24-Nov-1999 06:29 (Wednesday) ::

Yes i know i just updated a few clients, but here are a few more
updates.

For those of you who wanted the cow back in the win32 client, well its
back!

The following clients have been updated

– dnetc-win32-x86.zip
– dnetc-freebsd-x86-elf.tar.gz

The win32 self-installer will be uploaded shortly

So happy down loading

:: 24-Nov-1999 04:32 (Wednesday) ::

Well, statsbox is still extremely unhealthy. We’re seeing some very strange
behavior in Sybase, with cpu utilization far in excess of what we should be
seeing. Decibel and I are both at a loss as to the cause of the problem.

I guess at this point we’re seeking some peer review on the problem.
If you have practical experience in Sybase database administration and
transact-sql coding, please drop me a line. We’d like a few more sets
of eyes to take a look at this situation. I suspect mssql 6.5 experience
would be equally valuable.

We’ve gotten to the point where we’re not even sure if we can trust what’s
coming out of sp_sysmon.

:: 24-Nov-1999 03:23 (Wednesday) ::

k news on several clients that have been updated lately.

The following clients can be found at the clients page.
http://www.distributed.net/clients.html

-dnetc-linux-alpha-glibc21.tar.gz
-dnetc-linux-alpha-glibc2.tar.gz
-dnetc-netbsd-x86.tar.gz
-dnetc-netbsd-arm32.tar.gz
-dnetc-netbsd-alpha.tar.gz

These clients along with clients updated on Nov/16/1999 all support
CSC. For more information on CSC please visit
http://www.distributed.net/csc/

Have Fun!

:: 24-Nov-1999 03:20 (Wednesday) ::

The following is a development bitslicing AltiVec G4 core.

Benchmarking CSC … 100.00% done
Completed in 0.00:00:16.30 [2,251,498.52 keys/sec]

:: 24-Nov-1999 01:24 (Wednesday) ::

Well, there she be – the new design for the web site.

A total content rewrite and reorganization is coming. Stay tuned. But
this is the look. I’m still weeding out some bugs in the new display,
and the other languages will be switched over as the sidebars are
constructed in native tongues…

Send flames, criticism, and commentary to vetere@distributed.net .

:: 23-Nov-1999 15:37 (Tuesday) ::

The 21-Nov RC5 stats run is about half-way through, and after this will
come the 22-Nov RC5 run. CSC stats are current and accurate, it’s just
RC5 that is affected at this point.

The trouble stems from the fact that (as decibel mentioned last night)
the box has developed an annoying habit. If apache is on and serving
requests, the stats run completely halts. If I turn off apache, it
runs full speed. So, in the interests of wrapping up the late runs, I’ve
got apache turned off.

(Hey, if nothing else, it’s been a good opportunity to upgrade to the
most current apache and php releases)

Once the 21-Nov update wraps up, I think I’ll reboot the box, although
I dunno what I expect that to accomplish. Can’t hurt, I suppose.

More details as the situation progresses.

:: 23-Nov-1999 06:13 (Tuesday) ::

Well, bad news…. statsbox is looking rather unhealthy. It started acting
a little flaky during the CSC run, then when it hit the -04 logfile during
the rc5 run, it ground to a halt. Nugget shut down apache, and all was good
again.

Then, we discovered that it’s going to end up importing 2 of today’s (Nov. 23)
logfiles. This is bad.

Neither of us is going to stay up to babysit the run (damn day-jobs!), so we’ll
have to deal with it tommorow.

The box is also acting rather unhealthy again, so there’s probably something
funny going on… we’ll keep everyone informed as we know more.

Sorry for all the hassles.