Team Warped (OS/2)

You may have noticed that some of your graphs on the main team page have not been updated since September 2nd. The official DNET stats server is off line, so Cowboy can’t get your aggregate stats from there. Cowboy spiders the DNET web site to pull out your herd stats there.

As soon as the server is back on line, the top level graphs should start updating again.

Your cow graphs are unaffected by the server outage.

Best regards,

Kevin G. McCoy

I just replaced my wife’s old computer (Baldric) with a new Intel Core 2. Baldric had started to break down and was a bit slow on large graphics jobs. The replacement motherboard/cpu I got her is nothing special, but the graphics card is.

I got her an NVIDIA GeForce GTX-275 graphics card (she is a graphics designer) and installed the DNET CUDA client on her system to crack RC5 keys while the screen saver is running.

Here is a line from the CUDA client log on Timmay, the new computer:

[Jul 10 08:20:58 UTC] RC5-72: Completed CC:28BE14C2:00000000 (62.00 stats units)
0.00:12:50.84 – [345,449,886 keys/s]

This one graphics card is faster than many peoples entire herd output!

I found that if you use the DNET screen saver feature to activate the CUDA client, and let the normal CPU client run as a service, the user does not notice any slowdown of the computer or video.

I will change Samovar’s settings to use a screen saver today, and replace the clunky batch files I am using to turn CUDA on and off.

Happy Saturday!

Kevin G. McCoy

A new beta client with cores optimized for OGR-NG is available at

Distributed.net beta clients

No OS/2 client yet, but many other OSes are covered. Keep checking – OS/2 clients are usually quick to follow windoze and Linux.

I just ran v2.9105.511b on a couple of my machines and the results were impressive. I got 10-15% improvement over the current stable client!

When you install the beta, make sure your DNETC.INI file is not configured to use a specific core. Run the benchmark and it will tell you which of the possible cores is the fastest:


DNETC -bench ogr-ng


Make sure you are not running any CPU hog programs or start up any apps while the benchmark is running.

Different CPUs require different cores for optimum results. Don’t assume a core that is fast on on one of your computers will be the best one for another.

Typically the default core is the fastest. If not, then you might want to configure your INI file to use the core with the fastest benchmark.

Have a good weekend, and for you folks here in the USA – Happy Independence Day!

Best regards,

Kevin

The new DNET CUDA client is really something. Instead of using your CPU to crack RC5 keys, you use your graphics card’s processing power. You might not realize it, but in some respects your graphics card probably has a more powerful CPU than the one on your motherboard.

It only works with recent NVIDIA graphics chip sets, but man, it is really moovin along on my test computer! I have a couple year old NVIDIA GeForce card in this machine, pumping out some excellent key rates:

Projected ideal time to completion: 0.00:53:20.00
[Jan 31 14:28:08 UTC] RC5-72: 4 packets (256.00 stats units) are in
buff-out.r72
[Jan 31 15:22:32 UTC] RC5-72: Completed CB:F75B7435:00000000 (64.00 stats units)
0.00:54:23.00 – [84,240,854 keys/s]
[Jan 31 15:22:32 UTC] RC5-72: Loaded CB:F75B7476:00000000:64*2^32
[Jan 31 15:22:32 UTC] RC5-72: Summary: 17 packets (982.00 stats units)
0.13:35:24.89 – [80.07 Mkeys/s]
[Jan 31 15:22:32 UTC] RC5-72: 0 packets remain in buff-in.r72
[Jan 31 15:22:32 UTC] RC5-72: 5 packets (320.00 stats units) are in
buff-out.r72
[Jan 31 15:22:32 UTC] The keyserver says: “distributed.net / cracking keys in
idle time / many years to go”
[Jan 31 15:22:32 UTC] Refreshed project state data from server. (cached)
[Jan 31 15:22:32 UTC] RC5-72: Retrieved 5 packets (293.00 stats units) from server.
[Jan 31 15:22:33 UTC] RC5-72: Sent 5 packets (320.00 stats units) to server.
[Jan 31 16:16:56 UTC] RC5-72: Completed CB:F75B7476:00000000 (64.00 stats units)
0.00:54:23.29 – [84,233,187 keys/s]
[Jan 31 16:16:56 UTC] RC5-72: Loaded CB:F870A3E6:00000000:49*2^32
[Jan 31 16:16:56 UTC] RC5-72: Summary: 18 packets (1046.00 stats units)
0.14:29:48.18 – [80.33 Mkeys/s]

