An easy way to make modem users happy would be to compress the downloaded wu and the uploaded result. Eventhough this will help all users, modem users would get the most out of this.

As an example I made the following calculations based on my situation at home. I run seti at 90% share and I conect once a day for approximately 40 minutes to download around 25 wu and upload 25 results.

This means I download 354kb * 25 = 8850kb and upload 8kb * 25 = 200, a total of 9050kb.

If both these files types were compressed it would be: download 266kb * 25 = 6650kb and upload 2kb * 25 = 50, a total of 6700kb. This is a 26% reduction in data sent and received which would also represent around a 26% reduction in conection time.

Not only we would need to be conected less time, for us that dont have a flat internet rate, would be a 26% reduction in our internet bill.

Is it possible to do this?

Roberto

---

An easy way to make modem users happy would be to compress the downloaded wu and the uploaded result. Eventhough this will help all users, modem users would get the most out of this.

As an example I made the following calculations based on my situation at home. I run seti at 90% share and I conect once a day for approximately 40 minutes to download around 25 wu and upload 25 results.

This means I download 354kb * 25 = 8850kb and upload 8kb * 25 = 200, a total of 9050kb.

If both these files types were compressed it would be: download 266kb * 25 = 6650kb and upload 2kb * 25 = 50, a total of 6700kb. This is a 26% reduction in data sent and received which would also represent around a 26% reduction in conection time.

Not only we would need to be conected less time, for us that dont have a flat internet rate, would be a 26% reduction in our internet bill.

Is it possible to do this?

Roberto

Roberto,
It is unlikely that you would see much of an improvement.
The reason is that (most) modems already use dynamic data compression algorithms, which are not far short of ZIP compression.
Although the number of bytes recorded as transferred would go down, the real throughput over the analogue circuit would change very little.
Couple the fact that the savings would be minimal with the extra server load ZIPping the files and it's unlikely to be seen as an overall benefit.

/Edit
There would be some benefit on the main internet data link at Berkeley, but again, the extra server load would probably offset any gain.

---

An easy way to make modem users happy would be to compress the downloaded wu and the uploaded result. Eventhough this will help all users, modem users would get the most out of this.

As an example I made the following calculations based on my situation at home. I run seti at 90% share and I conect once a day for approximately 40 minutes to download around 25 wu and upload 25 results.

This means I download 354kb * 25 = 8850kb and upload 8kb * 25 = 200, a total of 9050kb.

If both these files types were compressed it would be: download 266kb * 25 = 6650kb and upload 2kb * 25 = 50, a total of 6700kb. This is a 26% reduction in data sent and received which would also represent around a 26% reduction in conection time.

Not only we would need to be conected less time, for us that dont have a flat internet rate, would be a 26% reduction in our internet bill.

Is it possible to do this?

Roberto

Roberto,
It is unlikely that you would see much of an improvement.
The reason is that (most) modems already use dynamic data compression algorithms, which are not far short of ZIP compression.
Although the number of bytes recorded as transferred would go down, the real throughput over the analogue circuit would change very little.
Couple the fact that the savings would be minimal with the extra server load ZIPping the files and it's unlikely to be seen as an overall benefit.

/Edit
There would be some benefit on the main internet data link at Berkeley, but again, the extra server load would probably offset any gain.

But then again, it is not the server that seems to be the bottleneck that would be doing the zip. That would most likely be done by a splitter (for download at least) and Berkeley could just add another one if it started being a problem. It would be more difficult on upload than download as it would be the verifier that would do the unzip, and the verifier is quite often behind.

---

BOINC WIKI

The reason is that (most) modems already use dynamic data compression algorithms, which are not far short of ZIP compression.
Although the number of bytes recorded as transferred would go down, the real throughput over the analogue circuit would change very little.

Ok, but for people that are charged per bits trasferred, this could mean 25% reduction on their bill, or could mean they dont reach their maximun monthly transfer capacity. And it feels the right way to do it.

But then again, it is not the server that seems to be the bottleneck that would be doing the zip. That would most likely be done by a splitter (for download at least) and Berkeley could just add another one if it started being a problem. It would be more difficult on upload than download as it would be the verifier that would do the unzip, and the verifier is quite often behind.

