Hamid,
thanks for letting me know dkftpbench helped!
- Dan

Hamid Reza Shahriari wrote:
> The problem was solved. There was a bug in our ftp proxy of firewall.
> It was stalled in some steps of protocol. The dkftpbench helped us to
> find this bug.
> I hope that the dkftpbecnch will be the standard benchmarker for ftp like
> specweb for http.
>
> Very thanks to your notice,
> --Hamid
>
> On Tue, 8 May 2001, Dan Kegel wrote:
>
> > Hamid Reza Shahriari wrote:
> > > > I think this is saying that dkftpbench connected but got no response
> > > > to the GET command in five seconds.
> > > >
> > > > A few questions:
> > > > 1. how fast is the link between the client and the server?
> > > 100 MB/S
> > >
> > > > 2. Which FTP server software are you benchmarking? What OS?
> > > I use a firewall in transparent mode on special OS between dkftpbench and
> > > wu-ftp.
> >
> > OK, the firewall is running a special OS.
> > What OS is the server running? What OS is the client running?
> >
> > > > 3. Is the server publically accessible?
> > > Unfortunatelly firewall is not free and it is in development.
> > >
> > > > 4. Can you send me the complete log for a failed 1-client run, perhaps
also with
> > > > the output of "tcpdump -n -x proto tcp"?
> > > I attached the output.
> > > I run this command:
> > > ----------------------------------------------
> > > ./dkftpbench -hrostam -n1 -t180 -fx10k.dat -v
> >
> > Still looks like ftpbench is timing out on a connection.
> > You can verify this with a packet log generated by tcpdump;
> > it should show ftpbench trying to make a connection but getting
> > no response in five seconds. (Send the log to me and I'll check it.)
> >
> > You can adjust the timeout by changing the line in ftp_client_pipe.cc from
> > /* Abort if no response in five seconds */
> > m_sked->addClient(this, m_wakeup + (5 * eclock_hertz()));
> >
> > You might also try benchmarking with larger files, so it doesn't
> > try to open so many connections.
> >
> > (It is possible to run out of free TCP ports. The limit on ports
> > for a particular client/server combination is dictated by
> > the local port range and the TCP specification, i.e.
> > ports per second = # of available ports / 2 MSL
> > MSL is normally 60 seconds, and on Linux # of available ports is
> > given by /proc/sys/net/ipv4/ip_local_port_range; on my system,
> > that defaults to "1024 4999", so there are about 4000 ports by default.
> > 4000 / 120 = about 300.
> > Doesn't look like you're likely to run into this limit.)