Newer NVIDIA graphics cards can run circles around my old card, so if you are considering a new system or upgrading your video for gaming purposes, give the NVIDIA cards a look.

The CUDA client needs a special driver loaded on your windows box to allow it to use the graphics card’s many microprocessors to crunch RC5 keys. You can download it for free from the NVIDIA web site.

Unfortunately, the CUDA client can’t crunch OGR work units, but if you are already concentrating on RC5-72, this could substantially increase your work rate. If you are currently doing OGR-NG exclusively, you can help Team Warped on the RC5-72 challenge and not take away from our OGR stats.

I use both the standard DNET client as well as the CUDA client on Samovar, our friendly neighborhood stats server. The two clients can run simultaneously, and since they use separate hardware, each can run full speed – you get the best of both worlds!

The only downside is that the CUDA client makes your graphics card run a bit hot and it vastly slows down the screen drawing speed. If I need to do actual work on Samovar, I have to pause the CUDA client to make the screen usable. I don’t have to pause the standard client, as this one runs at idle priority and is unnoticeable.

The computer screen looks perfectly normal when running CUDA – it just runs really slow.

I made desktop links to a couple of batch files that pause and unpause the CUDA client. That seems to work well for me. Pause; Do some work; Unpause.

The CUDA client really picks up speed if you overclock the graphics card. My graphics card came with a utility that can shift the GPU clock speed and monitor its temperature. My card heats up another 10-12C when running the CUDA client at its top clock speed. This is not too bad, as I have a lot of cooling fans in Samovar’s computer case.

So, if you already have an NVIDIA card or are thinking of upgrading, give the CUDA client try!

Kevin

I notice that some Team Warped members are using old DNET clients that can only handle the old OGR contest. Your cows are not doing any work, but they still communicate with the Cowboy server.

Check your herd stats. If a cow is has a “No Server Comm” error, you may be running an out of date client.

Check your log by clicking on the hostname. If the entries at the bottom of the log say:

v2.9012-497
dnetc v2.9012-497-CTR-05111008 for Win32 (WindowsNT 5.1).
Using email address (distributed.net ID) ‘benji0001verizon.net’
[May 29 20:06:02 UTC] The keyserver says: OGR-P2 is closed.
[May 29 20:06:02 UTC] NetUpdate::All contests are either closed (keyserver) or
disabled (client)
[May 29 20:06:02 UTC] Network update is currently not available.
[May 29 20:06:02 UTC] *Break* Shutting down…
[May 29 20:06:02 UTC] Shutdown complete.

Then your client needs immediate replacement!

This means you Bob

I added 4 new graphs to the main page this morning. They have flyover-zoom – if you move your mouse over the graphs they zoom in to full size. I also did some cleanup of unused buttons and other stuff to make your experience better.

Kevin

I changed over to the new Cowboy service today. The server used to run as an application on my desktop and was subject to getting turned off when the computer rebooted and was sitting there at the login prompt. Now that it is running as a service, it will continue working, even if I am not logged in.

This should help a lot with everyone’s stats graphs.

I also made quite a few cosmetic changes to the the herd details grid. Hopefully your browser won’t cut off the right edge any more.

Back to work!

Kevin

I have fixed a lot of bugs and am still adding features to the Cowboy web site.

The new stand-alone stats analysis server seems to be stable (finally), so as soon as testing is complete, I will switch it over to the Windows Service version to further improve reliability. Everyone’s stats graphs should improve over the next few days, now that outages have been minimized.

I am concentrating on Help text in the web server back end tonight. That should go fairly quickly and then I’ll get back to filling in missing features on the Herd Details page.

Stay tuned!

Kevin

Most of the old Cowboy II web pages now redirect you to the new web site. I am no longer updating the old pages, but if you bookmarked specific graphs, they are still there.

The new stats site is located at:

http://idk.serveftp.net/cowboy/cowboyisapi.dll

Use the contest combo boxes to select the set of stats you want to see.

On the entry page, select the name of the person you wish to view (the herd).

