ndt-dev - [ndt-dev] Issue 68 in ndt: Funny web100clt output
Subject: NDT-DEV email list created
List archive
- 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
- [ndt-dev] Issue 68 in ndt: Funny web100clt output, ndt, 12/21/2012
- [ndt-dev] Re: Issue 68 in ndt: Funny web100clt output, ndt, 12/21/2012
Archive powered by MHonArc 2.6.16.