I reprocessed today's port 5000 results.txt - I think you will find it not wanting. :wink:
Now to reprocess all the rest, reconvert everything, get Bok to purge the bogus .csv files, re-import everything, bang head several times, get C443 results in there, double check the 7000 and 7500 orginal results.txt to make sure none have the swapped k/n for n/k values etc., bang head several more times, take several asprins, double and triple check the output files, relax... not necessarily in that order :wink:

[quote=IronBits;148357]I reprocessed today's port 5000 results.txt - I think you will find it not wanting. :wink:
Now to reprocess all the rest, reconvert everything, get Bok to purge the bogus .csv files, re-import everything, bang head several times, get C443 results in there, double check the 7000 and 7500 orginal results.txt to make sure none have the swapped k/n for n/k values etc., bang head several more times, take several asprins, double and triple check the output files, relax... not necessarily in that order :wink:[/quote]


Thanks for yours and Bok's tremendous effort on this David! :smile:

I'm trying to nip any problem in the bud before it goes too far...

I am seeing no results returned for the range of n=559950 thru 560000 for port 5000 even though we are well past that range now. This is 103 k/n pairs with no returned results to the server many hours after they should have!

Did someone grab a bunch of k/n pairs for manual processing that will be returned to the server in the next few hours? If so, that is OK.

I'm asking because this is the tail end of the n=555000 thru 560000 file that I sent to David that ended up being put into the server out of order. Before completing the 3rd drive, I'm wanting to see if some other problem has now come up with it.

It seems very unusual that the missing results just happen to be right at the end of this problem file.


Gary

Find it here? I found 559990 in it...
[url]http://nplb.ironbits.net/results/results_20081107_0657_IB_nplb_5000.txt[/url]

[quote=IronBits;148502]Find it here? I found 559990 in it...
[URL]http://nplb.ironbits.net/results/results_20081107_0657_IB_nplb_5000.txt[/URL][/quote]


Oh, never mind. It was just Max doing his 'grab a whole bunch of work and return it all at once several hours later' thing again just to confuse me. lol

Thanks for checking.


G

[quote=gd_barnes;148567]Oh, never mind. It was just Max doing his 'grab a whole bunch of work and return it all at once several hours later' thing again just to confuse me. lol

Thanks for checking.