All grids allow sorting of the data by clicking on the blue grid headers:

The column names are similar to the old Cowboy Stats Server page.

Hostname: the name of the workstation (cow), or its alias. I can rename your cow’s hostname, as it appears on the stats pages. If you have an actual hostname like topsecretname, I can have it show up as reallyboringname in the stats pages.

Heath: Green = healthy, Yellow = sick, Red=dead

Health Reason = reason for poor health or death

Peak = highest OGR or RC5 rate seen in your logs for the last 90 days

Average = the actual average rate of the cow, calculated as the number of work units accepted by the distributed.net key server. This number drops if you don’t run your cow 24/7, or if the cow is very busy doing non-contest related work.

Eff% = The cow’s efficiency, measured as: (Peak / Average) * 100

Last Log: Date and time (UTC) of the last log sent to the Cowboy Stats Server

Logs/Day: The number of logs per day this cow sent to the Cowboy Stats Sever. More than 10 per day affects the speed of your cow. Please adjust your mail-log-max value in dnetc.ini if you see this error. You typically need to double the number found there. The Cowboy Stats Server averages this logs/day number over 2 weeks.

Last Server: The last date/time (UTC) this cow sent/received work from the distributed.net key server.

Last Ckhpnt: The last date/time this cow was improperly shut down and restarted

Client: The version of the distributed.net client the cow is running, if known

OS: The operating system of the cow

CPU: The CPU type of the cow

Cores: The number of CPU cores, if known. If a cow has multiple physical CPUs, each with multiple cores, then this number should reflect that. Example: A dual CPU, Core-2 Quad will show up as 8 cores. I am working on this number for CUDA clients that have something like 64-128 cores.

Log: A link to the raw cow log.

For people with large herds (more than 10 cows currently), there is a “Prev” and “Next” button to view pages of 10 cows. Click these buttons to view other pages of cow stats:

I am currently working on the menus found at the tops of the various stats pages. Yes, I know they don’t work yet. Stay tuned for lots more stats and graphs.

Please add comments here with any bug reports and suggestions.

Enjoy!

Best regards,

Kevin G. McCoy

I am making some progress on Cowboy III and have added some more stats. Additional stats are also possible with the new infrastructure.

Check out it out here.

and let me know what you think. I will be making frequent updates to fix bugs and add features, so check the link often.

Note that you will not be able to bookmark your own stats page with the current software. I may change that in a future revision.

The cool part is that the main “team” screen updates in real-time and I will be able to update the graphs more often.

Have fun!

Kevin

OGR-25 is complete, and our team came in at #8, world wide. Not too bad for a team of our size!

I’d like to thank everyone who devoted time, both personally and via their spare CPU cycles in this effort.

The last 8 years of OGR-25 crunching has gone by so fast! Can you remember switching out clients from RC5-64 to OGR back in the day? I sure do!

Well, now that the venerable OGR-25 challenge is over, its time to move on. RC5-72 doesn’t look so good – it will be several decades before that one is complete – I’d like to start a new challenge that will be complete sometime before time I retire, or croak, whichever comes first.

There is a new OGR contest, called OGR-NG. Clients exist for our favorite operating system, so I encourage you to update to the latest v507 client as soon as possible.

OGR-NG should go pretty quickly, so lets get Team Warped switched over as soon as we can!

I have already switched almost all of my machines over to the new v507 client and have them crunching OGR-NG work units exclusively. My fingers are sore from so much typing of installation commands! I installed v507 on ~70 computers last night. Phew! Next I have to optimize them all, but that is a lot simpler than doing 70 deinstalls and 70 installations.

Neither distributed.net nor Cowboy can display the OGR-NG stats quite yet, but I will be collecting log files that can be reprocessed later. When I update Cowboy, your old stats will appear on our web site.

The v507 client can be found in the beta client area on Distributed.net.

Install the client as usual, then configure the dnetc.ini something like this:

—————————%————————————-
[parameters]
id=

[buffers]
checkpoint-filename=checkpnt.bin

[misc]
project-priority=OGR-NG,OGR-P2,RC5-72=0

[triggers]
restart-on-config-file-change=yes

[display]
progress-indicator=auto-sense

[ogr_p2]
fetch-workunit-threshold=10

[rc5-72]
fetch-time-threshold=1

