stephenbrooks.orgForumMuon1General1 result uploads
Username: Password:
Search site:
Subscribe to thread via RSS
2006-09-20 08:19:33
If this has already been dealt with - sorry for the dupe... but I glanced over the threads and didn't see
any topics yet about this.

I'm noticing that people are getting "1" result uploads.  I've experienced this when using the HTTP upload
on my server.  It sends one result, and leaves the rest in the temporary file - never to be counted unless
you rename the file, and re-upload.

Had this happen 3 times in a row on my WIN2003 server.  When I switched back to FTP - it worked fine.
Can't identify the specific circumstances - just that I had to switch it back, because I couldn't get anything
to upload.  Since the minimum manual upload cannot be < 10K - We can safely assume that these uploads
aren't actually 1 result... ergo - do we have a potential bug, or is it operator error?
Stephen Brooks
2006-09-20 14:44:02
Does this happen on many machines or just one particular one?
2006-09-20 15:19:22
I've never experienced such thing so far with my XP server, all http and ftp results are fine as far as I can tell.  Do those files have a certain size?  The lowest sizes in my recycle bin is usually starting at 12 kB.  A bug would be quite questionable I think because then every http upload should be "1 result" (as far as I see it).  All my own results sent to my own server or any of the other 3 on the serverpage (Stephen,wmikrut and Whitepanther's) never got miscounted, so might be a misconfiguration somewhere.
2006-09-21 08:29:25

I've seen it happen on more than one machine.  My own XP Pro behind a LinkSys - running Zonealarm, and without Zonealarm.  Same result on an Win2003 SBS server.  Can't do squat HTTP - and (can be reproduced) will upload (1) result, and leave the remaining results in the binary file.

I just noticed a bunch of single-result files come through on my teammates submissions on 9/17. Again - since we "know" that files less than 10Kb will not be uploaded, then there is an "issue" in my mind if we're getting a bunch of one-result files.  That means that somewhere - alot of results aren't being counted - nor are they being included in the research if 99% of the file sits in perpetuity.

Just want to be sure the results (regardless of who crunches them) make it into the research - and of course, the STATS! 

2006-09-21 08:33:45

These would typically be pretty big upload files.  (We) tend to hold results until we have massive uploads to submit.  I've typically seen this happen with > 10MB result files.  It's probably not an issue for most crunchers that do daily submissions.  For those of us who will allow a machine to crunch for a month or more without even visiting it - are the ones who will be impacted by this.  I'm not certain if it's the size of the file - or the OS running it.  I suspect it's file size... not something likely to be extensively tested.  The results files speak for themselves though.  If there's a one-result upload - then how?... and what happened to the rest of the file?  That's all I'm pointing out.  It's a little weird.
Stephen Brooks
2006-09-21 11:40:44
You've probably done this already, but just check you've made an exception for muon1 in the Windows firewall on those machines (as well as in ZoneAlarm etc.), if it's turned on.
2006-09-21 15:11:31
If u suspect it is because of very large results files, u might check if u allowed Apache sufficient large file uploads else Apache will not allow uploadresults.php to be executed after the whole results file has been uploaded (hence the uploaded result's temporary file will be discarded).  The sent results file will stay on the user's machine as the *.bin I believe.  Usually there should be a log notice of it in error.log in your Apache directory.  What is your following line in php.ini?  (especially the last line is important):

; File Uploads ;

; Whether to allow HTTP file uploads.
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
upload_tmp_dir = "c:\*\temp"

; Maximum allowed size for uploaded files.
upload_max_filesize = 25M
2006-09-21 15:13:40
Oh and also the following in de the php.ini:

; Maximum size of POST data that PHP will accept.
post_max_size = 25M
2006-09-22 02:35:49
This issue appears to be across machines, and across OS. 
Here's the DPC production for 9/20 -

Users die vandaag geflusht hebben: 96 / 366 = 26,23%
Position Daily Name Total Overall
1() 82.890 Team ColdFusion 193.288.654 (1)
2(2) 30.936 Dudes@TheBenny 20.129.878 (14)
3(2) 29.837 snoekbaars 5.027.953 (30)
4(3) 20.212 NoizyCows 73.272.209 (5)
5(1) 16.052 White Panther 33.520.798 (8)
6(3) 14.396 DanC 25.134.439 (11)
7(2) 9.085 Supersymmetry 13.361.989 (21)
8(6) 6.918 TEB 22.964.360 (12)
9(1) 5.678 MmmBeer 573.116 (86)
10(2) 4.192 Spoefke 9.438.010 (23)
11() 1.420 Xanathorn 13.425.386 (20)
12(3) 1 Stephan P 78.427 (158)
13() 1 Poekie 5.143.858 (29)
14(2) 1 TNG 1.843.395 (49)
15(4) 1 RiLekst 355.730 (103)
16(2) 1 Riball 36.507 (179)
17(1) 1 Praetorian 10.298 (221)
18(1) 1 RGR 4.201 (237)
19(5) 1 TheBorg 992.713 (69)
20() 1 Herr Otto 54.360 (169)
21() 1 Honda MT racer 19.443 (200)
22() 1 iago 2.304 (248)
23() 1 IceClub 1.219.925 (62)
24() 1 Jintram 130.407 (139)
25() 1 Joon 848.477 (76)
26() 1 Keesmo 1.462.832 (57)
27() 1 Nyarlathotep 69.006 (161)
28() 1 Peter-web 215.576 (121)
29() 1 Peter Tijsma 511.958 (92)
30() 1 TRiON 3.784 (240)
Total: 221.697

It would be interesting to see what actually transpired in the logs if they can be ID'd. When this has happened, my sendlog will show that one result was uploaded.  This is a little disconcerting when you just submitted a 10MB results.txt, and see 1 result.
When you look in the muon folder though... there is the remaining 9.98 MB file - and my best guess is that those results are never seen, unless manually renamed to results.txt and re-uploaded.

Doesn't take long before you've set aside quite a few Mpts.  Just a thought -
Stephen Brooks
2006-09-22 10:42:12
The HTTP send is certainly designed to send only the initial segment of the results, but it sounds like there might be a logic error in there under some circumstances.  I will check it anyway.  If I can't replicate the error I may need one of your files via e-mail to see what is going on.
2006-09-26 04:41:48

I've been advised that these particular results are a bug in our stats generator - but the anomaly has nonetheless occurred.
I' have been able to work around it, and hence it may not indeed be that much of an issue.

Probably better that you focus on the science - and us stats freaks will worry about the little stuff. 
Thanks for looking into it - but I may have made more of it than need be - given what we now know.
Stephen Brooks
2006-09-26 12:08:48
A bug in whose stats generator - mine or DPC's?
2006-09-26 14:35:02
DPC's. You're doing just fine. 
: contact : - - -
E-mail: sbstrudel characterstephenbrooks.orgTwitter: stephenjbrooksMastodon: strudel charactersjbstrudel

Site has had 16975597 accesses.