Forum Replies Created
-
AuthorPosts
-
urguiParticipantI will push it to iperf3 developers.
But “Conduct speed test via UDP at” suffix is still MBps. Should it be? :)
urguiParticipantPossible workaround – https://medium.com/@mariociabarra/wifried-ios-8-wifi-performance-issues-3029a164ce94
urguiParticipantThis fixes “no UDP timeout” problem for me: https://github.com/esnet/iperf/pull/222
urguiParticipantYes, 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?
urguiParticipantThats the point – you can’t gather WiFi related info from iOS via official APIs, because there is none. There is no apps for iOS like WiFi Analyzer on Android for example. OK, correction – there is, but you need to have a jailbreaked device.
urguiParticipantI 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 ;).
urguiParticipant* 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 ;).
urguiParticipantBut back to the topic.
I don’t think that there is a chance to support external adapters in this way. AFAIK Apple airport API supports very limited set of Broadcom PCI(e) chips and that’s it. I’ve never heard of any USB WiFi device working out of the box for MacOSX. It’s always third party drivers + their own network utility.
Of course the problem with third party is that you have to connect with API they provide and these are probably with different vendors. I’d think about trying to make contact with some MacOSX friendly third party vendor and focusing on that. For example ASUS is a one making MacOSX drivers for USB WiFi adapters and has (relatively ;) good reputation and quality.
And of course there is a Wi-Spy. Although damn expensive (I don’t even see the price listed any more in the Metageek site :), it’s something many of us (semi)pros would use probably.
urguiParticipantIf I may comment as relatively new user of NetSpot professional …
I suggest to be a bit more open regarding issues related to introduction of features like this. Often users not familiar with internals of Apple OS’es, policies etc can’t understand why it’s sometimes so hard to support stuff from outside of the Apple world, implement features Apple haven’t meant to be implemented etc. And it leads to (unnecessary) frustration from users, but not pointed to the reality (Apple), but to the developers.
As I understand at the moment (correct me if I’m wrong) it is possible to use external interfaces, but these have to use AirPort API and export all necessary info to it. And there is a (internal) test tool available to test capabilities of devices. No? Is there a reason why such tool isn’t public?
Also a word about “coming next features” announcements. I understand that developers want to share some info about future – ie “yes, we are implementing all this stuff”. But again, fo example I see a lot of promises has been made in the 2.1 release notes – WiSpy support, predictive surveys, external devices support. We all (me too) would like to see it. And don’t get me wrong – at least from my point of view I never make buying decisions based on promises. And I understand that it takes time to implement all this, but again – users are just seeing unfulfilled promises.
Just think about it, please ;).
urguiParticipant> 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 testAnd 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.pngNothing 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 -
AuthorPosts