G[/quote]
Eh? I don't remember grabbing a bunch of work and returning it several hours later. Unless that's just the ~20 or so results that I had in cache from when I went on my trip? (I usually prefer to do manual LLR while I'm away, since my internet connection can be unreliable at times; this time, however, I simply increased my LLRnet caches to larger amounts, 20 in the case of my port 5000 client.) I never bothered to decrease the cache size after I got back, so all my results since then would have been returned at least several hours after they were originally reserved. (Also, I had turned my computer off for a few hours sometime after I had gotten back--that may have casued an additional delay in some of the reserved k/n pairs.)

At any rate, my port 5000 client's cache is now completely empty, so there should be no remaining k/n pairs in the server that are reserved by me. :smile:

[quote=mdettweiler;148570]Eh? I don't remember grabbing a bunch of work and returning it several hours later. Unless that's just the ~20 or so results that I had in cache from when I went on my trip? (I usually prefer to do manual LLR while I'm away, since my internet connection can be unreliable at times; this time, however, I simply increased my LLRnet caches to larger amounts, 20 in the case of my port 5000 client.) I never bothered to decrease the cache size after I got back, so all my results since then would have been returned at least several hours after they were originally reserved. (Also, I had turned my computer off for a few hours sometime after I had gotten back--that may have casued an additional delay in some of the reserved k/n pairs.)

At any rate, my port 5000 client's cache is now completely empty, so there should be no remaining k/n pairs in the server that are reserved by me. :smile:[/quote]


Max,

I just checked again and it took me a while to figure out what happened. You processed a range from the server several DAYS before it was handed out!! The n=559950-560000 range that contained 103 pairs was processed by you on Nov. 5th and 6th. The server was handing out that range on Nov. 8th and 9th. That is why I thought it hadn't been processed yet. I kept looking for it in the 8th and 9th results files.

Can you explain how this could happen? The only thing I could figure is that you took a small range from the original sieve file, processed it, and then returned the results to the server before it handed the pairs out. If that is the case, I would prefer that we not do that. It kind of defeats the purpose of a server. It's better to just cache 100 work units that are being handed out currently by the server. The job max time of 3 days should now allow for relatively large caches such as this, even for slower machines.


Thanks,
Gary

[quote=gd_barnes;148576]Max,

I just checked again and it took me a while to figure out what happened. You processed a range from the server several DAYS before it was handed out!! The n=559950-560000 range that contained 103 pairs was processed by you on Nov. 5th and 6th. The server was handing out that range on Nov. 8th and 9th. That is why I thought it hadn't been processed yet. I kept looking for it in the 8th and 9th results files.

Can you explain how this could happen? The only thing I could figure is that you took a small range from the original sieve file, processed it, and then returned the results to the server before it handed the pairs out. If that is the case, I would prefer that we not do that. It kind of defeats the purpose of a server. It's better to just cache 100 work units that are being handed out currently by the server.


Thanks,
Gary[/quote]
LOL--yes, that's what I did. I took a hundred or so k/n pairs from the original sieve file, processed them, and returned them to the server. My original goal was to try to chip away at the 550K-560K range ahead of time, it having been inserted into knpairs.txt after higher ranges as you are of course already aware of. I guess it probably didn't accomplish much, though, since my 100 or so k/n pairs were just a drop in the bucket compared to the whole 550K-560K range. :rolleyes:

This also is why all of those results came in with a time of "0.0 sec."--because, since the server had never originally assigned the k/n pairs to me, it of course couldn't put down the amount of time that had elapsed between the reservation of the k/n pairs and the returning of the results. :smile:

Anyway, I won't due that again since it accomplishes nothing except process a few k/n pairs out of order, which ends up making for some confusion later on. :smile: I hadn't originally expected this to cause any problems, since usually when I process my results, I just have one of my Perl scripts separate the particular range I'm interested in from a much larger results file containing all the results for the past few months or so, and then process that (rather than downloading a that past [i]x[/i] results files from the web page and then dealing with that.) Of course, there's no reason for me to expect Gary's processing routine to operate the same way, so I should have considered that before processing these k/n pairs out of order. :rolleyes:

[quote=mdettweiler;148577]LOL--yes, that's what I did. I took a hundred or so k/n pairs from the original sieve file, processed them, and returned them to the server. My original goal was to try to chip away at the 550K-560K range ahead of time, it having been inserted into knpairs.txt after higher ranges as you are of course already aware of. I guess it probably didn't accomplish much, though, since my 100 or so k/n pairs were just a drop in the bucket compared to the whole 550K-560K range. :rolleyes:

This also is why all of those results came in with a time of "0.0 sec."--because, since the server had never originally assigned the k/n pairs to me, it of course couldn't put down the amount of time that had elapsed between the reservation of the k/n pairs and the returning of the results. :smile:

Anyway, I won't due that again since it accomplishes nothing except process a few k/n pairs out of order, which ends up making for some confusion later on. :smile: I hadn't originally expected this to cause any problems, since usually when I process my results, I just have one of my Perl scripts separate the particular range I'm interested in from a much larger results file containing all the results for the past few months or so, and then process that (rather than downloading a that past [I]x[/I] results files from the web page and then dealing with that.) Of course, there's no reason for me to expect Gary's processing routine to operate the same way, so I should have considered that before processing these k/n pairs out of order. :rolleyes:[/quote]


Actually, it's just me being WAY too anal. lmao

No problem. I see why you did it.

I don't have any 'processing routine' so to speak of the results. I generally ignore what comes in, other then to see what n-range is currently being handed out, until a server nears its drying point. Then I attempt to nip any problems in the bud ahead of time by seeing if any ranges are missing. This appeared to be a problem that wasn't.

Thanks for the info.


Gary

David,

Two things:

1. Can you make it a priority to fix the verbiage in the results file when a prime is found? It needs to show "is prime!" as well as the CPU time. Besides affecting Karsten's scripts, it has also affected one of Max's scripts. Looking for "is prime" is fairly common when automating the processing of results.

2. Can you leave the info. up on your web page for a port for 1-2 weeks after it has dried? Because Max's scripts didn't work correctly when creating results files for processing to me, I'm having a difficult time finding a couple of primes in the file in the manner that I normally would, i.e. by just doing a find on "prime!". Regardless of that, frequently there will be something that I/we need to refer to right after the drive is done.


Max,

Your results processing script didn't work correctly because of the problem above. Can you fix that and resend the file to me? Where the server results files that had primes were coming out without the "is" verbiage and the CPU time, they are showing as "not prime" in your file. There are at least 2 of those.

I could verify them by looking at the port 5000 primes here but the page that shows them is already gone. I could also go back through many days of results for port 5000 but that would take too long.

Edit: There were 4 primes shown as not prime. But there could be more. I could only go by what we had posted in our thread here and the top-5000 site. In other words, I really couldn't verify the primes in the results.

Thanks guys.


Gary

[quote=gd_barnes;148899]David,

Two things:

1. Can you make it a priority to fix the verbiage in the results file when a prime is found? It needs to show "is prime!" as well as the CPU time. Besides affecting Karsten's scripts, it has also affected one of Max's scripts. Looking for "is prime" is fairly common when automating the processing of results.

2. Can you leave the info. up on your web page for a port for 1-2 weeks after it has dried? Because Max's scripts didn't work correctly when creating results files for processing to me, I'm having a difficult time finding a couple of primes in the file in the manner that I normally would, i.e. by just doing a find on "prime!". Regardless of that, frequently there will be something that I/we need to refer to right after the drive is done.


Max,

Your results processing script didn't work correctly because of the problem above. Can you fix that and resend the file to me? Where the server results files that had primes were coming out without the "is" verbiage and the CPU time, they are showing as "not prime" in your file. There are at least 2 of those.

I could verify them by looking at the port 5000 primes here but the page that shows them is already gone. I could also go back through many days of results for port 5000 but that would take too long.

Edit: There were 4 primes shown as not prime. But there could be more. I could only go by what we had posted in our thread here and the top-5000 site. In other words, I really couldn't verify the primes in the results.

Thanks guys.


Gary[/quote]
First of all, here's a link to the port 5000 primes list, in case this helps:

[url]http://nplb.ironbits.net/primes_5000.txt[/url]
(even though the link was taken offline, I was still able to get to it by reverse-engineering the URL to the port 400 primes list. :smile:)

Secondly, I just took a look at the results file I sent you from my Sent Items folder, and I found that the lines for primes that are erroneously listed as "not prime" all contain this exact string of text where the "is prime! Time :" string should be:

"is not prime. LLR Res64: Time : "

Thus, I can do a search/replace on that string, replacing it with "is prime! Time : 0.0 sec." The times are not important, since they are practically useless anyway. Thus, a quick search/replace of this sort produces the desired effect. :smile:

I'll email you the results, fixed using the above method, shortly. :smile:

Max :smile: