Loading ...
Sorry, an error occurred while loading the content.
 

Re: [ftpbench] timeout error

Expand Messages
  • Hamid Reza Shahriari
    ... 100 MB/S ... I use a firewall in transparent mode on special OS between dkftpbench and wu-ftp. ... Unfortunatelly firewall is not free and it is in
    Message 1 of 6 , May 8, 2001
      On Sun, 29 Apr 2001, Dan Kegel wrote:

      > Hamid Reza Shahriari wrote:
      > > I'm a new member of this list. I've faced an error with dkftpbench
      > > for benching our server:
      > >
      > > $ ./dkftpbench -hrostam -n300 -t600 -fx10k.dat -v
      > > ...
      > > robouser13::unwatchfd 29: stopping
      > > 1 users alive, 15 users dead; at least 600 seconds to end of test
      > > User15: fetching 10240 bytes took 1.133100 seconds, 9037 bytes per second
      > > User15: fetching 10240 bytes took 1.132700 seconds, 9040 bytes per second
      > > User15: fetching 10240 bytes took 1.133200 seconds, 9036 bytes per second
      > > User15: fetching 10240 bytes took 1.132700 seconds, 9040 bytes per second
      > > User15: fetching 10240 bytes took 1.132600 seconds, 9041 bytes per second
      > > ftp_client_pipe_t::skedCallback: get timeout, calling shutdown()
      > > robouser15::unwatchfd 33: stopping
      > > All users dead. Test failed.
      > >
      > > But I run it for wu-ftp (Linux) successfuly.
      > > Right after the bench, I can get x10k.dat using ftp client of linux.
      > > I even run with -n1 (one user) but it fails in the same way.
      > > What's wrong?
      >
      > 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.

      > 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
      Option values:
      -hrostam host name of ftp server
      -P21 port number of ftp server
      -n1 number of users
      -t180 length of run (in seconds)
      -b3600 desired bandwidth (in bytes per second)
      -uanonymous user name
      -probouser@ user password
      -fx10k.dat file to fetch
      -m1500 bytes per 'packet'
      -v1 verbosity
      warning: max_bytes_per_sec 3600 < eclock_hertz() 10000; clamping to 1 byte
      per tick
      warning: max_bytes_per_sec 3600 < eclock_hertz() 10000; clamping to 1 byte
      per tick
      1 users alive, 0 users dead; at least 180 seconds to end of test
      ...
      User0: fetching 10240 bytes took 1.081600 seconds, 9467 bytes per second
      ...
      User0: fetching 10240 bytes took 1.077400 seconds, 9504 bytes per second
      ftp_client_pipe_t::skedCallback: get timeout, calling shutdown()
      robouser0::unwatchfd 3: stopping
      All users dead. Test failed.
      ----------------------------------------------

      Very thanks in advance,
      --Hamid


      [Non-text portions of this message have been removed]
    • Dan Kegel
      ... OK, the firewall is running a special OS. What OS is the server running? What OS is the client running? ... Still looks like ftpbench is timing out on a
      Message 2 of 6 , May 8, 2001
        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
        > Option values:
        > -hrostam host name of ftp server
        > -P21 port number of ftp server
        > -n1 number of users
        > -t180 length of run (in seconds)
        > -b3600 desired bandwidth (in bytes per second)
        > -uanonymous user name
        > -probouser@ user password
        > -fx10k.dat file to fetch
        > -m1500 bytes per 'packet'
        > -v1 verbosity
        > warning: max_bytes_per_sec 3600 < eclock_hertz() 10000; clamping to 1 byte
        > per tick
        > warning: max_bytes_per_sec 3600 < eclock_hertz() 10000; clamping to 1 byte
        > per tick
        > 1 users alive, 0 users dead; at least 180 seconds to end of test
        > ...
        > User0: fetching 10240 bytes took 1.081600 seconds, 9467 bytes per second
        > ...
        > User0: fetching 10240 bytes took 1.077400 seconds, 9504 bytes per second
        > ftp_client_pipe_t::skedCallback: get timeout, calling shutdown()
        > robouser0::unwatchfd 3: stopping
        > All users dead. Test failed.

        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.)

        - Dan
      • Hamid Reza Shahriari
        Dear Dan, 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
        Message 3 of 6 , May 15, 2001
          Dear Dan,

          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.)
          >
          > - Dan
          >
        • Dan Kegel
          Hamid, thanks for letting me know dkftpbench helped! - Dan
          Message 4 of 6 , May 15, 2001
            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.)
          Your message has been successfully submitted and would be delivered to recipients shortly.