Skip to content

Braid 0.1.0-beta.3

Pre-release
Pre-release

Choose a tag to compare

@github-actions github-actions released this 25 Sep 06:50
· 54 commits to main since this release

Downloads are substantially faster in this release, on ordinary links, for an
unglamorous reason: a connection used to ask the origin for one chunk, wait,
and ask for the next. Between every pair of requests was a round trip doing
nothing. Measured against a real CDN that came to more than half the available
bandwidth.

A connection now takes a contiguous stretch of the file and streams the whole
thing in a single request, cutting chunks out of the body as the bytes pass.
Chunks are still exactly what they were to the journal and the per-chunk hash,
which is what keeps corruption local and a crash cheap. They simply no longer
each cost a request.

Twenty-five one-second samples against releases.ubuntu.com:

mean range
beta 2 7.8 MB/s 1 to 24
beta 3 33.1 MB/s 9 to 55

It also reaches full speed in about three seconds rather than crawling for
fifteen.

A slow path no longer decides when a download finishes

Borrowing a phone's mobile data is the point of this project, and until now a
path much slower than the others could cost more than it contributed: whatever
it was carrying when everything else ran out set the finish time.

Three things were wrong. A stretch down to its last chunk could not be handed
over, so a gigabit card waited on a phone. A chunk already in flight could not
be handed over at all. And a chunk only checked whether it had been called off
when bytes arrived, which tied how fast it could stop to how fast it was going,
so the slowest path was the slowest to notice.

A faster lane can now take over a single remaining chunk, or fetch its own copy
of one a slower lane is carrying and keep whichever lands first. Only a lane at
least half again as fast may do that, and only two lanes per chunk, because a
duplicate over mobile data is somebody's money. Measured on a path sixty times
slower than its neighbour: it used to cost 2.43s on a 2.87s download, and now
costs nothing at all.

Each lane works out how many connections it is worth

Opening eight connections to everything is wrong in both directions. One
connection to a distant origin is held back by its own window rather than by
the link; a phone sharing mobile data is often saturated by two, and the other
six spend its battery carrying nothing.

Each lane now starts with one connection and doubles while doubling measurably
helps, then settles on whichever count was fastest. The connections setting is
a ceiling for one lane rather than a total for the transfer.

Phones

  • A phone that stops sharing and starts again is picked up within a few
    seconds. Before this it stayed dead for the rest of the transfer, because the
    path was remembered as familiar rather than checked for whether it was still
    carrying anything.
  • A paired phone is followed when its address changes. Addresses are leases,
    and either end rejoining its Wi-Fi is enough to change one. Matching is on the
    device's identity, never its name: two people on one network calling their
    phone by its model name is not a rare accident.
  • A lane that appears mid-download now joins that download, rather than waiting
    for the next one.
  • dl --relay lets the command line use a phone, which only the desktop app
    could do before.

Reading the numbers

  • Sizes and speeds are in MB and GB throughout, decimal, matching what a
    download page and the Finder quote. The binary spellings are still accepted
    wherever you can type a size.
  • The speed shown is a plain mean over the last second, so it settles instead
    of chasing. It used to be an exponential average, which followed every swing
    of a link that genuinely varies.
  • The sidebar meters use a speed test's scale, compressing as they go right.
    Drawn proportionally, a phone on mobile data beside a fast card is half a
    percent of the bar and indistinguishable from an interface doing nothing,
    which is the one distinction the sidebar exists to make.

Installing

macOS (Intel and Apple silicon) Braid-0.1.0-macos.dmg
Windows x86-64 braid-0.1.0-x86_64.msi
Windows on ARM braid-0.1.0-aarch64.msi
Debian and Ubuntu, x86-64 braid_0.1.0-1_amd64.deb
Debian and Ubuntu, ARM64 braid_0.1.0-1_arm64.deb
Fedora and RHEL, x86-64 braid-0.1.0-1.x86_64.rpm
Fedora and RHEL, ARM64 braid-0.1.0-1.aarch64.rpm

The Android companion is at
InfoDiveLabs/braid-android.

Nothing here is code signed. macOS will refuse the first launch: open it
from the right-click menu, or allow it in Privacy and Security. Windows
SmartScreen will warn.

macOS asks for local network access the first time you look for a phone. It
has to be allowed or the desktop cannot reach one at all, and the failure looks
exactly like the phone not being there. It cost us an afternoon; it is worth
your thirty seconds.

What is not verified

  • The Windows packages have never been installed by anyone. There is no Windows
    hardware here.
  • Windows interface binding is written from Microsoft's documentation and has
    no test job on ARM.
  • The phone path has no throughput measurement on real hardware. The fixes
    in this release have tests, and the companion was confirmed reachable and
    serving, but no end-to-end number was taken through a phone.
  • A phone shared over Wi-Fi sends every byte across the air twice: once from the
    phone to the router, once from the router to you. When Wi-Fi rather than your
    internet connection is the limit, it adds little. A USB tether avoids this
    entirely.
  • Everything measured here was measured on one Mac, on one connection, in India.