Because it occurs more while lower latency, occurs less while higher latency.
So this type of obstruction is impossible to be happened inside the wireless driver. And obstructions occur much more in upload than download, that's why my phone can still receive some small size notifications while hangs occur, that sounds legitimate, because pushing services don't really need uploads from clients, except Whatsapp, so Whatsapp can't receive any new messages while obstruction hangs occur. That's why much more obstruction hangs while shortcut forwarding engine enabled than SFE disabled. Faster response speed (lower latency), more obstruction hangs, slower response time (higher latency), less obstruction hangs.
Hangs only occur while wifi devices connect to WAN, but never occur while wifi devices connect to LAN or each others.
#LAN SPEED TEST DD WRT FULL#
If something is uploading via wifi and eaten up the full wifi bandwidth, obstructions are keeping coming up (20MB in that case) but connections from other wifi devices hang or even cannot connect to WAN (can connect to LAN). But while the phones are idle or sleeping, or averagely low traffic flow, the obstructions (hangs) occur the most frequent, especially some seldom sudden traffic flow spikes, or some seldom sudden request amount spikes, usually invokes an obstruction (hang). While many things are streaming through wifi, which makes the wifi busy and congested, the least obstructions (hangs) occurred. Because this obstruction phenomenon occurs the most while wifi speed is fast and low usage, or even idle. Thought packets were obstructed inside the wireless driver, but it seems not possible. But uploading from wifi notebook via 49Mbps wifi radio then passing through to the 100Mbps WAN, from a small alley to a wide freeway, any congestion should not be existed, packets should can be transmitted out to the WAN port without obstruction.īut 20MB memory eaten up for wifi uploading? Eaten up much more than ethernet uploading! There are some buffered packets should be obstructed inside somewhere of the kernel transport layer stack space somehow while uploading from wifi devices to WAN.
There should be congestion occurred in the ethernet wired upload test, while packets go through from the 1Gbps LAN link speed to 100Mbps WAN speed, but only eaten up 3MB buffer, seemed to perform well.
#LAN SPEED TEST DD WRT DOWNLOAD#
Both upload and download speed test results of wifi notebook were around 47~49Mbps, the usually full speed of wifi connectivity. Both 2 wired PCs connect to my router via 1Gbps cat6, around 92~97Mbps test results for both upload and download, near the max speed limitation of WAN. My ISP here in Hong Kong provides me 100Mbps service as written in our signed service agreement (yes most of our ISP services here provided by different companies in HK here are so nearly fast and some even 1Gbps, Japan's ISP even faster, not like the slow ISPs in USA I know).
#LAN SPEED TEST DD WRT PC#
But the speed test of the wifi notebook was scary, eaten up around 2MB - 3MB more memory than wired PC in download test, and the most horrible is the wifi upload test, used RAM amount jumped up from around 33.7MB to even over 53MB, 20MB buffer memory eaten up for just uploading a file via wifi! What a miracle! While doing large file download and upload speed test, both 2 wired PCs ran the nearly full WAN speed, and the wifi notebook ran the nearly full wifi speed.Īlthough 16MB buffer was given, each wired PC could only eat up a few MByte of memory in their individual speed test, the usage of EA2700 RAM (64MB total) just jumped up in a range of around 3MB - 4MB, not really much while still 27MB free. Was especially crazily trying the 16MB size default core/tcp r/w buffer size (not so large now), and was doing some WAN speed test from different computers (2 ethernet wired desktop PCs and 1 wifi notebook) one by one (not 3 at the same time), and then I had just observed a very strange phenomenon of RAM usage in DD-WRT status page: Until one day when I was trying different buffer size in kernel transport layer stacks: Tried all wifi configs like WPA2 only + AES only + 802.11g only + 0 Group Key Renewal Interval but not helps, the problem is still existed and the situation is still similar, or even worse by the faster speed. I was wondering about if there are something related to the physical wifi signals or any 802.11 standard encryption. I was just searching for and testing about this annoying bug for a few months. The problem is just no network responses in application programs. Just deeply tested and diagnosed about the hangs in transport layer connections (TCP/UDP) which only occur in wifi connections, but not any physical wifi connectivity disconnections.
0 kommentar(er)
