1 |
Michał Górny posted on Fri, 17 Jan 2014 20:30:00 +0100 as excerpted: |
2 |
|
3 |
> Dnia 2014-01-17, o godz. 19:19:14 Duncan <1i5t5.duncan@×××.net> |
4 |
> napisał(a): |
5 |
> |
6 |
>> Michał Górny posted on Fri, 17 Jan 2014 17:27:30 +0100 as excerpted: |
7 |
>> |
8 |
>> > 96M portage-20140108.sqfs |
9 |
|
10 |
>> > For deltas [...] |
11 |
>> > |
12 |
>> > 6,3M portage-20140109.sqfs-portage-20140110.sqfs.vcdiff.djw |
13 |
|
14 |
>> > applying it takes ~2.5 second on my 2 GHz Athlon64. |
15 |
>> |
16 |
>> diffs are ~1/16 the full squashfs size[.] So people updating once a |
17 |
>> week [or] 10 days would see a bandwidth savings, provided the sync |
18 |
>> script was intelligent enough to apply updates serially. |
19 |
>> |
20 |
>> The breakover point would be roughly an update every two weeks, or |
21 |
>> twice a month |
22 |
> |
23 |
> However, it may be actually beneficial to provide other durations, like |
24 |
> weekly deltas. In my tests, the daily updates for this week summed up to |
25 |
> almost 50M while the weekly was barely 20M. |
26 |
|
27 |
That's useful additional data. Thanks. |
28 |
|
29 |
And yes, a weekly delta would be quite useful, taking the breakover point |
30 |
out to about a month or so. Practically speaking, I'd guess most |
31 |
gentooers update once a month or more, so that should cover the vast |
32 |
majority. Beyond a month, just downloading a new full squashfs makes as |
33 |
much sense anyway, and as the cutover would be automated, users on the |
34 |
borderline wouldn't have to worry about whether they should just do the |
35 |
normal sync or download an entirely new tarball, as they now need to do, |
36 |
if they even bother at all. For those users, it'd be an even BIGGER win. |
37 |
|
38 |
=:^) |
39 |
|
40 |
-- |
41 |
Duncan - List replies preferred. No HTML msgs. |
42 |
"Every nonfree program has a lord, a master -- |
43 |
and if you use the program, he is your master." Richard Stallman |