Ok, lets forget about the results upload, just zip the downloaded wu's. If I recall correctly Einstein already does this.

---

Climate Prediction does this for both their downloaded and uploaded files.

---

Climate Prediction does this for both their downloaded and uploaded files.

True, but then CPDN does not have nearly as many results comming back. They have a smaller user base, and the results take a few weeks to compute rather than a few hours.

---

BOINC WIKI

I know that. But the result file is bigger than the usual ones around on other projects, although you're luckily don't have to send in the 600MB file. ;)

---

We are getting of track here, the reference to Einstein (or CPDN) doing it was just to show it is supported in the Boinc API and therefore should be easy to implement.

From the responses I see there seems to be no drawbacks and only advantages.

---

A few points/questions.

Is it true that anyone still pays by the second for dial-up? I don't know - here in the UK we pay so much for a X minute call, pay the same if use the X minutes or not.

I can see that a 25% bandwidth usage/data count could make economic sense to Berkeley.

Berkeley send the WU as a text representation (uuencode or similar?) of binary data. A ZIP would obviously be a binary data transfer. Is there a reason why text transfer was chosen???
Platform Compatibility? Would they need to send ZIPs, TARs, GZips or whatever depending on the platform?
(Yes, Einstein do send ZIPs)

Open Source compress/decompress libraries??

ZIP formats would (probably) ensure/confirm data integrity in transmission.

Any security issues with some sites over binary transfers?

---

Is it true that anyone still pays by the second for dial-up? I don't know - here in the UK we pay so much for a X minute call, pay the same if use the X minutes or not.

I can see that a 25% bandwidth usage/data count could make economic sense to Berkeley.

Here in Uruguay what we pay has two components:

a) the phone charge. Every x minutes (depends on the time of day, goes from 2 to 6) a "computo" is charged.
b) the internet charge. This depends on the plan, you can get charged by the minute, have flat rate or in my case get it free from the bank my credit card is issued.

So reducing the conection time will lower my bill (component a))

Now I will change to ADSL, using a rate that is flat, but allows upto 1GB monthly data transfer, so zipping the wu will leave more data for other things (web sufring, email, etc).

---

From the responses I see there seems to be no drawbacks and only advantages.

You still have more overhead on the server for a compressed up-load (however on the download side it does make sense). IIRC the splitters keep up pretty well with their current load, there might be enough room there to implament this. The result uploads are smaller (10-12Kb), I kinda doubt that the benefit would justify the overhead on the servers.

Using your numbers, compressing the downloads only: download 266kb*25=6650 and upload 8kb*25=200. That totals 6850kb, a 24% reduction, with all the overhead on the splitters. I think your on to something here, and it'll benefit everyone, not just dial-up users.

I'd like to hear what the dev team has to say about this.

---

Still looking for something profound or inspirational to place here.

Now I will change to ADSL, using a rate that is flat, but allows upto 1GB monthly data transfer, so zipping the wu will leave more data for other things (web sufring, email, etc).

1Gb a month - boy that's mean!
I have done that much in a week-end on 56K dial-up ;)
ADSL in the UK is generally 15-25 UKP/month with 6-20Gb /month.
Unlimited flat-rate dial-up can be had for ~12 UKP

I can see your interest in cutting the data to a minimum.

Somewhere, there is a Proxy site, that does this - you install a client at your end, browse through their servers and they compress ans forward everything to you and your end uncompresses.
The one I came across I think was free - but no one is getting to read everything I send/receive free or not, so I'm definiate no for this type of operation.

That said, it does suggest the psssibility of adding a compression layer between the project servers and the hosts, rather than acrually zipping and un-zipping files.

---

Now I will change to ADSL, using a rate that is flat, but allows upto 1GB monthly data transfer, so zipping the wu will leave more data for other things (web sufring, email, etc).

1Gb a month - boy that's mean!
I have done that much in a week-end on 56K dial-up ;)
ADSL in the UK is generally 15-25 UKP/month with 6-20Gb /month.
Unlimited flat-rate dial-up can be had for ~12 UKP

Well, this is for the cheapest plan. This 1GB plan is US$ 20 per months, there are more expensive plans.

---