EAZIX: NetPerf, NetPipe, and FTP tests
I arrived at the office with the laptop gone, which is no cause for alarm,for anyone could've simply used it. It's with the students from UPM, but
they gave it to me as soon as they'd finished what they were doing.
Starting with netperf, i directed the output (just stdout) to /data/log/
netperf.log. Considering the very little posibility of error, i tested it
just ten times, which was too much, because it was specified to test it
just once. Yet, the (somehow) inconsistent output justified what i've done.
However, the test should be considered "PASSED" for netperf, as it gave out
what was expected.
Since i haven't quite figured out how netpipe worked, i proceeded with the
ftp test while reading the manuals on netpipe. To test ftp transfers, i
used the output from /sbin/ifconfig, and got the output every ten seconds
to a file in /data/log/ftp*/, that way, i can see every erroneous transfer
and every dropped packet with a precision of 10seconds. The ftp "put" tests
were good, considering the time it takes to upload files, but there's a big
problem with the ftp "get" cause it's taking too long to download files.
I'm yet to verify the cause of this, but i have my hypotheses on why it's
so.
Having figured out how netpipe works, i installed it to the laptop and
proceeded with the long test, i did it twice with exactly the same output
using significantly different options. Having a lot of info on the log
files that i stored in /data/log/netpipe/, i decided that the significance
of using netpipe with other options would be very low (or even none at
all), i decided to go back to solving why ftp get takes so long.
The day's over and i still haven't figured out what's wrong, so i went to
overtime for an hour. Trying several tricks such as setting the units up to
recognize a point-to-point connection (a connection between only two
computers) and turning off the firewall all together on both computers
still didn't improve the transfer rate of the ftp-get. My seatmate even
tried to help me out, alas to no use. I finally thought of a conclusive
test that'll guarantee that the fault is not with the driver, but with the
ftp (client or server). It's NFS, which is a way to "trick" a system to
think that a "foreign" directory is in the machine itself. We have failed
to configure it before 6pm, when i needed to go home, so i took down notes
on what to do and left everything for Monday.
<< Home