• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

For those of you that use OGR=0, WHY? There is a beter way.

Adul

Adul

Elite Member
There is a more proper way to make rc5 the main project priority. What are you going to do when the contest comes to an end?

This is a more proper setup. This is how it works
RC5 will be kept the priority unless a couple of circumstances are met.

1. The project comes to an end. So why do randoms for a project that is no longer there.

2. The connection to the net is lost, rc5 buffers run dry. It will then run a OGR stub. Upon completion of this stub, there willl be a check for RC5 work. If there is not any, then it will do another stub until there is more work to do in RC5.

Now honestly guys, it will not hurt that much to do an occasional ogr stub. Missing blocks I would believe to be for more harming to our Rc5. In other words it is a better use of our computing power.

** this will buffer 72 hours worth of work no matter the comp speed **

-------------------------------------------------------------------------------------

[parameters]
id=tncrc5@home.com

[networking]
keyserver=proxy.teamanandtech.com
nofallback=true
autofindkeyserver=no
dialup-watcher=passive
interfaces-to-watch=*

[misc]
run-work-limit=0
project-priority=RC5,OGR

[rc5]
fetch-time-threshold=72
preferred-blocksize=33


[buffers]
checkpoint-filename=cp
frequent-threshold-checks=3


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

[ogr]
fetch-workunit-threshold=2
 
It is time we make all team members aware off the options they choose. That way the choice they make will be the best ones.

Yes I have been digging into these ini files a whole lately.
Wait untill I make on for PPstats. 🙂
 
Adul... oh great god of OGR...

Teach me the ways of OGR so that I may better maintain my processing trade with danzigrules and make sure that I have the damn config file setup correctly... 😉

As of this morning, I'm running it on a K6-2/450 and the "speed page" says something like "256 WU/day"... which is sortof meaningless to me unless that means stubs or something... 😕

Meanwhile, the pproxy ini file has the lines "minkeysready" and "maxkeysready" for the [ogr] section.

Does this not illustrate why I'm confused??????????? :frown:

HELP!!!!!!

🙁
 
Thanks Adul! Sorry for the delay!

This is the proxyper.ini file:

; $Id: proxyper.ini,v 1.22 2000/04/19 23:18:22 jlawson Exp $

[KeyServer]
ipaddress=proxy80.teamanandtech.com
port=2064
connectperiod=600
connectivity=normal ; normal,offline,lurk,lurkonly
;bindip= ; IP to talk out to keyserver from
;uuehttpmode=0
; 0=normal,1=uue,2=http,3=http+uue
; 4=socks4,5=socks5,6=genproxy,7=genproxy+uue
;httpproxy=wwwproxy.corporation.com
;httpport=8080
;httpid=

[ports]
;listenaddress= ; IP to accept clients on
port=2064
;port2=23 ; must be root for ports < 1000
;port3=80
testport=3064
timeout=30

[console]
logfileconsole=
logfileconsolerotation=daily
consoleverbosity=&quot;general stats keyblock server client buffers timestamp attention errlow errsevere&quot;
timestampflags=130 ; 130=new UTC 4-digit year format

[rc564]
logfilekeyblock=pproxyrc5
logfilekeyblockrotation=daily
minkeysready=2000
maxkeysready=2400
maxkeysdone=500

;[desII]
;logfilekeyblock=pproxydes
;logfilekeyblockrotation=daily
;minkeysready=10
;maxkeysready=20
;maxkeysdone=3

[ogr]
logfilekeyblock=pproxyogr
logfilekeyblockrotation=daily
minkeysready=300
maxkeysready=750
maxkeysdone=250

;[csc]
;logfilekeyblock=pproxycsc
;logfilekeyblockrotation=daily
;minkeysready=10
;maxkeysready=20
;maxkeysdone=3

[misc]
proxymessage=&quot;Welcome to Poof's Baby Bovine&quot;
pidfile=rc5desproxy.pid
statusperiod=30
periodicperiod=120
;logfilecompressor=logcompressor.sh

