that affects tx rate reporting.
>
> Bob
> -----Original Message-
> From: Martin T [mailto:m4rtn...@gmail.com]
> Sent: Thursday, September 25, 2014 4:10 PM
> To: Bob (Robert) McMahon
> Cc: Marc Herbert; Andrew Gallatin; iperf-users@lists.sourceforge.net
> Subject: Re: [Ipe
lso, in these cases, the client will
> include the packet in the transmit rate calculation because the kernel did
> accept the packet even though the ultimate transmit failed.
>
> Bob
> -Original Message-
> From: Martin T [mailto:m4rtn...@gmail.com]
> Sent: Monday, Sept
ob (Robert) McMahon
wrote:
> Hi Martin,
>
> Yes on the summing of the return values to get the transmit rate.
>
> Bob
> -Original Message-
> From: Martin T [mailto:m4rtn...@gmail.com]
> Sent: Sunday, September 21, 2014 1:31 PM
> To: Marc Herbert; B
r of write() per seconds.
> There is a "physical" limit caused by either the CPU, or memory bandwidth,
> or scheduling, etc. What is the maximum UDP sending rate you ever saw
> reported on this specific hardware and operating system?
>
> As already suggested on this lis
14, Marc Herbert wrote:
> Martin,
>
> What makes you think iperf counts local packet losses differently from
> network packet losses?
>
> Cheers,
>
> Marc
>
> 2014-09-18 8:50 GMT+01:00 Martin T :
>
>> Andrew,
>>
>> I'll rephrase my question whic
don't get an error, which is what benchmarks
> do.
>
> On Wed, Sep 17, 2014 at 7:53 AM, Andrew Gallatin
> wrote:
>
>> There is no way to know. UDP is lossy, after all.
>>
>> On Wed, Sep 17, 2014 at 7:47 AM, Martin T wrote:
>>
>>> Andrew,
>&g
ode, it looked like it
> ignores NET_SOFTERROR returns & retries.It would be nice if it reported
> the amount of ENOBUF errors it received like netperf does..
>
> On Wed, Sep 17, 2014 at 4:09 AM, Martin T wrote:
>
>> Andrew, Bob,
>>
>> did I understand you co
le12) : iperf
> -s -w 7350000 -l 1470 -u -i 0.1 -fb -p 60001
> 20:45:09 HNDLR udp-tx Close actions for event handler
> (43602lx1,file13)
> 20:45:09 INFO udp-tx Closed : (43602lx1,file13)
>
> Bob
> -Original Message-
> From: Bob (Robert) McMahon
> Se
CVERR on the sending socket(s)?
>>
>>
>>
>> Thanks,
>>
>> Bob
>>
>> *From:* Andrew Gallatin [mailto:galla...@gmail.com]
>> *Sent:* Monday, September 08, 2014 6:53 AM
>> *To:* Martin T
>> *Cc:* iperf-users
>> *Subject:* Re
te:
> AFAIK iperf is using the regular BSD socket API (discard this message
> if it does not). The BSP API provides very limited information but on
> the other hand it makes sure iperf numbers are exactly the numbers any
> application would get. Continued below.
>
> 2014-09-06 13:06
f.user/202
>>
>> I remember seeing a few others across the ages.... Use various archives /
>> search engines / search keywords?
>>
>>
>>
>> 2014-08-22 9:20 GMT+01:00 Martin T :
>>
>>> Thanks for the reply! I'll check the receiving side. Could
Hi,
if one executes for example "iperf -c 178.62.60.141 -fm -b 100m -u -t
30 -i 10", then after each 10 second interval Iperf client prints out
the amount of data it has transferred in mebibytes:
root@vserver:~# iperf -c 178.62.60.141 -fm -b 100m -u -t 30 -i 10
WARNING: option -b implies udp test
0.5 -u and show the results from the server?
>
> Bob
> From: Metod Kozelj [mailto:metod.koz...@lugos.si]
> Sent: Sunday, August 24, 2014 11:45 PM
> To: Bob (Robert) McMahon; Martin T
> Cc: iperf-users@lists.sourceforge.net
> Subject: Re: [Iperf-users] Iperf client 2.0.5 shows unr
just negated
> if ( reportstruct->packetID < 0 ) {
> reportstruct->packetID = -reportstruct->packetID;
> currLen = -1;
> }
>
> Bob
> -Original Message-
> From: Bob (Robert) McMahon
> Sent: Friday, August 22, 2014 10:11 AM
> To: 'Martin T'; iperf-u
> The report shall report that the receiver did not see the generated
> packets.
> Sandro
>
>
> On 22 August 2014 11:03, Martin T wrote:
>
>> Hi,
>>
>> please see the full output below:
>>
>> root@vserver:~# iperf -c 10.10.10.1 -fm -t 600 -i60 -u
Hi,
if I execute "iperf -c 10.10.10.1 -fm -t 10 -u -b 50m", then am I
correct that the last datagram sent by the Iperf client includes a
special pattern which is an indication for Iperf server to send the
server report? First bytes of the last datagram should be like
ff:ff:fc:ac:53:f6:f1:57:00:04:
H)-2),oct(115),10);'
> -- echo 16i[q]sa[ln0=aln100%Pln100/snlbx]sbA0D4D465452snlb xq | dc
>
> --
>
> BOFH excuse #299:
>
> The data on your hard drive is out of balance.
>
>
>
> Martin T je d
Thanks for the reply! I'll check the receiving side. Could you please
point me to an article/discussion describing the blocking- and
non-blocking NIC drivers? I didn't find it from iperf-users mailing
list..
regards,
Martin
On 8/21/14, Metod Kozelj wrote:
> Hi,
>
>
> Ma
Metod,
but shouldn't the Iperf client send out traffic at 500Mbps as I had
"-b 500m" specified? In my example is prints unrealistic
bandwidth(~60Gbps) results.
regards,
Martin
On 8/21/14, Metod Kozelj wrote:
> Hi,
>
> Martin T je dne 21/08/14 15:12 napisal-a:
&
I see, thanks!
regards,
Martin
On 8/21/14, Metod Kozelj wrote:
> Hi,
>
> Martin T je dne 21/08/14 14:17 napisal-a:
>> How did Iperf calculate, that it sent 71.5 MBytes? I mean it says it
>> has sent 51021 datagrams and one datagram is 1470B so I should have
>> sent 7
Hi,
if I executed "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" in a
virtual-machine with GigE vNIC, then Iperf client(version 2.0.5) under
Debian sent traffic at 120Mbps during all the intervals. If I replaced
the OS in virtual-server with CentOS, the same Iperf release with the
same command
Hi,
if I execute "iperf -c 10.10.10.1 -fm -t 600 -i 60 -u -b 500m" and
10.10.10.1 is behind the firewall so that Iperf client is not able to
reach it, then I will see following results printed by Iperf client:
[ ID] IntervalTransfer Bandwidth
[ 3] 0.0 - 60
Hi,
after an Iperf test, I got following results:
[root@ ~]# iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m
Server listening on UDP port 5001
Receiving 1470 byte datagrams
UDP buffer size: 0.04 MByte (default)
--
your case?
>
> http://www.embedded-bits.co.uk/2008/multiple-network-gotcha/
>
>
> 2012/12/9 Martin T :
>> Hello,
>>
>> I have a following simple network topology consisting of two laptops
>> and one L2 switch facing with trunk ports to laptops:
>>
>>
Hello,
I have a following simple network topology consisting of two laptops
and one L2 switch facing with trunk ports to laptops:
T60[eth0] <-> switch <-> [eth0]T42
Both T60 and T42 machines have three sub-interfaces:
T60:~ # ip addr show | grep "eth0.[0-9]*$"
inet 10.10.1.1/24 brd 10.10.
I have a following very simple setup:
PC1[eth0] <-> [fxp0]PC2
Both PC1 and PC2 have Iperf version 2.0.5 installed. eth0 in PC1 has
IPv4 address 10.10.10.1 and fxp0 in PC2 has IPv4 address 10.10.10.2.
PC1 and PC2 NIC's are connected with straight-through cable.
If I execute Iperf server in PC2 l
lues?
regards,
martin
2011/4/4 Marc Herbert :
> On Mon, 4 Apr 2011, Martin T wrote:
>
>> If I execute Iperf(version 2.0.5 (08 Jul 2010) pthreads) client with
>> "iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m -w 4m" command, Iperf
>> server with "iperf -s u -
If I execute Iperf(version 2.0.5 (08 Jul 2010) pthreads) client with
"iperf -c 192.168.2.1 -u -fm -t60 -d -b 10m -w 4m" command, Iperf
server with "iperf -s u -w 4m" command, Iperf client with "iperf -c
192.168.1.1 -t 60 -w 2m" command etc, I get the "TCP window size: 50.0
KByte (WARNING: requested
28 matches
Mail list logo
