From a03a114b3fd2b16f80844a5ffa763adaae59b635 Mon Sep 17 00:00:00 2001 From: Canopy bot Date: Tue, 28 Nov 2023 21:26:53 +0000 Subject: [PATCH] updated from main (commit 45441f9924761e681d5d599f0ee0f13adbc84249) --- Posts/TCP-ns | 2 +- atom | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/Posts/TCP-ns b/Posts/TCP-ns index 7728ed5..118f3d3 100644 --- a/Posts/TCP-ns +++ b/Posts/TCP-ns @@ -16,7 +16,7 @@

Now, after switching over to µTCP, graphed below, there's much fewer network utilization and the memory limit is only reached after 36 hours, which is a great result. Though, still it is not very satisfying that the unikernel leaks memory. Both graphs contain on their left side a few hours of mirage-tcpip, and shortly after 20:00 on Nov 23rd µTCP got deployed.

Investigating the involved parts showed that a TCP connection that was never established has been registered at the MirageOS layer, but the pure core does not expose an event from the received RST that the connection has been cancelled. This means the MirageOS layer piles up all the connection attempts, and doesn't inform the application that the connection couldn't be established. Once this was well understood, developing the required code changes was straightforward. The graph shows that the fix was deployed at 15:25. The memory usage is constant afterwards, but the network utilization increased enormously.

-

+

Now, the network utilization is unwanted. This was hidden by the application waiting forever that the TCP connection getting established. Our bugfix uncovered another issue, a tight loop: