WiFi UDP testing


#1

Is anyone up and about presently (10PM PDT)? I m testing various WiFi access points to see which ones handle UDP datagrams well. My old Linksys WRT54G clearly deos not. I have a NetGear NightHawk x6-3200 and am in need of another person to chat to for a short while.

I shall be in the sandbox

I will try again Monday.


#2

I brought this issue up last year around this time and it was, bluntly put, ignored. I have a WRT54G and noticed many oddities - ping times would be at some normal level and increase about 5 times normal then return to normal level. This would repeat for Interface run duration.

With my Motorola SBG6580 cable modem/wireless router it would do same, but, worse leading to it eventually ceasing to work leading to needing a reboot for it as it would no longer route any net traffic for anything to any computer attached to it.

Netgear WGR614v9 exhibits cyclical massive increase in ping time and after about 3 hours would cease working with Interface to remote servers but would be usable for other applications.

Using any of those with a cable connection vs wireless resulted in normal operation. I began digging with wireshark and saw some interesting metrics, but, nothing I could point to and say this is the problem.


#3

The WRT54G tosses UDP datagrams quickly. That is what it picks first to dump when its slosh buffers fill up. I stopped using it to connect to HF and switched to direct Ethernet connection in order to not sound like a modulated buzz saw when conversing with fellow avatars. All routers do this to some extent and WiFi access do that more so since they are multiplexing between all the devices connected to them.

A good example of a decent router is my net connection in which the path is a 5 mile microwave link. The radios have a 50MB slosh buffer and they use a smart selective UDP drop algorithm to adjust to the data flow.

What I am testing is to see if the Nighthawk x6-3200 has sufficient buffering to be usable in a high Fidelity audio chat context.


#4

For what it’s worth - to the HF developers - it might be worth looking at how other UDP heavy applications manage things such that this isn’t an issue. If 2 of the minuscule crowd currently tinkering with this see such issues it will certainly be a big deal should the crowd expand.


#5

I can tell you right now most of the UDP heavy apps do poorly when run through consumer grade WiFi access points. In terms of audio chat in HF, VOIP apps have similar characteristics.

What I wonder is that now with ATP (another UDP agent) running, how will asset transfers affect the UDP audio, especially when flowing through WiFi. It would be a shame if HF required hard line connections always.