Skip to Content.
Sympa Menu

ndt-dev - [ndt-dev] Issue 68 in ndt: Funny web100clt output

Subject: NDT-DEV email list created

List archive

[ndt-dev] Issue 68 in ndt: Funny web100clt output


Chronological Thread 
  • From:
  • To:
  • Subject: [ndt-dev] Issue 68 in ndt: Funny web100clt output
  • Date: Fri, 21 Dec 2012 16:53:02 +0000

Status: New
Owner: ----
Labels: Type-Defect Severity-Medium

New issue 68 by
:
Funny web100clt output
http://code.google.com/p/ndt/issues/detail?id=68

This issue was reported by a user when running web100clt:

Checking for Middleboxes . . . . . . . . . . . . . . . . . . Done
checking for firewalls . . . . . . . . . . . . . . . . . . . Done
running 10s outbound test (client to server) . . . . . 875.96 Mb/s
running 10s inbound test (server to client) . . . . . . 758.64 Mb/s
The slowest link in the end-to-end path is a 10 Gbps 10 Gigabit
Ethernet/OC-192 subnet
Information: The receive buffer should be
-26815615860811546501625050117287787328309182590883722076948913662186352464796058042772490767901870558730916594732010558223785459518905051590698094924136448
kbytes to maximize throughput

Seems a sanity check is lacking.

The scenario is ~1 ms rtt, two machines in the same room, one router
between, one's connected at 1 Gbps (hence the slowest link guess is
wrong), one's connected at 10 Gbps.

But the prescribed receive buffer is apparently some sort of negative
RAM, probably makes use of FTL neutrinos...

That looks like a signed vs. unsigned bug for a 64 bit integer...

--eli




Archive powered by MHonArc 2.6.16.

Top of Page