Iperf related issues

Home › Help Forum - Questions, Comments, Feature Requests - NetSpot › Issues › Iperf related issues

Tagged: iperf, issues

Viewing 15 posts - 1 through 15 (of 18 total)
1 2
  • Author
    Posts
  • October 10, 2014 at 4:43 pm #2673

    urgui
    Participant

    Many thanks for iperf support, it’s really welcome, but unfortunately there some … cough … problems in it ;).

    * It’s unclear from configuration what “Always use TCP speed” does. Is it related to UDP? But it’s not greyed out if UDP is not selected. What is TCP speed?

    * If “Conduct speed test via UDP” is selected, but “Always use TCP speed” isn’t, Netspot crashes while performing the test. According to server log only one datagram is really transferred. (Btw, is UDP speed really in megabytes per second (capital B)?)

    * Legend is not included in exported heatmap images for iperf heatmaps and default name for these is always “<survey>-<zone>-signal-level”.

    * UDP Jitter values are shown all as 0 on the map, although it probably makes sense as according to the dialog header it’s in seconds(!) ;).

    * None of colour schemes makes sense for UDP jitter. Add a one from green (small values in left) to red (high values)?

    October 13, 2014 at 7:12 pm #2708

    Alex – NetSpot
    Keymaster

    Thanks for reporting those… checking these issues now.

    October 15, 2014 at 4:07 am #2711

    Alex – NetSpot
    Keymaster

    Hi again… and yes, I have to confirm some of the issues that need to be polished and will be asap.

    > Always use TCP speed

    We are checking the relation among the controls in the Preferences. Technically the option means that while testing the speed via UDP the speed value received via TCP will be used.

    > …Netspot crashes while performing the test

    Did you send the crash report to us?

    > According to server log only one datagram is really transferred.

    Is the speed for testing specified?

    > is UDP speed really in megabytes per second (capital B)?

    A typo… thanks for pointing that out. NetSpot cannot have typos like this :)

    > Legend is not included… and “<survey>-<zone>-signal-level”.

    Checking this and will be fixed.

    > UDP Jitter values are shown all as 0

    Was a UDP test completed? If not, there’s no way to calculate the jitter.

    > None of colour schemes makes sense for UDP jitter

    You are right here, we’ll see what can be done.

    Thanks again!

    October 15, 2014 at 6:45 am #2712

    urgui
    Participant

    > We are checking the relation among the controls in the Preferences.
    > Technically the option means that while testing the speed via UDP the
    > speed value received via TCP will be used.

    OK. I couldn’t think this out myself, so I think that GUI needs some better logic to reflect this. What about something like this (clearer with fixed width font):

    [x] Conduct speed test via TCP
    [x] Conduct speed test via UDP
    (*) Speed for UDP tests: [ 1 Mbps ]
    ( ) Use speed value received via TCP test

    And it should react to changes in UI – both radiobutton options should be greyed out if UDP checkbox is not selected and TCP speed radiobutton should be greyed out if TCP checkbox is not selected. Probably needs better wording as well, english is not my native language.

    > Did you send the crash report to us?

    Nope, but you can view crash report here: http://pastebin.com/zm1PMckc
    And screenshot of settings used to trigger it here: http://picpaste.com/netspot-preferences-F9cneyrh.png

    Nothing fancy.

    > Was a UDP test completed? If not, there’s no way to calculate the jitter.

    Yes, it was and according to the gradient on the heatmap there is some variation in it as well, but all values are 0’s in both – in the left panel and in the popup on the heatmap. My comment with smiley was about this info:

    http://picpaste.com/netspot-jitter-rZpK4djR.png

    I mean – really in seconds? If it’s really rounded to integer in seconds, then of course these are all zeroes.

    Or maybe it’s related to the another problem I discovered – UDP upload test is really a TCP. Ie if both TCP and UDP tests are selected, following tests are really conducted according to the iperf3 server log and tcpdump:

    1) Download in TCP
    2) Upload in TCP
    3) Download in UDP
    4) Upload in TCP

    October 15, 2014 at 3:24 pm #2713

    Alex – NetSpot
    Keymaster

    Working on… I’ll keep you updated. Thanks so much for a detailed follow-up.

    October 31, 2014 at 6:53 pm #2807

    Alex – NetSpot
    Keymaster

    Can you give this build a try? https://netspotapp.com/buildz/2.4.x/2.4.572/NetSpot.dmg
    All the issues you reported should be fixed. The build will go public shortly.

    October 31, 2014 at 8:51 pm #2812

    urgui
    Participant

    * The UDP speed labels still says MBps.

    * I switched on UDP test, but didn’t realize that I can’t reach my iperf3 server via UDP yet. Dialog appeared stating that test failed – connection refused. All is correct so far, but by accident I pressed “Try again” button and it rendered NetSpot unusable. It just kept spinning there about 10 minutes with no way to cancel it. After that my MacOSX stated that application isn’t responding any more. Indeed …

    * OK, configured local iperf3 server. Sometimes it works, but often it hangs and I’m forced to quit Netspot again. Backtrace from one of such quits is here – http://pastebin.com/s79j5Xt7

    Sorry for breaking so nice program, but such are my habbits from days when I did a lot of software testing ;).

    October 31, 2014 at 9:54 pm #2813

    Alex – NetSpot
    Keymaster

    We are really glad to have such clients as you. Keep breaking it. We’ll fix it, it’s the job we love :)

    November 1, 2014 at 6:29 am #2814

    urgui
    Participant

    I fooled around some more and realised that I lied a bit. This “Try again” dialog wasn’t about UDP test probably, but about TCP upload test.

    There seems to be two issues with iperf3 tests in this build.

    1) There is no timeout for UDP test. My firewall is dropping iperf3 UDP traffic and if Netspot attempts to use it, it never timeouts and no way to cancel the test. It’s true for both cases – for testing connection in preferences and conducting test in scanning. Sometimes, if I wait long enough, it renders Netspot unusable even if I restart it and reconfigure iperf3 (see backtrace etc from previous post), but I suspect it’s something in the system and is really beyond the scope. If I restart computer, there is no hangs, but …

    2) In 7 cases out of 10, TCP upload test fails. There is no problem with server, if I press “Try again” button, it’s completed in all cases. Might be some kind of timing issue. I captured such failed case with tcpdump as well, I can send it to you privately if needed.

    Iperf visualisation issues are resolved indeed, thanks.

    And if developers are responsive like you, the pleasure to break stuff is purely mine ;).

    November 18, 2014 at 10:36 pm #2831

    Alex – NetSpot
    Keymaster

    It does sound like both issues that you mentioned in your last post are related to timeouts in iperf3. Is there any chance you can get a clean compiled official iperf3 client and test it in the same conditions as NetSpot? Based on our tests, we suspect you may have the same issues, and they are somewhere inside iperf lib. We keep our own tests and would update you once we find out anything new. We might be wrong, as we could not reproduce all of the bugs reported by you.

    ps: and I’m sorry for a few weeks of silence… had to wait longer for my team to come back with more or less useful update to your case.

    November 23, 2014 at 3:47 pm #2835

    urgui
    Participant

    Yes, I looked a little bit iperf3 code and indeed the UDP issue is in iperf3 code – connect() doesn’t return. As far as I can see it’s normal and needs some special code to handle it – alert() or setsockopt() timeouts. I’m not sure how portable these are though.

    But I don’t see how I can reproduce the TCP upload failing issue. What I see from dumps is kind of messy, but client seems to start this. As I don’t have a source to look at how you use iperf_* calls I’m not sure of course and it might be some kind of race as well. Can you give me a iperf3 related snippet from your code so I can test it and possibly report the issue to the iperf3 developers?

    November 24, 2014 at 3:21 pm #2836

    hubiao
    Participant

    Hi,

    I am not totally sure, but it seems I had the similar issue when using Netspot2.4. After I updated iperf3 to the latest version. The problem has gone.
    ——–
    In our before TCP test, Netspot always hangs for scanning in all my tests. If I wait long time enough, iperf3 on the server side will receive: iperf3: error – unable to receive results.

    Hope this can provide some information.

    November 25, 2014 at 7:10 am #2838

    urgui
    Participant

    This fixes “no UDP timeout” problem for me: https://github.com/esnet/iperf/pull/222

    November 25, 2014 at 5:33 pm #2842

    Alex – NetSpot
    Keymaster

    I’ll follow-up after speaking with our developers. Thanks

    December 4, 2014 at 9:45 pm #2860

    Alex – NetSpot
    Keymaster

    We’ve updated the version of iperf3 used in NetSpot. The new build will be online next week. It’s our main understanding that the developers of iperf3 would apply the fixes in their code if they find them reasonable. We’ll keep monitoring this thread as well.

  • Author
    Posts
Viewing 15 posts - 1 through 15 (of 18 total)
1 2

You must be logged in to reply to this topic.