Base64 encoding increases the size of the raw data by about 37%, and is unnecessary because XML supports binary octets as CDATA.
Why not use it? The WUs don't have to go through ancient mailservers, and transfer is point to point, so there are no barriers apart from will.

Base64 encoding increases the size of the raw data by about 37%, and is unnecessary because XML supports binary octets as CDATA.
Why not use it? The WUs don't have to go through ancient mailservers, and transfer is point to point, so there are no barriers apart from will.

Exactly as has been done with Astropulse workunit files, since the very start of that sub-project.

It's entirely up to the lab staff how they handle it, but either compression or raw CDATA for MB would shave ~30% off that part of the project's download requirements. Whether modifying the splitter code to generate CDATA format, or post-processing the existing format with compression, I'll leave to them. I'll only mention that post-processing would also compress the (non-trivial) XML header, whereas CDATA would not.

Yeah, I thought so when the bandwidth suddenly became maxed out again. However, we're soon running out of files to split, so unless more are added, the raise is more academic really :-)

I don't care much for myself. My machines have WU's to last them well over the next three day outage.Too much hormone treated meat.
Too much Monsanto veggies.
Too old and outdated constitution.
A crazy problem, as you Yanks use to say......There is no God, and God never existed.

It's entirely up to the lab staff how they handle it, but either compression or raw CDATA for MB would shave ~30% off that part of the project's download requirements. Whether modifying the splitter code to generate CDATA format, or post-processing the existing format with compression, I'll leave to them. I'll only mention that post-processing would also compress the (non-trivial) XML header, whereas CDATA would not.

Could either compress as is, or do a cdata version and compress that too, the xml header would be compressed in both cases, even if the payload grows a bit.

A quick test - I converted an existing wu, decompressed the payload with ascii85 and made a cdata version:

Interesting in this case that gzipping the current format WUs made a smaller file.
So, all they need to do is make and store the current WUs as gz and add Content-Encoding: gzip to the http header on transfer, and all should be fine.

that's nice, but there is very little work to be split. please feed the splitters.

Please enjoy your Saturday night away from the lab.

I agree. There is no reason whatsoever that the staff should bother about this small insignificant problem of no work to send out, on a weekend. Anyone who disagree with that should immediately sign up to baby sit the servers at the lab on weekends, for no pay whatsoever.

Nobody is going to die if their computers doesn't get fed with WU's on a weekend. That is really a NON ISSUE.

Edit: PS. It's snowing like mad here. According to weather statistics, this is so far the coldest winter in this part of Sweden for over 150 years. That my friends is much more important than a temporary lack of WU's :-)Too much hormone treated meat.
Too much Monsanto veggies.
Too old and outdated constitution.
A crazy problem, as you Yanks use to say......There is no God, and God never existed.

I agree. There is no reason whatsoever that the staff should bother about this small insignificant problem of no work to send out, on a weekend. Anyone who disagree with that should immediately sign up to baby sit the servers at the lab on weekends, for no pay whatsoever.

Nobody is going to die if their computers doesn't get fed with WU's on a weekend. That is really a NON ISSUE.

Edit: PS. It's snowing like mad here. According to weather statistics, this is so far the coldest winter here in this part of Sweden for over 150 years.

Now we have again two different kind of humans.
Members with enough WUs for at least 6 or 7 days. And members which have maybe only WUs for 3 days - which worry that they can't bridge the next 3 day outage.
I'm the last ones. I guess my PCs will idle during the next 3 day outage, because they will not DL enough WUs from Monday to Tuesday morning (Berkeley time). But nothing for to upset. It's a pity that SETI@home can't use my PCs then.

I would look into the lab at weekends, but what I could do? Clean the lab?
This wouldn't help.
OTOH, Berkeley is too far away from here where I live.

The weather news from my home (Germany/Baden-Württemberg), on the main street no snow, the small street in front of my house with ~ 10 cm snow/ice and melts, the half windshield of my car is closed 50 % with snow (not more snow on the car) and also melts.
From today to mid of the week we will have here + ~ 4 - 6 °C outside at the day. Maybe not white X-Mas.

With the servers running out of work units so fast these days, have there been any thoughts on how to process more work units between each required physical visit to the server room to load tapes or disks of whatever media the raw data is stored on these days?

Is this process already optimized, or would it be possible to perhaps store the data on multiple external hard drives or on it's own separate RAID array?

If it is possible to read and verify the data from the media faster than the machines can initially process said data to create workunits, than it should be possible to build up a store of unprocessed data when humans are available to feed the machine. The "extra" data could then be queued for access whenever one of the splitter CPU's has no available data to make work units from.

Great for weekends, or after outages. Not sure if this would be something that the project would actually want to run full time, as I understand the bottleneck for the actual science is in the post-home-user stages.

However, it appears that Worf is having trouble keeping up with the many kibble bowls to fill.
Might Oscar help him out with the radar blanking work?My body may be here, but my mind is in a galaxy far, far away.

I am not sure how this could be done, but some of us ache for a fairness doctrine as applied to downloaded WUs.

While the system was up for the last couple of weeks, I managed to snag 2 Astropulse and 8-9 Seti Enhanced WUs. Now the my last 6 Seti enhanced WUs are Pending Validation as the second computer is one of the machines that downloads 4-10 WUs per day. Granted most of them get returned inside the window of time, but still, I turn them around in 2 days, and wait 3-6 weeks for validation to happen.

Seti is out of WUs now so my Boinc is working on other projects JUST to stay busy

I am not sure how this could be done, but some of us ache for a fairness doctrine as applied to downloaded WUs.

While the system was up for the last couple of weeks, I managed to snag 2 Astropulse and 8-9 Seti Enhanced WUs. Now the my last 6 Seti enhanced WUs are Pending Validation as the second computer is one of the machines that downloads 4-10 WUs per day. Granted most of them get returned inside the window of time, but still, I turn them around in 2 days, and wait 3-6 weeks for validation to happen.

Seti is out of WUs now so my Boinc is working on other projects JUST to stay busy

I think the "fairness" doctrine is known as "grab and growl". Grab what is there, and growl about it all you want, it will not change a thing.
Janice

how come the people with a low RAC are always ridiculing the people, usually high RAC users, who are almost out of work when they are reporting a problem.

i'm for a more fair work distribution method in which RAC is the basis. machines/users with a higher RAC should be rewarded more work, directly proportional to RAC, during the rationing periods.

then we all could listen to the "computationally challenged" users complain they don't have enough work...

I have a low RAC, Rottenmutt, and I haven't ridiculed anyone. I guess some people with low RAC are unhappy that high RAC crunchers seem to get lots of work units. Personally, as long as I can contribute a little, my life wont end if I run out of WUs for a while. But some folk get very "antsy" about it - just people I suppose - such is life.

Never mind though, SETI is back up and running - that has got to be good.

I see the rationale for having as much seti work as your machine can handle, as the seti folks have had extended downtime over the last several months.

High RAC, low RAC, that all depends on just how many computers you can employ and the relative hotness of each of the machines.

Some of us only have one computer, and that one is several years old. If the High RAC users get all the WUs then we can be shut out.

A slightly better approach would reward users who consistently turn in units that pass validation, turn them in on time, and grade higher for short turn around time. People who fail to turn in units on time get throttled on how many work units they have at one time. People who have compute errors on their work get limited on how many WUs can be outstanding at one time. People who turn in work units well inside the time limit (lets assume that they return them inside 5 days, but sysadmin makes the decision) get rewarded with more WUs.