wiki:PlasticSlices/BaselineEvaluation/Baseline4Details

Version 5 (modified by Josh Smift, 9 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

GigaPing, using count=100000, 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.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

GigaPing, using count=100000, 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

GigaPerf TCP, using port=5103, size=350, 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

GigaPerf UDP, using port=5104, size=500, rate=100, 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

GigaPerf TCP, using port=5105, size=250, 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

GigaPerf UDP, using port=5106, size=500, rate=100, 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

GigaWeb, using count=30, 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

GigaWeb, using count=40, 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

GigaNetcat, using count=25, port=6109, file=substrate.doc, 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

GigaNetcat, using count=25, port=6110, file=substrate.doc, 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.