Lack of RC5-64 stats...

[BGod]

decibel
:: 11-Apr-2002 23:31 CDT (Thursday) ::
As dbaker mentioned in his .plan
(http://n0cgi.distributed.net/cgi/dnet-finger.cgi?user=dbaker), the master will
be down for the next 18 hours or so. Since the log files are on the master,
this also means that we won't be catching up on the stats backlog while the
master is down.

As for the backlog, I've been working on some changes to the stats code
the past few days trying to eliminate situations that could cause stats
inconsistencies. Unfortunately, the new code has introduced some problems of
it's own, so I've been in the process of slowly debugging things. Hopefully
things will be stabilizing over the next few days.

dbaker
:: 12-Apr-2002 00:12 GMT (Friday) ::
Greetings, folks.

The master server will be offline for much of tonight and tomorrow morning
while it is couriered by FedEx Express to one of our new colo facilities.

I appreciate all the colo offers that I have received. I am splitting up our
network a bit and this is just one of our new homes. For those of you that have
offered space and haven't heard back from me, I apologize for the delay. Moving
the master has been priority one and then I will work on moving the rest of the
equipment. I'm still interested in the offers that I received and plan to make
use of at least one, if not two, of them.

I currently have no plan to bring up a secondary master during the down time .
As a result, the proxy network will back up a bit and stats will be delayed We.
will catch up the network and the stats server within a day or so .

The master will be taken down at approximately 20:00CDT (01:00UTC) to prepare
it for shipment. Unfortunately, in AUS, the last FedEx Express drop-off time is
at 21:00CDT. We expect the equipment to be back online at the new colo facility
by about 15:00EDT (19:00UTC) That ultimately leaves us with about 18 hours of
down time.

This should be the new permanent home of the master server for many years to
come. Thanks to everyone who has contributed to pulling this off.

Cheers.

 

[GeoffS]

:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|
:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|:|

 

[bphantom]

That's nothing.... Right now TA is surviving on it's own round robin pproxies, because mine is out. My pproxy (TA master pproxy) cannot connect to any of the D.NET round robin pproxies. And their proxyinfo page is offline, so I can't try other possible candidate's. 🙁 This is turning ugly.

Brad..

 

[GeoffS]

ACK! If TA goes dry, I have enough to last until about Monday night.. then I'm out too! :| I guess I'll have to find other things for those machines to do if it comes to that! :|

Geoff

 

[Poof]

Uh ohh... I have my own pproxy but I better check to see how many blocks it has left. :Q It's NOT a good time to be crunching randoms considering that a significant portion of the keyspace has already been checked. 🙁

 

[bphantom]

It isn't pretty... One of the D.Net full proxy operators told me to try his server (had a few hundred thousand blocks remaining). In the few minutes it took to get into his pproxy, all of his blocks had been extinguished. Ugg, this is nasty. If I am unable to download blocks in the next little bit, I may block access to port 2064. Considering it is creating mass connection attempts to the pproxy, for blocks it simply doesn't have. 🙁 The block will automatically be removed if it detects incoming blocks from D.Net (gotta love Linux and shell scripting).

Brad..

 

[vss1980]

Actually you are more likely to find the right key crunching randoms now than say at the start of the contest. Why? Because the client only cracks random blocks from slices in the keyspace picked by the master server and I'm assuming (yeah yeah, I know assumption is the mother of all f***-ups) that d.net will only nominate a slice in the keys that still hasn't been fully checked.

Of course, random's are still bad as they are more likely to be duplicate blocks that have already been submitted (see here).

Moral of the story is to set your client to TA-Cube's proxy and run it dry 😛 to allow others to match key-rate. (j/k)

 

[RaySun2Be]

That sucks. 🙁

On a side note, I fired up an old 233mhz PC running NT4.0 that was used for development a long time ago, and when I checked the services running, guess what I found? Yep, DNETC.EXE. It looks like I had flushed all the completed blocks, but didn't uninstall the client back in July of last year prior to our move to the new office, according to the log file. It was getting a whopping ~495KKeys per second.

🙂

 

[bphantom]

Well I have a temp solution in place. So any team member connecting to the TA RR pproxies or Core will get feed. Then hopefully within a couple hours, the master keyserver will be back online (about 19:00 UTC).

Brad..

 

[burnedout]

Thanks for the information bphantom. I was able to update about 20% of my herd (Dual 1 GHz PIII and Dual 533 Celeron).

All the others out there are on their own for now.

 

[BGod]

Now I'm starting to remember why I set my pProxy thresholds so high. My nine home machines are buffered with eleven days worth of work. If things really get ugly I'll see if I can punch a hole in my firewall and share.

 

[LANMAN]

Sure glad I filled my proxy last week! That won't last long though, it's already at 80,000 with 120,000 in the in-box.

I hope they get everything up and running or I'll be crunching randoms soon too! :|

I can't believe their doing something like this with almost 75% of the keyspace almost completed. Let's hope they have good insurance since this they used FedEx and it doesn't end up like: Linky

--LANMAN

 

[ViRGE]

Lanman, they don't have an option. Their contract with their previous free provider ended, so they had to move it.😱

 

[bphantom]

Everything is working just fine now. TA keyserver and the RR pproxies maintained blocks from 17:00 UTC yesterday morning until D.Net's keyserver came back up. At about 06:00 UTC this morning, I was able to pull down a little over 250K blocks (feed mine, and the RR's). As of yesterday, the TA keyserver now has a secondary pproxy feeding it. Which gives the TA keyserver 400K blocks, instead of the standard 200K.

Brad..