Looks like they've heard our concerns...and I take members responses to Nuggets post as a positive thing, which means that this email doesn't have to be sent 
Please read
- Thread starter BurntKooshie
- Start date
Well, I don?t know if this has anything to do with the current crunching of OGR rather then RC5 blocks, but I?ve lost ground. Dropped 52 spots, which is no big deal, but if this is because of OGR crunching, then I?m surely going to be upset. Is this the case?
It seems to me they are using us as test bunny?s for future OGR implementation, though I maybe way off. If someone could really pass on some specifics on the situation, it would be very helpful.
It seems to me they are using us as test bunny?s for future OGR implementation, though I maybe way off. If someone could really pass on some specifics on the situation, it would be very helpful.
Well, I just f***** up my D.net client, and I don't think I be reinstalling it. I was trying to get it to do RC5 only, and now it won?t start. So guess that?s that!
ViRGE
Elite Member, Moderator Emeritus
- Oct 9, 1999
- 31,516
- 167
- 106
Here's my INI file, it should get ya going again.
[parameters]
id=virgedx@home.com
[misc]
project-priority=RC5,OGR=0,DES=0,CSC=0
[rc5]
preferred-blocksize=28
fetch-workunit-threshold=12
randomprefix=183
[des]
preferred-blocksize=28
fetch-workunit-threshold=12
[csc]
preferred-blocksize=28
fetch-workunit-threshold=12
[logging]
log-file-type=fifo
log-file-limit=2048
log-file=log.log
[networking]
keyserver=proxy.teamanandtech.com
disabled=no
autofindkeyserver=no
nofallback=true
[buffers]
checkpoint-filename=checkpoint
[ogr]
fetch-workunit-threshold=12
[triggers]
restart-on-config-file-change=yes
[parameters]
id=virgedx@home.com
[misc]
project-priority=RC5,OGR=0,DES=0,CSC=0
[rc5]
preferred-blocksize=28
fetch-workunit-threshold=12
randomprefix=183
[des]
preferred-blocksize=28
fetch-workunit-threshold=12
[csc]
preferred-blocksize=28
fetch-workunit-threshold=12
[logging]
log-file-type=fifo
log-file-limit=2048
log-file=log.log
[networking]
keyserver=proxy.teamanandtech.com
disabled=no
autofindkeyserver=no
nofallback=true
[buffers]
checkpoint-filename=checkpoint
[ogr]
fetch-workunit-threshold=12
[triggers]
restart-on-config-file-change=yes
I think Dnet needs to release a coherent statement (if they haven't) about their current slate of contests, what they've got planned for the future, and what their philosophy is in regard to prioritizing things. As far as I know, nothing of this nature has really been addressed.
With CSC (and before that, DES), I understood--you do RC5, CSC comes on the scene for a short while (during which a lot of people do CSC), then it's over with and everything goes back to RC5. With the current state of affairs with OGR, that doesn't seem to be the case. It seems like they've got this OGR contest ready to go, and as soon as it's finished, more waiting in the wings (OGR-25, etc).
Initial bad client versions aside, RC5 appears to be taking a massive hit from OGR with OGR as the default contest. It seems to me that RC5 is no longer high priority for DNET--they would rather move on to other things but cannot just shut down RC5 because that would be such a huge embarrassment. So, instead, they take the huge number of clients that were installed with the intention of cracking RC5 but were not explicitly configured to turn off OGR, and switch them over, shelving RC5 for the indefinite future.
My basic point is... by introducing OGR and future "default priority" contests, DNET is going to string RC5 out much longer than it should have taken, and they're not being respectful of the huge base of committed RC5 crackers who would like to see this thing one day finished.
With CSC (and before that, DES), I understood--you do RC5, CSC comes on the scene for a short while (during which a lot of people do CSC), then it's over with and everything goes back to RC5. With the current state of affairs with OGR, that doesn't seem to be the case. It seems like they've got this OGR contest ready to go, and as soon as it's finished, more waiting in the wings (OGR-25, etc).
Initial bad client versions aside, RC5 appears to be taking a massive hit from OGR with OGR as the default contest. It seems to me that RC5 is no longer high priority for DNET--they would rather move on to other things but cannot just shut down RC5 because that would be such a huge embarrassment. So, instead, they take the huge number of clients that were installed with the intention of cracking RC5 but were not explicitly configured to turn off OGR, and switch them over, shelving RC5 for the indefinite future.
My basic point is... by introducing OGR and future "default priority" contests, DNET is going to string RC5 out much longer than it should have taken, and they're not being respectful of the huge base of committed RC5 crackers who would like to see this thing one day finished.
Virge- thanks!! I just copied all of your file to mine (except your id you wish) and I'm back on RC5, i gotta do this to other computers.
welp,.... it all sounds well and good but........
Dnet are only gonna say..
1) You knew there were other projectes in the pipeline.
2) so you should have, prior to starting anything, set your prefered choice of cracking in the options of your client....
Just my $0.02
D
Dnet are only gonna say..
1) You knew there were other projectes in the pipeline.
2) so you should have, prior to starting anything, set your prefered choice of cracking in the options of your client....
Just my $0.02
D
JonB
Platinum Member
With all previous contest changeovers (I've been through the second DES contest, the CSC contest, and the aborted OGR trials), there was some warning, but not much. I didn't know the DES contest had started until I saw my cow icon change to a butterfly.
A major part of the DNet client programming is to be able to switch contests on the fly. With limited (or none, in this case) notice, DNet can see where to beef up the next client revisions to better handle a swap. There were problems with all the other contest switches, but I saw nothing similar this time. Progress is not always appreciated.
The latest system tweak coming out of this swapover involved fixing the keyservers and pproxies to distribute work based on client revisions. Great idea, but there wouldn't have been such an obvious need for it if they had phased in the contest slowly.
A major part of the DNet client programming is to be able to switch contests on the fly. With limited (or none, in this case) notice, DNet can see where to beef up the next client revisions to better handle a swap. There were problems with all the other contest switches, but I saw nothing similar this time. Progress is not always appreciated.
The latest system tweak coming out of this swapover involved fixing the keyservers and pproxies to distribute work based on client revisions. Great idea, but there wouldn't have been such an obvious need for it if they had phased in the contest slowly.
I must agree with DarkOne and JonB here. The info is all at Dnet, albeit a bit hard to find.
As I have said before, the fault is more our own as a Team. I and many others knew what was coming, thought that this would happen, and it did.
We should have thrown up a few threads on the subject to attract some attention to the matter.
You can send a letter if you want, but I would try to make it a constructive one over all else.
viz
As I have said before, the fault is more our own as a Team. I and many others knew what was coming, thought that this would happen, and it did.
We should have thrown up a few threads on the subject to attract some attention to the matter.
You can send a letter if you want, but I would try to make it a constructive one over all else.
viz
The general tone of the letter seems to be that we (team TA) messed up and did not take care of our members better. I would tend to agree with that. Those of us who have gone through the different contests should have made some noise before this happened.
What DNet needs to do is just change the way that the contests start. The .plan announcment of a contest change would be nice. I know with CSC they needed everything to start quick and be ready for the contest (it was time based with the assumption it would be done in 2-4 days) It they had given a heads up of a week people could have had the updated clients needed for OGR or changed their settings to stick with RC5.
No one likes the feeling of being on the end of a rope being jerked around by DNet.
S.
What DNet needs to do is just change the way that the contests start. The .plan announcment of a contest change would be nice. I know with CSC they needed everything to start quick and be ready for the contest (it was time based with the assumption it would be done in 2-4 days) It they had given a heads up of a week people could have had the updated clients needed for OGR or changed their settings to stick with RC5.
No one likes the feeling of being on the end of a rope being jerked around by DNet.
S.
Vis and Darkone, that is true to some extent, however new folks like myself read several things.
1. OGR is suppended indefintely
2. The client states the following: (in 2-9)
Load-work precedence:
The order specified here determines the order the client will look for work each time it needs to load a packet from a buffer. For example, "OGR,RC5,..." instructs the client to first look for work for OGR and if it doesn't find any, to try RC5 next, and so on.
You'll note the last line, this is misleading. I had clients set with RC5 first, but it still did OGR.
3. I also had OGR set to '0' for 2-13, yet it still got OGR. 2-14 states it is not implmented for OGR. Why did I get OGR?
I can see that this is a combination of many things, lack of experience with the clients, bad information posted by Dnet, incomplete FAQ for our team members and misleading information in the client as well as functions that do not quite do as they say.
I'm sure getting OGR up and running was a big success for Dnet, but the lack of news/information about it really did suck. Maybe everyone else is operating under the idea that they know Dnet works this way, but I did not, and I think it is run poorly if this is normal.
Now folks who say there isn't anything we can do about it are correct, it is past and all we can do is improve things for new team members. Some effort has been done to accomplish this too. Unfortunatly, it may not keep TAT from loosing a 100K or more RC5 blocks a day because folks that have busted their butts for this effort feel decived.
1. OGR is suppended indefintely
2. The client states the following: (in 2-9)
Load-work precedence:
The order specified here determines the order the client will look for work each time it needs to load a packet from a buffer. For example, "OGR,RC5,..." instructs the client to first look for work for OGR and if it doesn't find any, to try RC5 next, and so on.
You'll note the last line, this is misleading. I had clients set with RC5 first, but it still did OGR.
3. I also had OGR set to '0' for 2-13, yet it still got OGR. 2-14 states it is not implmented for OGR. Why did I get OGR?
I can see that this is a combination of many things, lack of experience with the clients, bad information posted by Dnet, incomplete FAQ for our team members and misleading information in the client as well as functions that do not quite do as they say.
I'm sure getting OGR up and running was a big success for Dnet, but the lack of news/information about it really did suck. Maybe everyone else is operating under the idea that they know Dnet works this way, but I did not, and I think it is run poorly if this is normal.
Now folks who say there isn't anything we can do about it are correct, it is past and all we can do is improve things for new team members. Some effort has been done to accomplish this too. Unfortunatly, it may not keep TAT from loosing a 100K or more RC5 blocks a day because folks that have busted their butts for this effort feel decived.
MWalkden-
I see your point. The client settings are confusing sometimes as well.
I am assuming that 2-13 (2-12 on a 460 client) OGR=0 is for the fetch limits, which 0 means to use the defaults which can be a week's work for many stubs/machines.
As we now know, it's the 'load work precedence' where OGR needs to be shut off. (Option 2-9 on a 460 client) The instructions are clear when you get to that screen.
Anyway by 'constructive' in my earlier post, I meant that it would be a good time to make viable suggestions to Dnet on how to avoid these problems in the future, not a flame thrower. I am all for a better way of doing things, but a few statements in the letter are a little harsh.
In conclusion, it's clear that the DPC did a MUCH better job of taking care of this problem for their members. Slash dot no better than us. That proves that we as a team could have done better.
viz
I see your point. The client settings are confusing sometimes as well.
I am assuming that 2-13 (2-12 on a 460 client) OGR=0 is for the fetch limits, which 0 means to use the defaults which can be a week's work for many stubs/machines.
As we now know, it's the 'load work precedence' where OGR needs to be shut off. (Option 2-9 on a 460 client) The instructions are clear when you get to that screen.
Anyway by 'constructive' in my earlier post, I meant that it would be a good time to make viable suggestions to Dnet on how to avoid these problems in the future, not a flame thrower. I am all for a better way of doing things, but a few statements in the letter are a little harsh.
In conclusion, it's clear that the DPC did a MUCH better job of taking care of this problem for their members. Slash dot no better than us. That proves that we as a team could have done better.
viz
Virge -
It's dissapointing to see that immediately after Moose discusses blocksize, you are configured to the smallest block, not even default. To top it off, you advertise it, which other people are copying. Please, people, give Dnet a hand and up your blocksize. Very few of us are running machines that require the smaller blocks.
It's dissapointing to see that immediately after Moose discusses blocksize, you are configured to the smallest block, not even default. To top it off, you advertise it, which other people are copying. Please, people, give Dnet a hand and up your blocksize. Very few of us are running machines that require the smaller blocks.
ViRGE
Elite Member, Moderator Emeritus
- Oct 9, 1999
- 31,516
- 167
- 106
Actually Simulacrum, that's my "debugging" INI file. I use that when I need to crack a block or 2 quickly to see if a certain proxy is up(in this case, one of the BBs). My client is normally set to use larger blocks, so I don't usually fragment as much.
PS My mahcine is a PMMX200, a single block can take at least 11min, usually longer
PS My mahcine is a PMMX200, a single block can take at least 11min, usually longer
Well, if it matters we (TA) are currently in first place (OGR), for how long is anyone?s guess. We also have the most participants 233.
I agree about the new members, like myself who had no clue OGR was coming. I mean according to the RC5 progress meter we?re not even halfway there, looks like 35%, and it took 997 days to get at this point. It?ll take even longer now since OGR seems to be the priority. Unless someone finds the key.
I agree about the new members, like myself who had no clue OGR was coming. I mean according to the RC5 progress meter we?re not even halfway there, looks like 35%, and it took 997 days to get at this point. It?ll take even longer now since OGR seems to be the priority. Unless someone finds the key.
Just a follow up here, Nugget from Dnet posted in the rant thread. I read it and it makes me feel much better knowing our frustrations have been noted. Additionally, some responsibility was taken.
TRENDING THREADS
-
Discussion Zen 5 Speculation (EPYC Turin and Strix Point/Granite Ridge - Ryzen 9000)- Started by DisEnchantment
- Replies: 25K
-
Discussion Intel Meteor, Arrow, Lunar & Panther Lakes Discussion Threads
- Started by Tigerick
- Replies: 21K
-
Discussion Intel current and future Lakes & Rapids thread- Started by TheF34RChannel
- Replies: 23K
-
-
Facebook
Twitter