- Zero out the vm and exit
sudo apt-get clean
sudo dd if=/dev/zero of=/EMPTY bs=1M
sudo rm -f /EMPTY
cat /dev/null > ~/.bash_history && history -c && exit
/* -*- Mode: C++; c-file-style: "gnu"; indent-tabs-mode:nil; -*- */ | |
/* | |
* Copyright (c) 2009 The Boeing Company | |
* | |
* This program is free software; you can redistribute it and/or modify | |
* it under the terms of the GNU General Public License version 2 as | |
* published by the Free Software Foundation; | |
* | |
* This program is distributed in the hope that it will be useful, | |
* but WITHOUT ANY WARRANTY; without even the implied warranty of |
I am trying to understand the effects of manually setting the TCP Socket's Tx/Rx buffer size on the CWND over time.
// ns3 Tx/Rx buffer default initial = 131072 bytes or roughly 88 packets
Config::SetDefault ("ns3::TcpSocket::SndBufSize", UintegerValue (tcpQ*1500)); // 1500 MSS
Config::SetDefault ("ns3::TcpSocket::RcvBufSize", UintegerValue (tcpQ*1500));
I tested with a simple linear topology, here, 1* means one or more intermediate routers/nodes. By default, each link is 5Mbps, 1ms delay. However, I can also enable at most one bottleneck link of 1Mbps, 10ms delay.
This python (2.7) script reads credentials and input from input.txt
file for telnet test and generates the telnet output to output.txt
make sure to modify the input.txt
file accordingly for proper _ip-address_
, _user_
and _password_
.
Original post: | |
https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c |
Waf: Entering directory `/home/ubuntu/NFD/build' | |
[ 18/154] Compiling daemon/face/udp-channel.cpp | |
[ 19/154] Compiling daemon/face/ethernet-factory.cpp | |
[ 21/154] Compiling daemon/face/ethernet-channel.cpp | |
[ 45/154] Compiling daemon/face/websocket-channel.cpp | |
[136/154] Compiling daemon/face/tcp-channel.cpp | |
[139/154] Compiling daemon/face/unix-stream-channel.cpp | |
[140/154] Compiling daemon/face/null-face.cpp | |
[141/154] Compiling daemon/face/lp-reliability.cpp | |
[142/154] Compiling daemon/mgmt/face-manager.cpp |
. | |
. | |
. | |
uint32_t MacTxDropCount, PhyTxDropCount, PhyRxDropCount; | |
void | |
MacTxDrop(Ptr<const Packet> p) | |
{ | |
NS_LOG_INFO("Packet Drop"); |
Started by upstream project "NFD" build number 6788 | |
originally caused by: | |
Retriggered by user [email protected] for Gerrit: https://gerrit.named-data.net/c/NFD/+/4993 | |
Building remotely on OSX-10.14-ua-monaco-21803 (OSX OSX-10.14) in workspace /Users/jenkins/workspace/NFD/OS/OSX-10.14 | |
> git rev-parse --is-inside-work-tree # timeout=10 | |
Fetching changes from the remote Git repository | |
> git config remote.origin.url https://gerrit.named-data.net/NFD # timeout=10 | |
Pruning obsolete local branches | |
Fetching upstream changes from https://gerrit.named-data.net/NFD | |
> git --version # timeout=10 |
The NFD and it's related tools and software packages can be installed on platforms mentioned in the official NFD documentation. However, a successful installation on constrained hardware like the Raspberry Pi with the official Raspbian OS is tricky and sometimes suggested to perform a cross-compilation and install the generated binaries. Although it's possible to install Ubuntu MATE and install the relevant pre-compiled binaries directly, one might need to go through the painstaking process of the MATE environment setup, and not be able to modify code to test/experiment self-written features.
In this documentation, I will talk about how to perform a step-by-step (as noob as possible) installation of NFD and related software from source on the Raspberry Pi running official Raspbian OS. The trick is two-folds-