[ignoredip]

[allowedip]
 
O I think i figured out what you where trying to say. What you are downloading are stubbs. Stubbs varies in sizes and the time it takes to complete one. They amount of work done is measured in nodes. Since each stub can take a different amount of nodes to complete it.

look at it has glasses of water. Each glass hold 12 oz of water. You drink 10 glass of water a day. Now lets say you no longer have the glasses to drink water from. Instead you have 16oz 32oz 8oz 4oz cups. so now you drink
2 32 oz
2 16 oz
2 8 oz
2 4 oz

cups of water. While you are drinking the same amount of water, the number of cups it takes to drink that water varies.

minkeysready=300
maxkeysready=750
maxkeysdone=250

Yes the keys can be confusing, just remember they are refering to stubbs ( which varie in size).

BTW, I would hardly call myseldf an OGR GOD 😉 still learning like you.


now if I manage to explain this total wrong. someone please correct me then 🙂
 
[KeyServer]
ipaddress=proxy80.teamanandtech.com
port=2064



I sense something odd there. 😉 Why use proxy80 if you're connecting to port 2064? lol
 
Adul - thanks for that! 🙂 The terms the ini file used (keys) made no sense in terms of OGR... 😕

But then the speed page talks about &quot;WU/day&quot; which again is confusing...
🙁

But... I've been monitoring my little cow and it is running at the 2.54 Mnodes/s that it should be running at. Looking at an output file I have (a &quot;nohup.out&quot; that I had dnet use when I start the client via a telnet session to the NetBSD), it looks like it took about 5 hours to do 1 stub (and that one had 62,568,152,497 nodes in it...😉). It currently has 7 left to do and the one it's working on has 45.09 Gnodes in it.

I just wasn't sure what the timing was for it to flush... so now I guess I sortof know... 🙂

Just want to make sure danzigrules doesn't have to wait too long to see some results! 🙂

And Sukhoi, I recall a bit ago someone mentioning that if you used the &quot;proxy80.teamanandtech.com&quot; hostname, it would take you to the round-robin as opposed to the other one (proxy.teamanadtech.com) that pointed directly to Mika's... ?? But it could be that both go to the round robin!

Using this one rotates me around to the different servers... Don't know if it is actually using port 80 anywhere though other than for web stuff... 😛
 
Adul,

Excellent advice! My compliments on a well-thought strategy for the client.

Even though I am almost entirely doing OGR work, I assumed that there would be times that the buffers dried up and no OGR (or possibly RC5) was available.

My approach has been to buffer a relatively large amount of OGR and a few (32 WU) of RC5 and set the client to complete them all before fetching more. That way I have some of both available nearly all the time and I don't have to worry about WU's getting &quot;stale&quot; and being re-issued by D.Net. Typically, I find that my clients spend about 45 minutes a day on RC5 work and 23:15 on OGR. 🙂 This way I'm still doing a bit of RC5 work as well, which makes me happy.

I know it's another approach, but I thought I'd at least throw it out.

-Brian
 
I goes both ways brain. 🙂 I was more concern about the RC5 bunch doing what they are doing by using OGR = 0
so I want to bring up soem awareness
 
Hmmmm, good subject matter everyone! By no means do I use RC5=0 in my ini....I simply flush every completed OGR WU, so I never run out of work. I keep the RC5 in buffers low, and I will switch the ini files once in a while to drain the old RC5 work out of the clients as well as the proxy so those RC5 blocks don't get stale.

You might consider the fetch/flush on per project exhaustion switch as well-

[buffers]
checkpoint-filename=cp
frequent-threshold-checks=4

That way, you will complete all the OGR (or RC5 😉 ) in your in buffer, and try to connect to the keyserver while munching the last unit of the primary project. This is something to consider.

Poof-

