:: 29-Nov-1998 22:52 (Sunday) ::

The RC5 keyrate plots at http://www.distributed.net/statistics/ and
http://www.distributed.net/statistics/rc5-64/ now have regression
lines plotted.

The regressions are for both linear and exponential growth using
daily block counts from 2 March 1998 to the last stats run and
exclude DES-II contests and various outliers.

:: 28-Nov-1998 22:08 (Saturday) ::

Ok, I finally got the requirements for the web site translation tool laid out…
you can see it at http://www.distributed.net/~decibel/trans-tool.html

:: 27-Nov-1998 01:55 (Friday) ::

Did some investigation of integer bit-slice last night and it looks
like it is a no win over BrydDES. Based on clock counts from
s-boxes 1 and 4 it would be 5% faster if hand assembly can do 10%
better than an optimized compile under DJGPP.

For integer work it looks like it is best to concentrate on BrydDES
for now. First step is to figure out how it works.

On the MMX front, here is how I come up with a possible 50% improvement.

On a P5 MMX, the s-boxes average 45 clocks per box. There are 8 boxes
per round and an equivalent of 9.348 (of 16) rounds done for each
“slice” of 64 keys.

To those 45 clocks must be added some setup (basically a = e ^ k)
and cleanup which amount to 16 clocks if they can’t be paired. As
these are all loads and stores they are all U pipe and will not pair
unless the s-boxes are rewritten to accommodate it.

So we have a clock count per key of (45 + 16) * 8 * 9.348 / 64 = 71.28.

At 200MHz this gives 2806 kkeys/s. We currently get 1876 kkeys/s.
2806/1876 = 1.50. Q.E.D.

If the s-boxes can be re-written it might go as high as 60%, assuming
half of those 16 instructions pair.

This all relates to the P5 MMX as the clock counts are deterministic.
On the out of order processors (PPro, PII, K6 and K6-2) the
improvement may vary.

:: 26-Nov-1998 02:52 (Thursday) ::

The distributed.net .plans are now provided via email daily at 0000 UTC.
Cool, eh?

To subscribe to the mailing list, send a message to
majordomo@lists.distributed.net with the body ‘subscribe plans ‘
followed by your address.

There may be a few bugs in the first day or so, but I’m sure I’ll be
able to work them out. Cough.

:: 25-Nov-1998 15:03 (Wednesday) ::

Since the last exciting installment:

Vetere mentioned that the 412e client has been released. If you have a 68k or an
upgraded 601, or a hankering for the buffer bars to be appearance compliant, go
snatch it (see his .plan for details). In other news, the new MacOS Client coding
is benefiting from Peter DiCamillo and most of the rest of us having several days
off from school/work for Thanksgiving.

:: 23-Nov-1998 21:44 (Monday) ::

The MacOS 412e clients have been placed in the pre-release directory on
ftp.distributed.net. In all likelihood, they will -never- be released.
We expect the 420 MacOS build to be complete near what would be the
release date of the 412e clients (one week from today)… two releases
in a row may prove confusion.

So, if you’re astute enough to be a .plan-reader, you’ll have a MacOS
client that’s got cosmetic fixes, a G3 Upgrade Card detection bugfixes,
and that only a few other people have.

Again, for clarity’s sake: these are -prerelease- clients. Do not
redistribute them.

o ftp://ftp.distributed.net/pub/dcti/pre-release/

:: 23-Nov-1998 09:26 (Monday) ::

additional work on developmental proxy and current proxy source tree.
fixed possible problem in the key-generation of the developmental
master code that could have caused problems.

added new logic to the automatic client selector (select.cgi) so that
it will suggest alternate platforms if it knows of other “close”
operating systems.

further work on dynamic object code classes, and begun additional work
on both coff and elf object support classes.

rewrote the /webcams/ page to use server-side php instead of
client-side Java-script.

wrote a new single-process, non-forking datapipe that works equally
well on Win32 machines. this will eventually be put in place on the
ftp site in the “unsupported” directory in place of the current
datapipe.c that is there.

:: 22-Nov-1998 16:31 (Sunday) ::

moo. Finally got around to cleaning up cliconfig. What a humdinger. I haven’t
implemented the changes in the problem loader or buffer handler yet, but will
do so later tonight.

-runoffline, -runbuffers, -frequent, -run, -n (blockcount=) are among the
options that have changed meaning or (as is the case with -run) are simply
shorthand combinations of other options.

The changes, from the users perspective, are minor:
a) blockcount can now be -1 which indicates ‘exit when buffers are empty
AND cannot be refilled’. This is similar to the behavior of the old
-runbuffers switch with the exception that it can also be used when
networking *is* enabled. In other words, blockcount=-1 is equivalent to
saying, ‘don’t ever generate random blocks’.
b) -runbuffers is now exactly the same as blockcount=-1. It does not
touch online/off-line mode.
c) -runoffline is now a pure network switch and won’t spontaneously combust
just because runbuffers happens to be on the command line as well.
-runoffline can can now be counterbalanced by -runonline.
d) -frequent has changed only in its description. What ‘frequent’ does is
not go online frequently as it had been previously described, but check
buffers frequently (to ensure that they are never totally empty). This
option is meaningless when running offline.
e) -run is obsolete and implies -runonline and -n 0. As you see, this is
not exactly the same as it was before inasfar as the -n switch is
concerned. However, the *effect* is the same since -run continues to
counterbalance the effect of runoffline=1 and runbuffers=1.

:: 21-Nov-1998 15:44 (Saturday) ::

The self-modifying core is, alas, incredibly slow on a K6 too :
57 kkeys/s instead of 340-350 kkeys/s on a K6/200 :-(

:: 20-Nov-1998 23:28 (Friday) ::

Hi all,

I updated the public source, so that it shouldn’t fail to compile at least.

There’s also a new 486 core. This one features self modifying code, and it’s
approx. 5% faster on my 486 DX4/100 under Linux. With other Intel
processors, this core seems dog slow, I wonder why… I will test this code
with a K6 and a K6-2, and I will post the result in this .plan file.