On Wed, 2008-05-07 at 20:42 +0200, Marc Herbert wrote:
> > I would have thought this would be *the* nr 1 use
> > of iperf: To measure download speed on a NAT'ed ADSL connection, where
> > sockets *only* can be opened in the client->server direction.
>
> You have to keep in mind that NATs are a kludge and that there is
> nothing mandating network applications to take them into
> consideration.
If you want iperf to be popular (and hence well maintained) I guess the
only option is to accept reality as it is with all the NATs.
> > So: Is there any way to test the server->client direction on a socket
> > opened by the client thus enabling testing from behind NAT?
>
> The easiest solution I can think of is the usual one for NAT: setup
> port forwarding to a given NATed address. I think every NAT device
> allows that.
Quite often ISPs or your local BOFH uses NAT and you don't have the
right to forward a port.
> > Now of course all traffic is running inside ssh tunnels. Would that give
> > meaningful results? What should I keep in mind when interpreting these
> > results (that happen to be "roughly" what I was expecting).
>
> I would say that it stays meaningful as long as throughput is small
> enough for encryption not to hog the CPU(s). Say a few tenths of Mb/s.
One can just as well use i.e. GRE tunnels that aren't encrypted. Then
the overhead should (I guess) be pretty linear with the throughput.
I use iperf quite often and would love being able to choose which side
that shall have the listening socket.
Regards,
Daniel
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Iperf-users mailing list
Iperf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iperf-users