The min/maxkeysready in OGR is stubs or WUs NOT the # of nodes. The proxy has no idea how large a stub will be until it is completed. Most computers in use now will munch only one or two OGR-25 stubs in a day, and my K6-233 may take 2 or 3 days to munch a big one.

The new clients are now reporting the number of stats units, which are the same as Gnodes.

As for the proxy80.teamanandtech.com....All of the port 80 proxies also listen on the default port of 2064, so that is why they work perfectly. 😉

viz
 
Viztech. We had much discushion of using frequent-threshold-checks=3 or 4. I settle on 3 for dial up and 4 for 24/7 connections.

Reason for 3 on dial up, you want those buffers full whenever possible, and not when they are ready. Now if you have a 24/7 connection or a pproxy you can access, then 4 is a better option.
 
Yes, excellent choice Adul.

Dial up detection mode works well also, as long as you're not on AOL! LOL

I hope that this thread does catch the eyes of a few RC5 only people. If the RC5 key is found tomorrow, a lot of machines will be doing nothing that could just as well be doing some more arithmetic. 🙂

viz
 
Actually, the latest clients work well with AOL 5 and above. I actually have 4 part time cows in my herd using AOL.😉
 
Excellent topic Adul 😉

Poof, what viztech said is right. proxy80.teamanandtech.com are proxies that listen at both 2064 and 80, all the proxy(xx).teamanandtech.com proxies listen on 2064 as well as either 23 and/or 80. The only two addies that are directly to Mika's are edge.teamanandtech.com or core.teamanandtech.com (I'm not 100% sure about this so please correct me if I'm wrong guys), any addy with proxy(xx).teamanandtech.com points to a RoundRobin of pproxies 😉

Hope that helped some 😕

With love and respect your fellow TA member

Two-Face
My stats:
RC5
OGR-25
Seti
Gamma Flux
 
Adul: I'm glad to see another person bring this issue up. I had brought it up a while ago, but it hadn't been discussed for quite a while. 🙂

About the buffer threshold checks, I'm pretty sure that the dialup detection mode will override that setting. For example, if you have dialup detection mode to lurkonly and buffer threshold checking to 4, the client will wait until a dialup detection is detected, and then flush everything possible. This means that if the client is online and completes a workunit it will flush that workunit and fetch another one automatically (in other words, it will behave like buffer threshold checking was at 3 while online).

You may want to experiment on your own, but I'm pretty sure that's how the client will behave.
 
Wow thanks guys for the clarification!!!! 😀

And viz - I've checked the log and my K6-2/450 looks like it did about 2-3 stubs the first day. I'm used to seti and > 1-2 day WU times, etc. (I have one old seti machine that does a WU every 153 hrs!). But with me running RC5 and it completing blocks on my faster machines at such a rapid rate in comparison to other projects, I kinda got used to that quick behavior out of dnet clients... 😉 Call it a renewed stats addiction! 😛

Since I'm participating in the &quot;project processing swap&quot; with danzigrules to maximize production for TA (I'm doing his OGR and he my RC5), then I just wanted to make sure that he can at least &quot;see&quot; the results of my machine's efforts in a timely fashion... I guess I could try to set the machine to flush once a day, now that I sortof have a handle on it's rate... But I have a feeling that you OGR guys are more laid back about the stats... 😉

Also thanks viz &amp; twoface regarding how that round robin is setup. I kinda remember the threads awhile ago when that was being set up, but since I was flushing directly to dnet at that time, I didn't really pay alot of attention to it...

And ViRGE... surprised you were willing to admit AOHell usage... 😉
(I can crack because I still have my old AOL account after I converted to a cable modem.... and in case the cable service goes out, I do have a backup...LOL 😉)
 
OGR people more laid back on stats?

Could be. But then again we seem to have a lot fewer active members. 😱 Hope that we continue to grow though. The processor trading thread to get K6s on OGR seems to be renewing fresh interest (and efficiency) into the project.😉

viz
 
You must log in or register to reply here.
Back
Top