OGR Almost over??

[Train]

I had no idea, being an RC5 guy and all, but ive heard OGR will be over soon? and we are close to first? Well in that case, I think i will Dedicate 2 PIII 700's here at work to OGR until its over, if TA can finish a project in first place that would be great!

I've already signed my life away to SETI after RC5 is over, so this may be my only chance to do something different.

 

[Adul]

I think ogr 24 is almost done and ogr 25 will be there sooner or later. Then i think there is ogr 26 afterwards.

 

[Viztech]

Yes Train, you still have a couple of weeks to help TA get back into the #1 spot in OGR-25. Make sure your client is set to pull from the TeAm proxies, set your project order to OGR,RC5,DES=0,CSC=0 and frequent-threshold-checks=4 and count some rulers. Your client will revert back to RC5-64 automatically when it can't get any new OGR work units, but will flush and fetch OGR as needed.

Thanx for the help Train!

viz

 

[CetiAlphaV]

what is the addy i should be pulling stubs from

 

[ViRGE]

As long as you get stubs, it doesn't really matter. It's just that Dnet's proxies are almost dry.

 

[JonB]

We will try to keep the Team keyserver full.

Its address is: proxy.teamanandtech.com

If you want to check its status, go to: IODBBS

 

[ViRGE]

TF is draining SO's pproxy as we speak. It's slow going, but we'll get several thousand OGR stubs as a result.

 

[CetiAlphaV]

Thanks guys. I now have my Athlon 550 dedicated to OGR.

 

[JHutch]

As I pointed out on another thread, OGR25 is not almost finished. It is almost finished with Pass 1, which means it is almost half over...

The OGR contests run through the stub space twice as a way to double check all the results. This method helps protect against malicious crackers looking to run their stats up with hacked clients.

JHutch

 

[jinsonxu]

Dang, the proxies have been refilled!

I wasted time buffering a few K of stubs. sigh.

 

[BurntKooshie]

<< bovine@distributed.net
Login: bovine Name: Jeff Lawson
Directory: /home/bovine Shell: /usr/local/bin/tcsh
Last login Tue Dec 5 10:24 (GMT) on ttyp2 from [hidden]
Mail last read Thu Mar 30 04:13 2000 (GMT)
Plan:

20-Nov-2000 11:30 (Monday) ::
As it turns out, OGR25 is also approaching the time where we need to
manually reissue the remaining unreturned stubs necessary to complete both
of its first and second passes. >>

That's not what bovine's saying Jhutch....

 

[JHutch]

BK,

You're right. And I guess I shouldn't pass myself off as knowing for sure, but ...

I'm pretty sure something isn't adding up here. Unless they were issuing pass 1 and 2 at the same time, the stubs I saw just didn't following a pattern that would support what Jeff's .plan said.

Basically, if they issued pass 1 and then pass 2, the stubs would have climbed up and then started back down. I've only seen stubs steadily climbing...

If they passed out 1 and 2 together, it would follow this pattern, but it is completely backward to the way they've done OGR24 in the past.

The last thing is that there have been a lot of &quot;estimates&quot; of how much bigger OGR 25 is than OGR24, and the node counts fit the estimates only if we have finished most of pass 1 and haven't start pass 2.

But, as in all things, I could be wrong. It has happened before ... though I could be mistaken about that!

JHutch

 

[BurntKooshie]

ahhhhh! I see why you're saying that now Your argument seems to make sense....now I see how/why something is awry somewhere, and we're not sure where....

 

[rc5]

&quot;Malicious hackers&quot; certainly can return same stubs twice from different IPs with &quot;hacked clients&quot;.

 

[Dijkhuis]

i think these graphs answer most questions:

http://n0cgi.distributed.net/statistics/ogr/index.html

ogr-25 pass 2 yet has to start, pass 1 is 70% done

 

[JHutch]

RC5---

That is why two passes, one after the other, is important. If the keyserver receives stub X twice within say a couple days of each other, it is probably a hacked client and can be marked as &quot;suspect&quot; and run through the system again for verification. The chances of a hacker getting the same stub on both passes is pretty small and other things (such as phenomenol node rate) would alert people that a potential hack has occured...

JHutch