| Version 7 (modified by , 12 years ago) (diff) |
|---|
Here are the details of Baseline 4, divided by slice.
We changed how we were capturing logs for this baseline, using screen's 'hardcopy' function rather than its 'screenlog' function. This created more readable logs, but caused each screen process to consume unacceptably large amounts of memory in order to maintain large scrollback buffers, and even those large buffers weren't sufficient for some experiments. The raw logs are at http://www.gpolab.bbn.com/plastic-slices/baseline-logs/baseline-4/.
plastic-101
SteadyPing, using interval=.05, and this table of client/server pairs:
| client | server | server address |
| ganel.gpolab.bbn.com | planetlab5.clemson.edu | server=10.42.101.105 |
| planetlab4.clemson.edu | plnode2.cip.gatech.edu | server=10.42.101.101 |
| plnode1.cip.gatech.edu | pl5.myplc.grnoc.iu.edu | server=10.42.101.73 |
| pl4.myplc.grnoc.iu.edu | orbitplc2.orbit-lab.org | server=10.42.101.112 |
| orbitplc1.orbit-lab.org | pl02.cs.washington.edu | server=10.42.101.81 |
| pl01.cs.washington.edu | wings-openflow-3.wail.wisc.edu | server=10.42.101.96 |
| wings-openflow-2.wail.wisc.edu | gardil.gpolab.bbn.com | server=10.42.101.52 |
Commands run on each client
server=<ipaddr> sudo ping -i .05 -s $((1500-8-20)) $server
Results
ganel.gpolab.bbn.com:
--- 10.42.101.105 ping statistics --- 1396393 packets transmitted, 1391125 received, 0% packet loss, time 76099874ms rtt min/avg/max/mdev = 59.346/62.437/84965.189/323.617 ms, pipe 1606
planetlab4.clemson.edu:
--- 10.42.101.101 ping statistics --- 1484173 packets transmitted, 1479406 received, 0% packet loss, time 76099411ms
plnode1.cip.gatech.edu:
--- 10.42.101.73 ping statistics --- 1496035 packets transmitted, 1474929 received, 1% packet loss, time 76099327ms rtt min/avg/max/mdev = 2.831/42.116/86679.762/353.206 ms, pipe 1472
pl4.myplc.grnoc.iu.edu:
--- 10.42.101.112 ping statistics --- 1479691 packets transmitted, 1459209 received, 1% packet loss, time 76099210ms rtt min/avg/max/mdev = 54.922/64.298/58815.628/544.703 ms, pipe 1155
orbitplc1.orbit-lab.org:
--- 10.42.101.81 ping statistics --- 1483844 packets transmitted, 1472706 received, 0% packet loss, time 76098550ms rtt min/avg/max/mdev = 104.721/119.090/70485.232/762.029 ms, pipe 1380
pl01.cs.washington.edu:
--- 10.42.101.96 ping statistics --- 1478306 packets transmitted, 1469663 received, 0% packet loss, time 76097994ms rtt min/avg/max/mdev = 59.682/71.623/71005.795/627.850 ms, pipe 1343
wings-openflow-2.wail.wisc.edu:
--- 10.42.101.52 ping statistics --- 1492205 packets transmitted, 1491671 received, 0% packet loss, time 76098509ms rtt min/avg/max/mdev = 29.544/33.358/69496.963/381.975 ms, pipe 1345
Analysis
All results seem consistent with what we'd expect.
plastic-102
SteadyPing, using interval=.05, and this table of client/server pairs:
| client | server | server address |
| sardis.gpolab.bbn.com | planetlab4.clemson.edu | server=10.42.102.104 |
| planetlab5.clemson.edu | plnode1.cip.gatech.edu | server=10.42.102.100 |
| plnode2.cip.gatech.edu | pl4.myplc.grnoc.iu.edu | server=10.42.102.72 |
| pl5.myplc.grnoc.iu.edu | orbitplc1.orbit-lab.org | server=10.42.102.111 |
| orbitplc2.orbit-lab.org | pl01.cs.washington.edu | server=10.42.102.80 |
| pl02.cs.washington.edu | wings-openflow-2.wail.wisc.edu | server=10.42.102.95 |
| wings-openflow-3.wail.wisc.edu | bain.gpolab.bbn.com | server=10.42.102.54 |
Commands run on each client
server=<ipaddr> sudo ping -i .05 -s $((1500-8-20)) $server
Results
sardis.gpolab.bbn.com:
--- 10.42.102.104 ping statistics --- 1438429 packets transmitted, 1434276 received, 0% packet loss, time 76268255ms rtt min/avg/max/mdev = 164.718/167.028/46964.880/200.998 ms, pipe 888
planetlab5.clemson.edu:
--- 10.42.102.100 ping statistics --- 1488355 packets transmitted, 1484309 received, 0% packet loss, time 76270465ms rtt min/avg/max/mdev = 3.625/4.952/47676.102/105.155 ms, pipe 878
plnode2.cip.gatech.edu:
--- 10.42.102.72 ping statistics --- 1423107 packets transmitted, 1408264 received, 1% packet loss, time 76271364ms rtt min/avg/max/mdev = 106.831/149.508/31011.660/288.808 ms, pipe 528
pl5.myplc.grnoc.iu.edu:
--- 10.42.102.111 ping statistics --- 1484515 packets transmitted, 1467344 received, 1% packet loss, time 76273971ms rtt min/avg/max/mdev = 160.276/165.904/24082.382/248.900 ms, pipe 474
orbitplc2.orbit-lab.org:
--- 10.42.102.80 ping statistics --- 1487140 packets transmitted, 1480729 received, 0% packet loss, time 76276195ms rtt min/avg/max/mdev = 102.669/105.717/37152.971/168.222 ms, pipe 729
pl02.cs.washington.edu:
--- 10.42.102.95 ping statistics --- 1481034 packets transmitted, 1474795 received, 0% packet loss, time 76280530ms rtt min/avg/max/mdev = 59.673/60.756/24094.513/54.720 ms, pipe 447
wings-openflow-3.wail.wisc.edu:
--- 10.42.102.54 ping statistics --- 1488732 packets transmitted, 1482181 received, 0% packet loss, time 76282441ms rtt min/avg/max/mdev = 29.543/34.070/43232.772/350.041 ms, pipe 847
Analysis
All results seem consistent with what we'd expect.
plastic-103
SteadyPerf TCP, using port=5103, time=86400, and this table of client/server pairs:
| client | server | server address |
| pl02.cs.washington.edu | navis.gpolab.bbn.com | server=10.42.103.55 |
| ganel.gpolab.bbn.com | orbitplc1.orbit-lab.org | server=10.42.103.111 |
| orbitplc2.orbit-lab.org | pl01.cs.washington.edu | server=10.42.103.80 |
One-time prep commands run on each client and server
sudo yum -y install iperf
Commands run on each server
server=<ipaddr> nice -n 19 iperf -B $server -p 5103 -s -i 1
Commands run on each client
server=<ipaddr> nice -n 19 iperf -c $server -p 5103 -t 86400
Results
Note that I lost my SSH connection to some of the clients, but the iperf process kept running in the background. These excerpts are a combination of the initial connection message from the clients, and the final results lines from the servers.
pl02.cs.washington.edu:
------------------------------------------------------------ Client connecting to 10.42.103.55, TCP port 5103 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.103.81 port 36185 connected with 10.42.103.55 port 5103 [ ID] Interval Transfer Bandwidth [ 3] 0.0-76393.9 sec 39.2 GBytes 4.41 Mbits/sec
ganel.gpolab.bbn.com:
------------------------------------------------------------ Client connecting to 10.42.103.111, TCP port 5103 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.103.51 port 56294 connected with 10.42.103.111 port 5103 [ 3] 0.0-76399.7 sec 21.7 GBytes 2.44 Mbits/sec
orbitplc2.orbit-lab.org:
------------------------------------------------------------ Client connecting to 10.42.103.80, TCP port 5103 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.103.112 port 41987 connected with 10.42.103.80 port 5103 [ 3] 0.0-76399.2 sec 15.7 GBytes 1.76 Mbits/sec
Analysis
All results seem consistent with what we'd expect.
plastic-104
SteadyPerf UDP, using port=5104, time=86400, rate=.5, and this table of client/server pairs:
| client | server | server address |
| planetlab4.clemson.edu | gardil.gpolab.bbn.com | server=10.42.104.52 |
| planetlab5.clemson.edu | orbitplc2.orbit-lab.org | server=10.42.104.112 |
One-time prep commands run on each client and server
sudo yum -y install iperf
Commands run on each server
server=<ipaddr> nice -n 19 iperf -u -B $server -p 5104 -s -i 1
Commands run on each client
server=<ipaddr> nice -n 19 iperf -u -c $server -p 5104 -t 86400 -b 512K
Results
Note that I lost my SSH connection to the clients, but the iperf process kept running in the background. These excerpts are a combination of the initial connection message from the clients, and the final results lines from the servers.
planetlab4.clemson.edu:
------------------------------------------------------------ Client connecting to 10.42.104.52, UDP port 5104 Sending 1470 byte datagrams UDP buffer size: 109 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.104.104 port 39909 connected with 10.42.104.52 port 5104 [ ID] Interval Transfer Bandwidth [ 3] 0.0-76605.7 sec 4.54 GBytes 509 Kbits/sec 0.019 ms 21042/3335348 (0.63%) [ 3] 0.0-76605.7 sec 855 datagrams received out-of-order
planetlab5.clemson.edu:
------------------------------------------------------------ Client connecting to 10.42.104.112, UDP port 5104 Sending 1470 byte datagrams UDP buffer size: 109 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.104.105 port 33609 connected with 10.42.104.112 port 5104 [ ID] Interval Transfer Bandwidth [ 3] 0.0-76626.1 sec 4.55 GBytes 510 Kbits/sec 0.017 ms 16355/3336225 (0.49%) [ 3] 0.0-76626.1 sec 1183 datagrams received out-of-order
Analysis
All results seem consistent with what we'd expect.
plastic-105
SteadyPerf TCP, using port=5105, time=84600, and this table of client/server pairs:
| client | server | server address |
| wings-openflow-2.wail.wisc.edu | planetlab5.clemson.edu | server=10.42.105.105 |
| planetlab4.clemson.edu | sardis.gpolab.bbn.com | server=10.42.105.53 |
| bain.gpolab.bbn.com | plnode2.cip.gatech.edu | server=10.42.105.101 |
| plnode1.cip.gatech.edu | wings-openflow-3.wail.wisc.edu | server=10.42.105.96 |
One-time prep commands run on each client and server
sudo yum -y install iperf
Commands run on each server
server=<ipaddr> nice -n 19 iperf -B $server -p 5105 -s -i 1
Commands run on each client
server=<ipaddr> nice -n 19 iperf -c $server -p 5105 -t 86400
Results
Note that I lost my SSH connection to some of the clients, but the iperf process kept running in the background. These excerpts are a combination of the initial connection message from the clients, and the final results lines from the servers.
wings-openflow-2.wail.wisc.edu:
------------------------------------------------------------ Client connecting to 10.42.105.105, TCP port 5105 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.105.95 port 52533 connected with 10.42.105.105 port 5105 [ ID] Interval Transfer Bandwidth [ 3] 0.0-76726.1 sec 57.5 GBytes 6.44 Mbits/sec
planetlab4.clemson.edu:
------------------------------------------------------------ Client connecting to 10.42.105.53, TCP port 5105 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.105.104 port 57701 connected with 10.42.105.53 port 5105 [ ID] Interval Transfer Bandwidth [ 4] 0.0-76787.2 sec 71.6 GBytes 8.01 Mbits/sec
bain.gpolab.bbn.com:
------------------------------------------------------------ Client connecting to 10.42.105.101, TCP port 5105 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.105.54 port 52677 connected with 10.42.105.101 port 5105 [ 3] 0.0-76792.4 sec 27.8 GBytes 3.11 Mbits/sec
plnode1.cip.gatech.edu:
------------------------------------------------------------ Client connecting to 10.42.105.96, TCP port 5105 TCP window size: 16.0 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.105.100 port 44744 connected with 10.42.105.96 port 5105 [ 4] 0.0-7199.0 sec 10.4 GBytes 12.5 Mbits/sec
Analysis
All results seem consistent with what we'd expect.
plastic-106
SteadyPerf UDP, using port=5106, time=86400, rate=.5, and this table of client/server pairs:
| client | server | server address |
| planetlab5.clemson.edu | wings-openflow-2.wail.wisc.edu | server=10.42.106.95 |
| wings-openflow-3.wail.wisc.edu | plnode1.cip.gatech.edu | server=10.42.106.100 |
One-time prep commands run on each client and server
sudo yum -y install iperf
Commands run on each server
server=<ipaddr> nice -n 19 iperf -u -B $server -p 5106 -s -i 1
Commands run on each client
server=<ipaddr> nice -n 19 iperf -u -c $server -p 5106 -t 86400 -b 512K
Results
planetlab5.clemson.edu:
------------------------------------------------------------ Client connecting to 10.42.106.95, UDP port 5106 Sending 1470 byte datagrams UDP buffer size: 109 KByte (default) ------------------------------------------------------------ [ 3] 0.0-76937.1 sec 4.55 GBytes 508 Kbits/sec 0.018 ms 28786/3349780 (0.86%) [ 3] 0.0-76937.1 sec 320 datagrams received out-of-order
wings-openflow-3.wail.wisc.edu:
------------------------------------------------------------ Client connecting to 10.42.106.100, UDP port 5106 Sending 1470 byte datagrams UDP buffer size: 109 KByte (default) ------------------------------------------------------------ [ 3] local 10.42.106.96 port 59190 connected with 10.42.106.100 port 5106 [ ID] Interval Transfer Bandwidth [ 3] 0.0-76948.3 sec 4.59 GBytes 512 Kbits/sec [ 3] Sent 3350239 datagrams [ 3] Server Report: [ 3] 0.0-76947.6 sec 4.55 GBytes 508 Kbits/sec 0.127 ms 26446/3350239 (0.79%) [ 3] 0.0-76947.6 sec 652 datagrams received out-of-order
Analysis
All results seem consistent with what we'd expect.
plastic-107
SteadyWeb, using port=4107, file=substrate.doc, md5sum=d4fcf71833327fbfef98be09deef8bfb, and this table of client/server pairs:
| client | server | server address |
| planetlab5.clemson.edu | pl4.myplc.grnoc.iu.edu | server=10.42.107.72 |
| pl5.myplc.grnoc.iu.edu | plnode2.cip.gatech.edu | server=10.42.107.101 |
| plnode1.cip.gatech.edu | pl02.cs.washington.edu | server=10.42.107.81 |
| pl01.cs.washington.edu | planetlab4.clemson.edu | server=10.42.107.104 |
One-time prep commands run on each server
sudo yum -y install pyOpenSSL patch cd rm -rf ~/gigaweb mkdir -p ~/gigaweb/docroot cd ~/gigaweb wget http://code.activestate.com/recipes/442473-simple-http-server-supporting-ssl-secure-communica/download/1/ -O httpsd.py wget http://groups.geni.net/geni/attachment/wiki/PlasticSlices/Experiments/httpsd.py.patch?format=raw -O httpsd.py.patch patch httpsd.py httpsd.py.patch rm httpsd.py.patch cd ~/gigaweb/docroot wget http://groups.geni.net/geni/attachment/wiki/DeliverablePage/Spiral1%20substrate%20catalog.doc?format=raw -O substrate.doc cd ~/gigaweb openssl genrsa -passout pass:localhost -des3 -rand /dev/urandom -out localhost.localdomain.key 1024 openssl req -subj /CN=localhost.localdomain -passin pass:localhost -new -key localhost.localdomain.key -out localhost.localdomain.csr openssl x509 -passin pass:localhost -req -days 3650 -in localhost.localdomain.csr -signkey localhost.localdomain.key -out localhost.localdomain.crt openssl rsa -passin pass:localhost -in localhost.localdomain.key -out decrypted.localhost.localdomain.key mv -f decrypted.localhost.localdomain.key localhost.localdomain.key cat localhost.localdomain.key localhost.localdomain.crt > localhost.localdomain.pem rm localhost.localdomain.key localhost.localdomain.crt localhost.localdomain.csr
Commands run on each server
server=<ipaddr> cd ~/gigaweb/docroot python ../httpsd.py $server 4107
Commands run on each client
server=<ipaddr> cd rm -rf ~/gigaweb mkdir ~/gigaweb cd ~/gigaweb while true ; do wget --no-check-certificate https://$server:4107/substrate.doc -O substrate.doc ; echo -n "md5sum: " ; md5sum substrate.doc ; rm substrate.doc ; done
Results
Since we transfered the file to each client hundreds (if not thousands) of times, we didn't save all the copies, but we did generate an MD5 checksum after each download, and log that, so we ran some grep commands on the logs to count the number of total checksums printed in each log, and the number where the checksum had the expected value.
planetlab5.clemson.edu:
+$ grep "md5sum:" plastic-107-hardcopy-0.log | wc -l 1986 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-107-hardcopy-0.log | wc -l 1985
pl5.myplc.grnoc.iu.edu:
+$ grep "md5sum:" plastic-107-hardcopy-2.log | wc -l 6944 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-107-hardcopy-2.log | wc -l 6944
plnode1.cip.gatech.edu:
+$ grep "md5sum:" plastic-107-hardcopy-4.log | wc -l 3700 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-107-hardcopy-4.log | wc -l 3699
pl01.cs.washington.edu:
+$ grep "md5sum:" plastic-107-hardcopy-6.log | wc -l 4756 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-107-hardcopy-6.log | wc -l 4755
Analysis
All results seem consistent with what we'd expect.
plastic-108
SteadyWeb, using port=4108, file=substrate.doc, md5sum=d4fcf71833327fbfef98be09deef8bfb, and this table of client/server pairs:
| client | server | server address |
| wings-openflow-3.wail.wisc.edu | orbitplc1.orbit-lab.org | server=10.42.108.111 |
| orbitplc2.orbit-lab.org | pl5.myplc.grnoc.iu.edu | server=10.42.108.73 |
| pl4.myplc.grnoc.iu.edu | wings-openflow-2.wail.wisc.edu | server=10.42.108.95 |
One-time prep commands run on each server
sudo yum -y install pyOpenSSL patch cd rm -rf ~/gigaweb mkdir -p ~/gigaweb/docroot cd ~/gigaweb wget http://code.activestate.com/recipes/442473-simple-http-server-supporting-ssl-secure-communica/download/1/ -O httpsd.py wget http://groups.geni.net/geni/attachment/wiki/PlasticSlices/Experiments/httpsd.py.patch?format=raw -O httpsd.py.patch patch httpsd.py httpsd.py.patch rm httpsd.py.patch cd ~/gigaweb/docroot wget http://groups.geni.net/geni/attachment/wiki/DeliverablePage/Spiral1%20substrate%20catalog.doc?format=raw -O substrate.doc cd ~/gigaweb openssl genrsa -passout pass:localhost -des3 -rand /dev/urandom -out localhost.localdomain.key 1024 openssl req -subj /CN=localhost.localdomain -passin pass:localhost -new -key localhost.localdomain.key -out localhost.localdomain.csr openssl x509 -passin pass:localhost -req -days 3650 -in localhost.localdomain.csr -signkey localhost.localdomain.key -out localhost.localdomain.crt openssl rsa -passin pass:localhost -in localhost.localdomain.key -out decrypted.localhost.localdomain.key mv -f decrypted.localhost.localdomain.key localhost.localdomain.key cat localhost.localdomain.key localhost.localdomain.crt > localhost.localdomain.pem rm localhost.localdomain.key localhost.localdomain.crt localhost.localdomain.csr
Commands run on each server
server=<ipaddr> cd ~/gigaweb/docroot python ../httpsd.py $server 4108
Commands run on each client
server=<ipaddr> cd rm -rf ~/gigaweb mkdir ~/gigaweb cd ~/gigaweb while true ; do wget --no-check-certificate https://$server:4108/substrate.doc -O substrate.doc ; echo -n "md5sum: " ; md5sum substrate.doc ; rm substrate.doc ; done
Results
Since we transfered the file to each client hundreds (if not thousands) of times, we didn't save all the copies, but we did generate an MD5 checksum after each download, and log that, so we ran some grep commands on the logs to count the number of total checksums printed in each log, and the number where the checksum had the expected value.
wings-openflow-3.wail.wisc.edu:
+$ grep "md5sum:" plastic-108-hardcopy-0.log | wc -l 1254 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-108-hardcopy-0.log | wc -l 1253
orbitplc2.orbit-lab.org:
+$ grep "md5sum:" plastic-108-hardcopy-2.log | wc -l 696 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-108-hardcopy-2.log | wc -l 695
pl4.myplc.grnoc.iu.edu:
+$ grep "md5sum:" plastic-108-hardcopy-4.log | wc -l 20271 +$ grep "md5sum: d4fcf71833327fbfef98be09deef8bfb" plastic-108-hardcopy-4.log | wc -l 20270
Analysis
All results seem consistent with what we'd expect.
plastic-109
SteadyNetcat, using port=6109, file=substrate.doc, md5sum=d4fcf71833327fbfef98be09deef8bfb, and this table of client/server pairs:
| client | server | server address |
| navis.gpolab.bbn.com | pl5.myplc.grnoc.iu.edu | server=10.42.109.73 |
| pl4.myplc.grnoc.iu.edu | pl02.cs.washington.edu | server=10.42.109.81 |
| pl01.cs.washington.edu | planetlab5.clemson.edu | server=10.42.109.105 |
| planetlab4.clemson.edu | wings-openflow-3.wail.wisc.edu | server=10.42.109.96 |
| wings-openflow-2.wail.wisc.edu | ganel.gpolab.bbn.com | server=10.42.109.51 |
One-time prep commands run on each server
sudo yum -y install nc mkdir -p ~/giganetcat cd ~/giganetcat wget http://groups.geni.net/geni/attachment/wiki/DeliverablePage/Spiral1%20substrate%20catalog.doc?format=raw -O substrate.doc
One-time prep commands run on each client
sudo yum -y install nc
Commands run on each server
server=<ipaddr> cd ~/giganetcat while true ; do nc -l $server 6109 < substrate.doc ; done
Commands run on each client
server=<ipaddr> cd rm -rf ~/giganetcat mkdir ~/giganetcat cd ~/giganetcat while true ; do nc $server 6109 > substrate.doc ; echo -n "$(date "+%F %T") " ; md5sum substrate.doc ; rm substrate.doc ; done
Results
Since we transfered the file to each client hundreds (if not thousands) of times, we didn't save all the copies, but we did generate an MD5 checksum after each download, and log that, so we ran some grep commands on the logs to count the number of total checksums printed in each log, and the number where the checksum had the expected value.
navis.gpolab.bbn.com:
+$ grep "substrate.doc" plastic-109-hardcopy-0.log | wc -l 2138 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-109-hardcopy-0.log | wc -l 2135
pl4.myplc.grnoc.iu.edu:
+$ grep "substrate.doc" plastic-109-hardcopy-2.log | wc -l 753 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-109-hardcopy-2.log | wc -l 746
pl01.cs.washington.edu:
+$ grep "substrate.doc" plastic-109-hardcopy-4.log | wc -l 4072 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-109-hardcopy-4.log | wc -l 4070
planetlab4.clemson.edu:
+$ grep "substrate.doc" plastic-109-hardcopy-6.log | wc -l 1986 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-109-hardcopy-6.log | wc -l 1985
wings-openflow-2.wail.wisc.edu:
+$ grep "substrate.doc" plastic-109-hardcopy-8.log | wc -l 5651 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-109-hardcopy-8.log | wc -l 5649
Analysis
All results seem consistent with what we'd expect.
plastic-110
SteadyNetcat, using port=6110, file=substrate.doc, md5sum=d4fcf71833327fbfef98be09deef8bfb, and this table of client/server pairs:
| client | server | server address |
| gardil.gpolab.bbn.com | pl01.cs.washington.edu | server=10.42.110.80 |
| pl02.cs.washington.edu | orbitplc2.orbit-lab.org | server=10.42.110.112 |
| orbitplc1.orbit-lab.org | pl4.myplc.grnoc.iu.edu | server=10.42.110.72 |
| pl5.myplc.grnoc.iu.edu | plnode1.cip.gatech.edu | server=10.42.110.100 |
| plnode2.cip.gatech.edu | sardis.gpolab.bbn.com | server=10.42.110.53 |
One-time prep commands run on each server
sudo yum -y install nc mkdir -p ~/giganetcat cd ~/giganetcat wget http://groups.geni.net/geni/attachment/wiki/DeliverablePage/Spiral1%20substrate%20catalog.doc?format=raw -O substrate.doc
One-time prep commands run on each client
sudo yum -y install nc
Commands run on each server
server=<ipaddr> cd ~/giganetcat while true ; do nc -l $server 6110 < substrate.doc ; done
Commands run on each client
server=<ipaddr> cd rm -rf ~/giganetcat mkdir ~/giganetcat cd ~/giganetcat while true ; do nc $server 6110 > substrate.doc ; echo -n "$(date "+%F %T") " ; md5sum substrate.doc ; rm substrate.doc ; done
Results
Since we transfered the file to each client hundreds (if not thousands) of times, we didn't save all the copies, but we did generate an MD5 checksum after each download, and log that, so we ran some grep commands on the logs to count the number of total checksums printed in each log, and the number where the checksum had the expected value.
gardil.gpolab.bbn.com:
+$ grep "substrate.doc" plastic-110-hardcopy-0.log | wc -l 2295 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-110-hardcopy-0.log | wc -l 2273
pl02.cs.washington.edu:
+$ grep "substrate.doc" plastic-110-hardcopy-2.log | wc -l 1636 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-110-hardcopy-2.log | wc -l 1633
orbitplc1.orbit-lab.org:
+$ grep "substrate.doc" plastic-110-hardcopy-4.log | wc -l 723 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-110-hardcopy-4.log | wc -l 720
pl5.myplc.grnoc.iu.edu:
+$ grep "substrate.doc" plastic-110-hardcopy-6.log | wc -l 41896 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-110-hardcopy-6.log | wc -l 276
plnode2.cip.gatech.edu:
+$ grep "substrate.doc" plastic-110-hardcopy-8.log | wc -l 1456 +$ grep "d4fcf71833327fbfef98be09deef8bfb substrate.doc" plastic-110-hardcopy-8.log | wc -l 1453
Analysis
pl5.myplc.grnoc.iu.edu ended up with many thousands of zero-length files; it looks like the netcat process on the server died, possibly when the SSH connection to the plnode was lost. All other results seem consistent with what we'd expect.
