Seti: Who dumped on me???

[Woodie]

Alright, who's been saving up for a huge dump?

See my siglink...someone dumped 1,353 WUs on me!!!

Seti accounts are: 4683123 and 4796509...who are you??? PM me!!

 

[Freewolf]

Hey Woodie I looked at your client log and looks like somebody dropped a ton of dups on you
Also saw that they just uploaded results and didn't download any new work.

 

[Rattledagger]

The 3 latest users/queues, queue D-E-F, is from the same external SetiQueue... The only currently named is esilent.

Interestingly, none of the 1353 wu from the largest dumper is doublets, since in the q000F-log all wu-names shows up exactly 2 times & second time due to "not dispatched by setiqueue", but still according to log 51 was reported doublets... I've not done cross-account-check to the 2 smaller accounts...

 

[Freewolf]

There are also 176 Problem results queued .

 

[Woodie]

I saw the "Problem Results"...do I have to do anything with those?

 

[Freewolf]

No the q should drop them when it trys to transmit them.

 

[Coquito]

In addition to this unexpected occurance, while my numbers have remained regular on your queue(27 results today, 31 yesterday), Berkeley has only reported 9wu's from me all day. 7 of which, are from a different pc using smoke's queue. Did my results get lost in the shuffle? Berkeley is still giving me errors, so I'll check back later.

 

[Freewolf]

Originally posted by: Coquito
In addition to this unexpected occurance, while my numbers have remained regular on your queue(27 results today, 31 yesterday), Berkeley has only reported 9wu's from me all day. 7 of which, are from a different pc using smoke's queue. Did my results get lost in the shuffle? Berkeley is still giving me errors, so I'll check back later.

No, your results are still sitting in the q waiting to be transmitted alone with over 1,400 other ones.

 

[Woodie]

Freewolf:

This morning, it seems that I still have >1,400 WUs waiting to upload, is there any way to speed it up?

I set the "Max delay between retries" from 30 minutes down to 10 minutes, hoping that this will get the results moving a bit quicker.

Thanks!

edit: 1220, now 1209...dropping, but awfully slowly.

 

[Smoke]

Woodie,

What's taking so long is your Q is having to DOWNLOAD new fresh WUs as well as send in the RESULTS of those 1,400 completed ones.

Go into your SETTINGS and temporarily DISABLE "DOWNLOAD NEW WUs".

Once the queued RESULTS have been transmitted, go back into SETTINGS and reENABLE "DOWNLOAD NEW WUs".

 

[Freewolf]

Originally posted by: Smoke
Woodie,

What's taking so long is your Q is having to DOWNLOAD new fresh WUs as well as send in the RESULTS of those 1,400 completed ones.

Go into your SETTINGS and temporarily DISABLE "DOWNLOAD NEW WUs".

Once the queued RESULTS have been transmitted, go back into SETTINGS and reENABLE "DOWNLOAD NEW WUs".

what he said and those problem work units can make the tranmitting slow down as well as sometime they will hang and the q will stop transmitting until a new work unit comes into it or you restart the q.

 

[Woodie]

Thanks guys...still sitting at 1205 results. I turned off "Downloand new WUs"...but I can't recycle the setiqueue service from work.

One of these days, I'll have to set up remote access for myself!

 

[Smoke]

I am still dealing with those "defective WUs" that were distributed months ago. I've been slowly tracking down the CLIENTS so affected and have been getting the owners to delete them.

This will be a repeat for many of you but it needs to be done by EVERYONE.

Do a SEARCH of your computer for a file(s) named, "result.sah". If you have transmitted all of your completed WUs (read have AUTO TRANSMIT enabled) you should not have any files named "result.sah". If you do .... they are DEFECTIVE! Delete the entire "numbered folder" within they reside.

EXIT SetiDriver (SetiHide) and then restart it.

This needs to be done on each computer running SETI.

Here is an example of what happens when these DEFECTIVE WUs are transmitted to Berkeley through a SetiQueue:


9:30am: Sending result 22se03aa.807.9393.267348.180
9:30am: Returning passing through request response
9:30am: Passthrough: Seti@home status: ErrorCode 0x00000064 100
9:30am: Seti@home message: 'Corrupt user ID. Please exit SETI@Home, delete user_info.sah and result.sah and restart SETI@H...
9:30am: Passing through request send_result_get_user_stats
9:30am: Queued passthrough request
9:30am: Sending result 27no03aa.25808.5520.940902.218
9:30am: Returning passing through request response
9:30am: Passthrough: Seti@home status: ErrorCode 0x00000064 100
9:30am: Seti@home message: 'Corrupt user ID. Please exit SETI@Home, delete user_info.sah and result.sah and restart SETI@H...
9:30am: Passing through request send_result_get_user_stats
9:30am: Waiting 10s before trying again
9:30am: Sending Result: SendRequest to shserver2.ssl.berkeley.edu failed: Connection Timeout
9:30am: Queued passthrough request
9:30am: Sending result 27no03aa.25808.5520.940902.218


Each time a good WU gets completed, SetiDriver (SetiHide) will again attempt to transmit the DEFECTIVE WU along with the good one and each time it (the defective WU) gets rejected. Imagine hundreds of these DEFECTIVE WUs being transmitted to a SetiQueue over and over again. It clogs up the works.

If you are a user of a SETIQUEUE, do your Q operator a big favor and check your Seti Computers for these defective WUs.

Thank you.

 

[Rattledagger]