[logging]
mail-log-via=idk.serveftp.net:250
mail-log-max=32768
mail-log-dest=rc5@idk-inc.com
log-file-limit=2048
log-file=dnetc.log
log-file-type=fifo

[ogr-ng]
fetch-workunit-threshold=10
—————————%————————————-

If you need help, drop me a line!

Best Regards,

Kevin G. McCoy

I ever was wondering why my Athlon1GHz had a crunching rate at only 7-8 Mnodes/s. Well its not a hot new system, I agree, but even real oldies like the P-II’s (300-400MHz) I have in my herd were not that far away at around 5 Mnodes/s, and the P-III 700MHz in my HP Omnibook was crunching at almost 10Mnodes/s.
Why the hack was the fastest CPU that slow compared to the others?

Then, although I must have known that earlier, while checking my herd statistics on ‘the Cowboy’ I realised that not all systems were running the same or similar client versions.
The recently installed clients on the P4 and AMD K8 dualcore WIN$ machines were on 2.9013-500, or -498 for the Win98 notebook,
the Linux test system P-II 400MHz has the the most actual client 2.9015-504 and my work horse eComStation was running on … shocked …
ancient 2.9008-490 (a version down from 2004).
But well, it is just a cruncher, a cracker doing some numbers back and forth and around, should not make a big deal…

Ok, lets get the newest from distributed.net.
Said… and done.
Got 2.9015-504 for OS/2 and waited until the next packages were done. Stopped the crunchers, flushed buffers and copied the new client into the directory.
Fired it up and all is well – until I recognised the output….the crunching rate was now up to 13 Mnodes/s – almost double than before.
I have been a damn idiot running that old client for so long … wasting hours of crunching … wasting lots of kWh electricity.
All could have been so much more efficient…

Lesson learned: Always the newest client! Check the download page on distributed.net at least once in a term, if you are running an actual OS.

You may notice that the stats graphs here on the Cowboy site change format from time to time. You might also notice that the tabular stats stop updating off and on.

The reason is that I am working on a new version of Cowboy that won’t use so many CPU cycles when updating the pages here. Right now, updates bring the Cowboy server to its knees for 30-45 minutes, every 6 hours. When I test the new server software, it updates the stats site with different graphs and HTML.

I need it to capture lots of logs with the new software, so the old site will sometimes stop updating for a day or so – none of the logs are lost though. The old server processes them when I turn it back on.

Tests on the new software shows it can do the same job in about 3 minutes with little impact on the computer! I am getting rid of the old Nexus database and replacing it with MySQL.

Other stuff…

I just added a new OGR box named “Ferrari”, a

dual

Core-2 Quad machine. Thats right – the equivalent of 8 CPU’s in a single box! It won’t be up full time until maybe Monday, but it should ramp up our team’s OGR rate a bit.

A quick run-up showed each core doing about 26 meganodes per second – not too shabby:

