search

richb-hanover / ndt

Automatically exported from code.google.com/p/ndt
Other
1 stars 0 forks source link

Funny web100clt output #68

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
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
-2681561586081154650162505011728778732830918259088372207694891366218635246479605
8042772490767901870558730916594732010558223785459518905051590698094924136448
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

Original issue reported on code.google.com by kumar.in...@gmail.com on 21 Dec 2012 at 4:52

GoogleCodeExporter commented 9 years ago 
Everything that goes into the receive buffer being printed is a double. Either 
mylink is wrong (unlikely given 10Gbps was given) or avgrtt was wrong.

It's possible that avgrtt somehow overflowed in the Web100 vars and that 
propagated to the receive buffer output.

Original comment by dominic@measurementlab.net on 21 Dec 2012 at 5:54

GoogleCodeExporter commented 9 years ago

Original comment by jslawin...@soldevelo.com on 25 Jun 2014 at 8:20