I see the "problem results" slowly is increasing, and is now upto 333. Since all is marked as doublets it's very likely all of the 1349 wu is already uploaded either by his own queue directly to Berkeley, or through another public queue.
I've never seen anything to that Smoke is talking about, but since these results is uploaded from another setiqueue & gives doublet-error it can't be the same error. Therefore I would personally have deleted all of these results, but if you don't wants to be so drastic you can make a new setiq-install & move all the results to this and let this queue have the problem uploading all the doublets. This way your public queue can be up and running as normal again.

BTW, since Q000D, E & F all is getting their results from the same external SetiQueue I would also disable these queues. Anyone knows who esilent is? This is the only of these 3 queues that currently has got a name...

 

[Woodie]

OK, how do I delete results?

 

[Smoke]

You must be replying to RD for I included instructions in my post.

After inspecting your LOGS I don't see any defective WUs ... only DUPLICATES. So my suggestions about the DEFECTIVE WUs is still something that all Seti Users should check on their computers but it has nothing to do with your current predicament.

Damn, that is really strange how it has your Q clogged.

Try this. Shut down the Q.

Explore to your SetiQueue Folder and open the CLIENT FOLDER. In there you will find a DUPLICATE FOLDER. Delete everything in it and then restart the Q. While you are at it you could also delete the USERS/ in Queues Q000F (4796509), Q000E (4683123), and if that doesn't clear things up I'd also delete USER/ Queue Q000B (Chrisinelpaso).

Restart the Q and tell us what happens next.

 

[Coolkid]

Originally posted by: Woodie
OK, how do I delete results?

You will need to find the specific user and queue directories (which i think would be 4796509/Q000F in your case) and manually delete all the results files for that queue.
You could also just delete those users directories completely to remove the users.
I'm pretty sure thats right as i cant check my queue as i'm in class at the moment, but im sure someone will correct me if thats wrong

 

[Freewolf]

Sounds right to me and those problem results are up to 397 now and still climbing. Sounds to me like someone used your q to try and get a bunch of dups sent in. If it was me I think I would send an email to the seti people with the id# of the guy who did it. They have been checking on some of the people in the top 1000 again and some of them have had their accounts either removed or the number of results adjusted.

 

[Smoke]

I was editing my post and I see Coolkid and Freewolf have suggested pretty much what I was thinking about.

Another edit:

I actually went to bed and have gotten up to make a suggestion to all of our public Q Operators.

I think it would be best if we all disabled the ability of new USERS to join our SetiQueues.

New User Priority: Queues Disabled

If we have a new CLIENT that wants to use our Qs, it can be arranged via a PM or email where we could open the Qs just long enough for them to get recognized and then close them to new CLIENTS immediately thereafter.

We are all open to having our Qs completely screwed up just like Woodie's. I understand Freewolf's comments about people dumping old WUs in an attempt to pad their stats right near the end of Seti-Classic but it could also be that someone just wants to mess up our Qs.

I've DISABLED my Q concerning acceptance of new USERS. I'll gladly accommodate any new users but they will need to contact me first.

 

[Woodie]

OK, I'll try deleting some of the folders tonight, see how it goes.

For the moment, I turned off New Users (queues disabled), and set the priority to "Upload Results".

I'm not worried about Chrisinelpaso or helpme...I'll disable those queues in a couple days, once I'm sure my whole fleet is not working for them any more.

Thanks for your input, everyone!

 

[Rattledagger]

All results arrived to a SetiQueue but not sent to Berkeley is always residing under setiqueue\CLIENT


Results that has been rejected 2 or 3 times is moved to client\dublicates if doublet, or some other directory if another error. These results will not be trying to re-upload, so for all purposes setiqueue doesn't know of these.
Also, if you've set "save a copy of all results" this is on successive upload placed in client\history

So to the actual results:
In CLIENT there is 1 client.ini, log_2004-05-05.txt and older, 1 result.csv
and many pairs of result_1234 & result_1234.ini
To move all results to another install will therefore be to move all client\result_*

Of course, since others is also using your queue, you can't just delete all result_* to remove the bad, but most of the bad is limited to a fairly short upload-interwall so should be after eachother alphabetically.
Note, since *.ini is updated then tried to upload & got the doublet-error, you can't just sort them by time.
Oh, and there are no special naming or sub-dividing in sub-directories of result_* so the only way to know who has uploaded this result is to look on user_id=1234567 inside the file...


Smoke's idea of disallowing new users is a great idea, and hopefully it work as it should. As for manually deleting any of the user.1234567-directories manually isn't necessary, since "Tools/Delete a client" is much easier method.


Looking on the queue, there are currently 5 dropped doublets, so therefore 10 files in client\duplicats.
Problems results queued is upto 482, if not completely mistaken this will increase till all 1349 and then will re-try all the doublets... I don't remember if it's 2nd or 3rd time they will be dropped, so... From the look of the speed most likely Berkeley will accept some of them on 2nd pass-through...

 

[Woodie]

ok, so I used the find command, and deleted all the units that were "ErrorCount=0" in the results.ini file.

Then, I went through and removed 98% of the results that had LHASA in them. I still have 181 results queued, and only 7 "bad" ones listed. Somehow, there were still some 20 results from one of the LHASA clients, and they also seem to be dupes (based on them turning to a RED background in the results section.)

I'll check back in a bit.

 

[Coquito]

You found my wus. Thank you.

 

[Woodie]

All better now...all the results went through, even the 17-odd leftovers from LHASA. Those 17 were all dupes, but at least they got processed overnight, so aren't clogging up the queue anymore.

Coquito: Yours were still there, just a bit buried! (Along w/ BUNCH of mine.)

Thanks all for your assistance!