[Apr 10 22:57:25 UTC] Automatic processor detection found 8 processors.
[Apr 10 22:57:25 UTC] Loading crunchers with work…
[Apr 10 22:57:26 UTC] The keyserver says: “Moo from the new and improved
haystack.ivo.nu”
[Apr 10 22:57:26 UTC] Retrieved project state data from server. (cached)
[Apr 10 22:57:28 UTC] OGR-P2: Retrieved 28 packets from server.
[Apr 10 22:57:28 UTC] Automatic processor type detection found
an Intel Pentium III (Katmai) processor.
[Apr 10 22:57:28 UTC] OGR-P2: using core #3 (GARSP 6.0-asm-rt1-mmx).
[Apr 10 22:57:28 UTC] OGR-P2 #a: Loaded 25/11-23-6-2-28
[Apr 10 22:57:28 UTC] OGR-P2 #b: Loaded 25/11-23-6-2-30
[Apr 10 22:57:28 UTC] OGR-P2 #c: Loaded 25/11-23-6-2-33
[Apr 10 22:57:28 UTC] OGR-P2 #d: Loaded 25/11-23-6-2-50
[Apr 10 22:57:28 UTC] OGR-P2 #e: Loaded 25/11-23-6-2-51
[Apr 10 22:57:28 UTC] OGR-P2 #f: Loaded 25/11-23-6-2-52
[Apr 10 22:57:28 UTC] OGR-P2 #g: Loaded 25/11-23-6-2-53
[Apr 10 22:57:28 UTC] OGR-P2 #h: Loaded 25/11-23-6-2-54
[Apr 10 22:57:28 UTC] OGR-P2: 20 packets remain in buff-in.ogf
[Apr 10 22:57:28 UTC] OGR-P2: 0 packets are in buff-out.ogf
[Apr 10 22:57:28 UTC] 8 crunchers (’a'-’h') have been started.
[Apr 10 23:00:27 UTC] *Break* Shutting down…
[Apr 10 23:00:27 UTC] OGR-P2 #h: Saved 25/11-23-6-2-54 (4.79 Gnodes done)
0.00:02:59.23 – [26,697,614 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #g: Saved 25/11-23-6-2-53 (5.21 Gnodes done)
0.00:02:59.23 – [29,076,747 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #f: Saved 25/11-23-6-2-52 (5.12 Gnodes done)
0.00:02:59.23 – [28,564,086 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #e: Saved 25/11-23-6-2-51 (4.79 Gnodes done)
0.00:02:59.23 – [26,741,590 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #d: Saved 25/11-23-6-2-50 (5.29 Gnodes done)
0.00:02:59.23 – [29,530,347 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #c: Saved 25/11-23-6-2-33 (4.65 Gnodes done)
0.00:02:59.23 – [25,916,046 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #b: Saved 25/11-23-6-2-30 (4.57 Gnodes done)
0.00:02:59.23 – [25,478,305 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2 #a: Saved 25/11-23-6-2-28 (5.12 Gnodes done)
0.00:02:59.23 – [28,540,177 nodes/s]
[Apr 10 23:00:27 UTC] OGR-P2: 28 packets are in buff-in.ogf
[Apr 10 23:00:27 UTC] OGR-P2: 0 packets are in buff-out.ogf
[Apr 10 23:00:27 UTC] Shutdown complete.

Kevin

I did some quick debugging of the Cowboy server code, fixed some bugs and replaced a missing file.

It seems to be working again after a day or two down time. Your stats here on Cowboy should come back to normal over the next few days/weeks. The outage will not affect your cracking rate on DNET.

We now have an overclocked Intel Core 2 Quad, water cooled stats server.

Click here for some photos.

Kevin

I am moving the web server and the Cowboy stats engine to Samovar. There are some teething pain issues that I am struggling with. I have installed the latest Apache, PHP, Perl, and am still configuring things.

There may be delays in Cowboy stats updates and my blogs seem to have a slight case of Alzheimer’s.

Hang in there!

Kevin

I just bought a replacement for Deepblue, the Cowboy server. I mention it, because the replacement should be a screamer. Deepblue is getting a bit long in the tooth and needs a new PSU and fans – I’ll keep it in my herd, but have decided to shift it to my wife’s office to replace her even slower computer. Gobbles, her old machine, will begin CAD duty in my art studio and will continue to crunch on OGR.

The new box is going to be an overclocked, water-cooled Intel Quad-Core 2 with 2 GB of RAM, 4 SATA RAID 0+1 drives and an overclocked gamer video card. The video card is supposedly compatible with the next generation of OGR/RC5 crunchers that should outrun even the Quad processor CPU! Watch for new DNET clients that can run on the processor in your video card. Video cards have the capability of crunching much faster than a motherboard CPU. Hopefully, I’ll be able to crunch OGR work on the Quad CPU and the video card simultaneously. In the short term, it will be CPU crunching only.

It will take a while to build it (the parts are currently on order from Newegg.com) and to configure it. Newegg says the parts should arrive sometime next week. Look for a machine named Samovar (named after the water cooling system) in my herd in the next couple weeks. I’ll post pictures soon.

Here is the list of hardware components in: Samovar

Kevin

It looks like the OGR contest has run out of easy to crunch blocks, and now most of my cows (and probably yours too) are working on slower-to-crunch ones. I have adjusted all my DNETC.INI settings as follows:

[ogr_p2]
fetch-workunit-threshold=xx

decreasing them by half. If it used to say “30″, I reset them to 15.

If the threshold number is too large, it will take days to weeks to crunch all your blocks. Your graphs will get spiky looking. If the number is too small, your cow will be asking the server or proxy for new blocks all the time, and that is inefficient.

If we start crunching easier blocks in the future, then we can all adjust this number upwards to cut down on network bandwidth. I’ll keep you posted.

Kevin

The following message was posted by Bovine on the RC5 mailing list the other day. I’ll post it here for anyone that is not a mailing list subscriber:

Dear friends,

It is with great sadness that we must announce that RSA Labs has
decided to terminate the RSA Secret-Key Challenge, which impacts the
RC5-72 project and all of the remaining RC5 challenges. This means
that RSA Labs will not confirm any solutions or award any additional
prizes, should a correct solution be found. Furthermore, we have
received a statement indicating that they will not be disclosing the
solutions to the unsolved challenges. More details can be found on
http://www.rsa.com/rsalabs/node.asp?id=2100 (Note that the page should
state that the RC5-32/12/8 solution was recovered on 14 July 2002, not
28 January 1997.)

Although RSA Labs is halting their official sponsorship, there is
still the option open to us to continue the project without their
prize or validation. We would like to solicit your feedback regarding
this option. Discussion is welcome on our rc5 mailing list (see
http://lists.distributed.net/mailman/listinfo/rc5 if you are not
already a member). In the coming days, we will provide a facility to
allow official votes to be made.

If the choice to discontinue the RC5-72 project is made, the official
transition plan will be as follows: In one week’s time from the
announced decision, the distributed.net keyservers will begin
indicating that the RC5-72 project is closed to all connecting dnetc
clients. All results received after that time will be discarded. A
couple of days before then, we will begin slowing down RC5 work unit
generation to allow the network to drain. If we receive sufficient
feedback indicating that you would like us to continue operating the
RC5-72 project, we will continue to generate work units and the
project will remain open.

We intend to continue operating the OGRp2 project, and are currently
in the development stages of additional types of projects. More
details regarding these future projects will be announced at a later
date. In the mean time, we encourage everyone to continue
participating in both the RC5-72 and OGRp2 projects.

Moo! ]:8)

Currently, the RC5 mailing list members are discussing the future of RC5 (OGR will continue as before). Some members want to cancel the contest and move on to some other contest, others want to continue RC5 without the prize money. Confirming the “winning” key might be problematic, since we won’t have a neutral referee (RSA Labs) and the complete plain text of the encrypted phrase is unknown.

Continuing would mean many more years of work, especially if there is a substantial drop of in participation. Note that the RC5 contest is currently at less than 1/2 % complete and it has been running for several years.

If you have an opinion on this matter, you might want to subscribe to the mailing list (go to the dnet web site and follow the links) and voice it quickly.

It may be a while before new contest cores can be written for the DNET client, if the decision is made to cancel RC5 support and replace it with a different contest.

I anticipate that most of the other teams will switch to OGR, at least in the short term. This will put a lot of pressure on us, if we want to stay as highly ranked as we are. I’m doing my part, but we will need some more CPU cycles to stay on top in the long term. Think about upgrading your older machines and adding friends, family and neighbors machines to the effort. Try overclocking your older machines – it just might help!

I’d like to hear your views on the RC5 contest cancellation here too.

Kevin

Strange thing – my outgoing email up and quit the other day. Since I am a software developer, I ran through all the usual debugging tricks. It looked like my local ISP, Comcast, was somehow blocking my outgoing email traffic! Incoming still worked fine. I used my computer at work to email them and they swore blind that they weren’t blocking my mail. They lied.

It turns out that they are actually and they finally ‘fessed up tonight. In a misguided attempt at blocking spam they have decided to change the standard email port from 25 to port 587. This is the technical equivalent of moving a few doors down the block because you get too many traveling salesmen knocking at your door. The trouble is the salesmen will soon find your new address, and start banging on that one too.

Yes, changing ports will block spam on their system briefly. Just until the virus writers add a few lines of code to get the new Comcast email port number out of your registry and use that instead automatically using port 25. It will be back to business as usual and the spam floodgates will be wide open again. Only the Comcast customers suffer.

I just checked my Windows registry, and low and behold, the email port number is in there half a dozen times. If I were a virus writer (and I am most assuredly not!), it would take about an hour to write some programming code that grabs the non-standard port number and work around Comcast’s idiotic port switcheroo. I can assure you that such a virus development effort is well underway by script kiddies around the planet, even as I type this.

The decision Comcast made to change email ports is just plain stupid on several levels. It will result in a massive tech support headache for them – just about every customer that has their standard email port blocked will be calling them to get their email “turned back on” again. They will have to walk tens of thousands of twit users through the process of reconfiguring their email browser. I wonder how the Comcast stockholders would feel about a poorly informed business decision that will hit their bottom line big time. Tech support is a major expense for an ISP.

Comcast tech support informs me that they are phasing this policy in, system-wide. I just got hit early on. I had a most unpleasant phone conversation with them, and they refused to unblock the port on my cable modem.

The good news: My “home” ISP (yes I have two of them) was sympathetic and offered a solution – they have an alternate email server port open that I can use instead of the blocked port 25. Kudos to Westnet/Silicon Beach out in California for being customer oriented and quick to offer a good solution. Westnet really knows how to run a business, and I have been very happy with their tech support over the years.

My advice is to avoid Comcast as an ISP. If they are dumb enough to make a major change to a basic service like this without informing their victims (oops, I meant customers) then what’s next?

Kevin

We are getting close to moving up to #5 in the world on OGR! If Team AnandTech keeps up their current rate and we do too, then we will overtake them in about 70 days from today!

Lets go Team Warped!

I will provide updates as we get closer to passing them.

Great work guys!

Kevin

I just added Poindexter, an LGA775 Intel Quad-core computer running at 2.7 GHz per core, overclocked from its base CPU speed of 2.4 GHz. So far, it seem stable at 15% overclocking, so I’ll keep it at that speed until something breaks, then maybe back off on the overclocking. Its nice and toasty warm at 75C on the CPU chip.

Hmm…. I have a little cooling capacity left, so maybe it will work at 20% overclocking? I’ll find out soon

I used the ASUS Striker Extreme motherboard with 2 GB of RAM and RAID-5 drives for a total of around 230 GB of HDD. This sucker cooks

Its a total gamer system, but I am using it for software development and DNET only. I got a totally riced-out mini-tower computer case, with a light-up Nissan 350Z logo on the front panel. I thought it appropriate, since that is my daily ride to work

Got a hot new DNET workstation? Tell us about it on the blog! Post some pictures too.

Kevin

Colin Hildinger, the originator of Team Warped has returned after a long hiatus! He is currently submitting log files to the Cowboy server and is a welcome (re)addition to our team. Colin has not been able to do much with DNET over the last few years due to work constraints, but is now back in style. Please make him feel welcome.

Lets crack some keys!

Kevin

Well, we got kicked out of the #5 position in team ranking by Ars Techinica Roast Beef, pushing us back down to #6 in the world. Roast Beef’s key rate is only slightly faster than ours, so if we can pour on the coal, it might be possible to catch up with them again. We should be back up at #5 in about 3 months – if we maintain our work rate and one of the slower teams maintains theirs.

I just added a couple of dual processor machines and a fast AMD box. Check out Taz (weighing in at 107 Meganodes per second!), Papasmurf, zipping along in the high 80 Meganodes/Sec, and Pepper, running about 70 Mn/Sec. Papasmurf is still being installed, so it won’t be online 24/7 for a few more days – I am not sure how fast this one is, but it may even outrun Taz.

Happy crunching!

Kevin

Sorry folks – last Thursdays storm knocked down a large portion of Washington State’s power grid and I just now got the lights back on. Team Warped Towers suffered from downed trees, no heat and water, and worst of all, no septic system.

Some of the downed trees came within inches of destroying buildings on my property and that of my immediate neighbors, so this was pretty serious.
The good news for the Team Warped membership is that I am investing in a standby generator to handle such emergencies in the future. The Genrac guy should be out tomorrow to give me a quote. I am tired of camping out in my own home.

Anyway, Cowboy is back up and running and your stats should recover in a week or two. They really weren’t affected by the Cowboy outage, since you still submit work directly to Distributed.net, even if Cowboy is off line.

Write me if you have any questions.

Happy holidays!

Kevin

The Cowboy site and this blog have been up and down the last two days due to internet connectivity issues and an unrelated power outage.
My cable modem provider dissconected me by mistake for about 18 hours and I am having some major electrical work done here at the Team Warped Towers industrial complex.
Everything should be back up and running now. We are still waiting for the Dnet stats server to come back up, but thats another story…

Kevin

I’d like to welcome Juergen Gaida to the Team Warped web site. Check out his stats here!

Kevin

The vast Team Warped web stats server room got a little quiet the last 36 hours or so. The lights were on, but apparently nobody was home.

I finally figured out that Cowboy runs a lot faster if you actually plug it into the LAN. Its back on line and accepting log messages from your cows again. Sorry for the droop in everyones stat graphs, but your actual work got logged on DNET. Not to worry!

I don’t know if my router/firewall hiccuped or if I have a flakey CAT5 cable. Everything was plugged in, but there was no connection from Deepblue to the outside world. I power-cycled everything and it is working again. We did have a power bump or two and torrential rains the last few days – maybe that was it.
Now, if Fiddles and Decibel can figure out whats wrong with the DNET stats server and fix it once and for all…
Kevin

Since Collin Hildinger dropped out of the DNET challenge about 2 years ago, we have effectively been without a team captain.

I wrote Decibel at DNET a month or two ago, mostly looking for a way to get in touch with Collin (who seems to have fallen off the face of the Earth). Decibel posted a message on our team page stating that I wanted to be captain! Well, that wasn’t exactly true, but time passed and nobody complained about the potential management change, so today, Decibel sent me the captain’s password.

I am happy to report that I have accepted the postion and hope to take our team into its second decade of operation.

I have been working on the DNET challenge for 9 years this month, all of it on Team Warped!

Please note that the captain is simply the contact person for the team – it is not like I get a 7-figure salary and a corporate jet or anything.

As my first official act, I have slightly updated the OS/2 blurb and redirected the link from the IBM Warp site to the eComStation site. I also put a link to the Cowboy site and this blog, inviting any other Team Warped members to drop by and chat or post their stats. I left most of the rest of the text the same.

The old IBM Warp link mostly talked about moving off OS/2 and on to windoze and Linux, so I didn’t think it was appropriate.
I invite other team members to submit text for our Distributed.net Team Warped page. I am still running Warp 4, so I don’t know much about eCS. If someone has some interesting information about eCS that would fit on the Team Warped description page, send it to me and I’ll be happy to post it. It has to be short – about the same length as the current text, so don’t get too long winded.

I hope to hear some ideas for the team page soon!

Kevin

Are you running a windoze box with an AMD CPU? Check out the new beta client on distributed.net. Its a good bit faster than the non-AMD-optimized ones. Look for version 498. There isn’t one out for OS/2 yet, but they usually follow up in a month or two on the other platforms. The new client doesn’t do anything for Intel processors, so if you aren’t running AMD/Windoze, I wouldn’t bother.

You really should be running at least v497 on all your machines though. This 497 is substantially faster than the older ones on Intel processors.

If you want to upgrade dnetc.exe, here is how you do it:

Don’t forget to flush your old work units before installing (overwriting) the old dnetc.exe with the new one. You can do that by opening a dos box and running:

c:\program files\distributed.net> dnetc -flush

Wait for the flush to finish. Then enter the following command if you are running dnetc as a windoze service (highly recommended):

c:\program files\distributed.net> dnetc -shutdown

Then overwrite dnec.exe with the new one

now delete the old, empty data files:

c:\program files\distributed.net>del *.ogf

c:\program files\distributed.net>del *.r??

delete your checkpoint file, if any:

c:\program files\distributed.net>del *.bin

Now execute the following commands if you want to run dnetc as a service, otherwise, just restart dnetc and you are done.

If you switch from running as a startup folder option to running as a service, you’ll lose the on-screen graphics, but you’ll gain a cleaner desktop and slightly better performance. If dnetc is running on someone elses machine, then running as a service is the way to go, since the end user can’t easily mess with the program settings or stop it. The service runs silently hidden in the background and
most users won’t notice its there. To install as a service do the following:
install service:

c:\program files\distributed.net> dnetc -install

start the service (run dnet)

c:\program files\distributed.net> dnetc -svcstart

Services automatically restart themselves on bootup, so you don’t need anything special for dnet in the startup folder.

Thats it!

Kevin