summaryrefslogtreecommitdiffstats
path: root/fs
diff options
context:
space:
mode:
authorUwe Kleine-König <u.kleine-koenig@pengutronix.de>2021-06-11 09:13:51 +0200
committerSascha Hauer <s.hauer@pengutronix.de>2021-06-11 13:13:41 +0200
commit2d339da430d0adcc56eb0173418219bf2ef33139 (patch)
tree6aeb64810a68d1023403e678359e571e7da0b4f1 /fs
parent0ed7bb09f2ef7b40ddcc4a8d269ad42f612c8438 (diff)
downloadbarebox-2d339da430d0adcc56eb0173418219bf2ef33139.tar.gz
barebox-2d339da430d0adcc56eb0173418219bf2ef33139.tar.xz
fs: nfs: Start earlier to resend requests
On a customer site we're experience a bit over 1% UDP packet loss. When wiresharking an NFS transfer of a kernel image (with the goal to boot via NFS) I saw 64 of 2555 RPC calls staying unanswered. With the current timeout setting each of them introduces a delay of 2 seconds and the whole transfer takes 137s. With the timeout reduced to 0.1s the transfer time is not optimal (going down to approx 15 seconds) but at least it becomes bearable. To still cope with a slow network (in contrast to an unreliable as pictured above) increase NFS_MAX_RESEND to keep NFS_TIMEOUT * NFS_MAX_RESEND (which defines the overall timeout before aborting the transfer) constant. Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de> Acked-by: Gavin Schenk <g.schenk@eckelmann.de> Link: https://lore.barebox.org/20210611071351.1445370-1-u.kleine-koenig@pengutronix.de Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Diffstat (limited to 'fs')
-rw-r--r--fs/nfs.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/fs/nfs.c b/fs/nfs.c
index 1130632eb3..057641edc8 100644
--- a/fs/nfs.c
+++ b/fs/nfs.c
@@ -119,8 +119,8 @@ struct rpc_reply {
uint32_t data[0];
};
-#define NFS_TIMEOUT (2 * SECOND)
-#define NFS_MAX_RESEND 5
+#define NFS_TIMEOUT (100 * MSECOND)
+#define NFS_MAX_RESEND 100
struct nfs_fh {
unsigned short size;