public inbox for cygwin-apps@cygwin.com
 help / color / mirror / Atom feed
From: Achim Gratz <Stromeko@nexgo.de>
To: cygwin-apps@cygwin.com
Subject: Re: scallywag / cygport not pulling lzip
Date: Fri, 08 Jan 2021 20:11:30 +0100	[thread overview]
Message-ID: <871rev9rbx.fsf@Rainer.invalid> (raw)
In-Reply-To: <d514e8d5-93cc-6c16-523e-00114ce1e9f4@SystematicSw.ab.ca> (Brian Inglis's message of "Fri, 8 Jan 2021 11:09:32 -0700")

Brian Inglis writes:
> Do we know what the frequency weighted difference is on bandwidth of
> packages actually downloaded?

Not that I know of, as everything goes through mirrors.  But I happen to
have a complete Cygwin mirror on disk at the moment plus another one
that only has the packages for my install and that's a fairly large
installation, but without a desktop environment:

30G     /mnt/mirror/cygwin
149G    /mnt/fullmirror/cygwin

So you can probably assume that only about 20% of the files are
frequently accessed (likely significantly less since most folks would
not install the debuginfo or source packages that are included in the
above figure).

> I am more concerned with mirror providers (and also the lack of them)
> especially those with limited resources, and those in marginal
> locations and circumstances, for whom download time and charges may
> override other considerations, and perhaps prevent them (or many) from
> accessing or taking full advantage of available software.

We could save way more space than that by de-duplicating the noarch
parts into their own archives as I have already demonstrated before.
The last time I did that I was cutting out around 30GiB IIRC.

> I doubt the unarchiving time difference is more than a blip in the
> total time required to *download* *AND* install any package, greatly
> outweighed by the download time difference, unless you are on a big
> pipe to a nearby mirror.

It is not, with a typical VDSL connection I'd be able to download faster
than I can install on a more typical machine, I need only about 5MiB/s
to saturate the filesystem for small files and around 20…40MiB/s for
large ones (to an NVMe drive, a spinning disk or some of the slower SSD
can't sustain that).  But that point is somewhat moot since setup will
always mirror to disk first and that's not easy to change since we read
the file twice: once for the SHA512 check (which can use up to around
300MiB/s input bandwidth somewhat higher in peaks and then the actual
installation).

I have a large base of internal installations that I feed from a
(single) local repo and some of those machines are behind rather slow
links (not quite modem speed, but still slow by todays standards) and
using zstd still makes quite the difference there.  The more typical
install time was reduced by a bit under 50% for both slow and fast
connections, so I no longer recommend that folks reserve time
specifically for the Cygwin installation as I had done before.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

  reply	other threads:[~2021-01-08 19:11 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-08  7:38 Marco Atzeri
2021-01-08 13:23 ` ASSI
2021-01-08 13:58   ` Marco Atzeri
2021-01-08 14:21     ` Jon Turney
2021-01-08 16:52       ` Brian Inglis
2021-01-08 17:13         ` Achim Gratz
2021-01-08 18:09           ` Brian Inglis
2021-01-08 19:11             ` Achim Gratz [this message]
2021-01-11 22:05               ` Brian Inglis
2021-01-12 16:28                 ` Brian Inglis
2021-01-12 19:46                   ` ASSI
2021-01-09 19:08           ` Achim Gratz
2022-08-14 19:07 Hannes Mueller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rev9rbx.fsf@Rainer.invalid \
    --to=stromeko@nexgo.de \
    --cc=cygwin-apps@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).