Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

autoupdater: extremely slow image download on HiveAP #273

Open
kpanic23 opened this issue Feb 6, 2024 · 3 comments · May be fixed by #274
Open

autoupdater: extremely slow image download on HiveAP #273

kpanic23 opened this issue Feb 6, 2024 · 3 comments · May be fixed by #274

Comments

@kpanic23
Copy link

kpanic23 commented Feb 6, 2024

I'm currently using autoupdater to update the firmware on an Aerohive HiveAP 330. Which takes ages.
So I've used that time to find out about what's holding it up.
The HiveAP 330 uses a 9600bps console output, so any output takes a long time.

The while loop in recv_image_cb outputs the progress in every iteration:

/** Receives data from uclient and writes it to file */
static void recv_image_cb(struct uclient *cl) {
struct recv_image_ctx *ctx = uclient_get_custom(cl);
char buf[1024];
int len;
while (true) {
len = uclient_read_account(cl, buf, sizeof(buf));
if (len <= 0)
return;
printf(
"\rDownloading image: % 5zi / %zi KiB",
uclient_data(cl)->downloaded / 1024,
uclient_data(cl)->length / 1024
);
fflush(stdout);
if (write(ctx->fd, buf, len) < len) {
fputs("autoupdater: error: downloading firmware image failed: ", stderr);
perror(NULL);
return;
}
ecdsa_sha256_update(&ctx->hash_ctx, buf, len);
}
}

Maybe it would be beneficial if the downloading progress would only get shown, like, every 128th iteration or so?

On a sidenote, it also looks to me like the SHA256 checksum is calculated for every iteration as well? Is this necessary? Wouldn't it be sufficient to calculate it once the download is completed?

ecdsa_sha256_update(&ctx->hash_ctx, buf, len);

Okay, it finally finished downloading, took about 20 minutes for the 44MB image...

EDIT:
using # autoupdater >/dev/null it took merely a couple seconds to download the image. So it definitely is related to terminal output.

@neocturne
Copy link
Member

The SHA256 checksum is calculated continuously while the image is downloaded, updating the hash state with every block of new data - there is no duplicate work happening.

Limiting the progress output sounds like a good idea.

neocturne added a commit to neocturne/gluon-packages that referenced this issue Mar 8, 2024
Updating the "XXXXX / XXXXX KiB" display for every run of
recv_image_cb() is a significant bottleneck on slow consoles. This was
reported for a device using a 9600 Baud serial console, but the slowdown
is noticeable even on a 115200 Baud console, especially when the network
is fast.

Replace the output with a "XX.X / XX.X MiB" display and only update it
every 0.1 MiB to fix the issue.

Closes freifunk-gluon#273
@neocturne
Copy link
Member

@kpanic23 I have implemented your suggestion in #274.

@rotanid
Copy link
Member

rotanid commented May 21, 2024

@kpanic23 can you test the implementation over at #274 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants