64KB Output filesize limitation

I downloaded the data file, and it's 404 KB in size (compared to the normal 367 KB)

There are a vast number of <coordinate_t> elements in the data header, but otherwise - on a relatively casual glance - it looks normal.

I have a number of other abnormally-sized data files in my cache:

404 KB from
29se11aa.2171.2382
29se11aa.21883.2382 (like yours)

392 KB from
29se11aa.12895.2484
29se11aa.20678.2484

all downloaded between about 16:30 and 20:00 on Wednesday 11 April.

That does sound like another splitter problem worth drawing to Jeff's attention - anyone like to add some extra observations while I go out on a short errand? Then I'll do a full report when I get back.

Edit - put in fuller identification numbers, not all sequences from that tape are affected.

I had one from that same 29se11aa.21883 group a few days ago. Which I didn't think much of at the time. Checking the file it was 404KB like the one you checked as well.

Looking at the tasks on my systems it looks like it can be further narrowed down to 29se11aa.21883.2382.12.10

I found these hanging out on one of my systems.

The ones I've found have all been shorties - 14-day deadlines, typical of VHAR.

In fact, they seem to be VVHAR - the one Lt linked has AR=55, I've just looked at an AR=57 here.

The ones I've found have all been shorties - 14-day deadlines, typical of VHAR.

In fact, they seem to be VVHAR - the one Lt linked has AR=55, I've just looked at an AR=57 here.

The ones I've found have all been shorties - 14-day deadlines, typical of VHAR.

In fact, they seem to be VVHAR - the one Lt linked has AR=55, I've just looked at an AR=57 here.

Unless this is one of those cases where it is an issue when using the opt apps. Looking at the 4 that Lint trap had. The stock app seems to have completed the tasks OK & the opt app ended up with the -131.

By completed OK, you mean the output filesize didn't exceed the limit ?

If it's just a case of the Opt-apps being too wordy, perhaps Lunatics could check for that and somehow limit the output text to stay under 64KB, or, the limit could be changed ?

The ones I've found have all been shorties - 14-day deadlines, typical of VHAR.

In fact, they seem to be VVHAR - the one Lt linked has AR=55, I've just looked at an AR=57 here.

Hmm, for the one HAL9000 linked, the first two coordinate sets are

<coordinate_t> <time>2455834.2627723</time> <ra>15.211767558555</ra> <dec>18.111415397339</dec> </coordinate_t> <coordinate_t> <time>2455834.4264586</time> <ra>19.048461812708</ra> <dec>17.949663297908</dec> </coordinate_t>

Almost all the AR=56 is in that pair, they're nearly 4 hours apart in both time and ra.

The 368 coordinate sets make the header section 58562 bytes, so adding a few signals to that size header can easily make a result file over 65536.

Joe

Some extra observations:

These finished with -131 errors:

29se11aa.21883.2382.12.10.68_0_0
29se11aa.21883.2382.12.10.65_1_0
29se11aa.21883.2382.12.10.43_0_0
29se11aa.14713.2382.7.10.160_0_0
29se11aa.14713.2382.7.10.143_0_0

This is in cache at 404Kb

29se11aa.29304.2382.9.10.230


Cheers
____________
AndrewM

Unless this is one of those cases where it is an issue when using the opt apps. Looking at the 4 that Lint trap had. The stock app seems to have completed the tasks OK & the opt app ended up with the -131.

By completed OK, you mean the output filesize didn't exceed the limit ?

If it's just a case of the Opt-apps being too wordy, perhaps Lunatics could check for that and somehow limit the output text to stay under 64KB, or, the limit could be changed ?

No, it wouldn't help.

The wordy Lunatics stuff is in stderr_txt, which gets sent to the server by a different channel when you report the task.

The 64KB limit is on the uploaded result file which one would expect to be identical - that's the intention, anyway, otherwise the results won't validate.

Unless there's something subtle like the stock app producing a file with Unix-style line endings (CR only), and the Opti apps using Windows line endings (CR-LF). In a file with a lot of short lines, that can make a big difference.

...
Unless there's something subtle like the stock app producing a file with Unix-style line endings (CR only), and the Opti apps using Windows line endings (CR-LF). In a file with a lot of short lines, that can make a big difference.

If it would help anything. I could setup a system to process the 7 files I saved with each app and then zip up the result files for someone to grab and look over.