2013年7月13日 星期六

有關Kmplayer利用VPN播放遠端電腦內媒體檔案LAG問題

經過交叉測試,確認是BUFFER不夠的問題,並且kmplayer似乎對讀取檔案時的流量要求有問題,會有遇到頂的情形。後來改用potplayer問題解決,讀取遇到高禎率時會提高讀取流量,並且BUFFER緩衝可以自己設定,後來設成300MB後問題圓滿解決。

後記:後來發現緩衝最大只能設到1024KB,不過還是一樣撥放順暢,所以推論應該是potplayer比kmplayer對於網路播放處理得比較好,可以對資料來源抓取速率無上限。
後記2:時間過久真的會忘記,緩衝設定的地方在參數選項-濾鏡-來源濾鏡/分離器-(你要撥放的檔案類型)...-緩存大小。並且設定完成後要退出程式重啟才會生效。

有關FTP及Apache上傳速度卡住問題

Apache部分


regedit裡新增兩個十進位DWORD
[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \AFD \Parameters]
DefaultReceiveWindow = 327680
DefaultSendWindow = 327680

資料來源http://smallvoid.com/article/winnt-winsock-buffer.html

Configure the winsock default send- and receive-buffer size

12 October 2002 by Snakefoot | Comment » | Trackback Off
Usually when reading about TCPIP there is only mentioned one Receive Window for a connection, which is used to control congestion created by network latency.

In the WinNT network architecture a layer is placed on top of the TCPIP layer called AFD(Ancillary Function Driver for Winsock). The AFD provides the winsock interface, which is used by most network applications in Windows and is also supporting things like DNS and DHCP.

The AFD uses two windows which acts as a flowcontrol for the application creating the socket:
  • Send Window: Used when the application is sending data over a connection, if more data is sent than the receiver is able to acknowledge then the AFD-Send-Window will block the transfer for the application, when it reaches the limit of the AFD-Send-Window. The application creating the socket can use setsockopt to adjust SO_SNDBUF.
  • Receive Window: Acts just like the TCPIP-Receive Window, and when creating a Winsocket over TCPIP, then AFD will use the TCPIP Receive Window as AFD-Receive Window. The application creating the socket can use setsockopt to adjust SO_RCVBUF.
The default size of the two AFD-Windows is configured at boot time and is dependent on the available amount of physical memory:
  • 4096 bytes if less than 19 MByte RAM
  • 8192 bytes if more than 19 MByte RAM
If using a high latency or high bandwidth network then the AFD windows can affect performance. A small AFD-Send-Window will constantly be blocking the application sending data. A small AFD-Receive-Window will constantly be saturating the application receiving data (And blocking the remote sender). The two AFD-Windows should have the same value as the optimal TCPIP-Receive-Window to get the best speed.

To set the default size of the AFD-Windows use the following DWORD registry keys :
[HKEY_LOCAL_MACHINE \SYSTEM \CurrentControlSet \Services \Afd \Parameters]
DefaultReceiveWindow = 16384
DefaultSendWindow = 16384
Note that the AFD-Windows should be rounded to a multiple of memory page size (Usually 4096 Bytes). Not a multiple of the Maximum Segment Size(MSS) which is recommended for the TCPIP-Window.

Related : Recommended settings for the TCP/IP stack

More Info MSDN - Write Scalable Winsock Apps Using Completion Ports
More info MS KB Q214397
More info MS KB Q246984
More info MS KB Q311084


FTP部分


簡單來說就是transfer buffer size需要加大。之前我的設定32768結果卡在2MB/s(我的上限是4MB/s),改成3276800後現在正常了,寫在這邊供需要的人參考。

資料來源:http://trac.filezilla-project.org/ticket/820

Ticket #820 (closed Bug report)

Opened 8 years ago
Last modified 6 years ago

FileZilla Server incredibly slow

Reported by:prezlaOwned by:ci-dev
Priority:normalComponent:FileZilla Server
Keywords:Cc:prezla, ci-dev, codesquid
Operating system type:Operating system version:

Description 

FileZilla Server 0.9.5 is incredibly slow. I was
running it for and FTP server, but have since swapped
it out for WARFTPd 1.82.0.10 because of the following
performance numbers (notice that FileZilla is almost 3
times slower than WARFTPd, and Microsoft FTP is only
about 1 sec slower than WARFTPd):
FileZilla Server 0.9.5:

ftp> get catalog.pdf
200 Port command successful
150 Opening data channel for file transfer.
226 Transfer OK
ftp: 42509572 bytes received in 18.24Seconds
2330.95Kbytes/sec.
Microsoft FTP Server 5.1 (XP):

ftp> get catalog.pdf
200 PORT command successful.
150 Opening BINARY mode data connection for
catalog.pdf(42509572 bytes).
226 Transfer complete.
ftp: 42509572 bytes received in 8.14Seconds
5221.02Kbytes/sec.
WARFTPd 1.82.00-RC10:

ftp> get catalog.pdf
200 PORT command successful.
150 Opening BINARY mode data connection for catalog.pdf
(42509572 bytes).
226 Transfer complete. 42509572 bytes in 7.00 sec.
(5930.465 Kb/s)
ftp: 42509572 bytes received in 6.99Seconds
6080.61Kbytes/sec.
My platform is:
Intel Pentium III 933
512 MB RAM
Microsoft Windows XP SP2

Change History

Changed 8 years ago by codesquid 

Please have a look at the transfer buffer option in the
settings dialog. The default is 4096 which works best on
most systems. You may have to modify this value, especially
if you have modified any options of your TCP/IP stack or are
using the useless, so-called internet accellerators.

Changed 8 years ago by prezla 

Thanks for the response. Performance has improved
signicantly by increasing the transfer buffer to 16384.
Is there a reason why the default is 4096? I'm assuming
that the buffer is allocated for each connection. If this
is true, I would assume this is done to conserve memory?

Changed 6 years ago by codesquid 

The default buffer sizes have since been increased.

2013年7月2日 星期二

android系統間藉由藍芽共用網路

轉錄http://www.scaine.net/site/2013/01/android-to-android-tethering-over-bluetooth/

Android to Android Tethering over Bluetooth

  1. It’s not battery friendly – both devices need to run their WIFI full time.
  2. It’s a broadcast – the hotspot’s SSID can be hidden of course, but anyone sniffing the airwaves will still see my hotspot and may attempt to hack it. Unlikely that they’d succeed, given that it’s WPA2, but still.
  3. I have to manually turn on the hotspot on my GNex and wait 20 seconds for my N7 to see the connection and get an IP address.
  4. I have to manually turn off the hotspot on my GNex.
  5. I also have to remember to turn back on WIFI on the GNex, or it’ll just use 3G all day thereafter, because turning on a hotspot automatically turns off your WIFI.
Lately, I wondered if there was a better way to do things. Could I use Bluetooth and just leave the service running full time?
Well, since both my devices run Android’s latest “Jelly Bean” release, I thought it would be a doddle to set up. I was wrong, sadly, because there’s a fairly obscure setting you have to set up before hand. However, once you know about that, it’s very simple. In the hope it helps you, here’s the full step by step :
First, and most obviously, turn on the both device’s “Bluetooth” setting.
NetworkSettings
You’ll need to do that on both devices.
Then, pair them up by clicking “Search for devices” on one of the devices and clicking on the name of other device. You’ll be asked to verify a PIN number. It doesn’t matter what the PIN number is, as long as it’s the same PIN number on both devices.
Now, on the GNex, here’s the bit that caused me a headache. Go to Settings, choose More… then choose Tethering & Portable Hotspot. In there, you have tick Bluetooth tethering. If you don’t, the tether will (silently!) fail and you’ll be left, like me, scratching your head.
NetworkSettings-MoreTethering-PortableHotspot
Okay, now you’re ready to use the GNex’s internet via Bluetooth. All you have to do is tell the N7 to actually use it.
On the N7, go to Settings, then click on the word Bluetooth (not the toggle – the word). Finally, click on the name of your GNex you paired earlier. To get it all working, choose Internet Access.
BluetoothSettings
That’s it. Assuming that your GNex has some kind of internet access, then so now will your N7 tablet, via Bluetooth.
I’ve only just completed this myself and initial impressions are that the browsing on my N7 is significantly slower than over WIFI (despite my GNex using WIFI). Obviously, there’s a bandwidth limitation when using Bluetooth – but at around 2Mbits, that shouldn’t hinder web page rendering. Both devices are Bluetooth 3 capable, although the GNex apparently has hardware capable of Bluetooth 4. However, from what I could find, all Bluetooth devices communicate at around 2Mbits unless they use other technology to create high-speed channels, such as Bluetooth 3′s HS capability, which simply creates a WIFI 802.11 channel – which would kind of defeat the purpose of this anyway!
Here’s the advantages of this set up, assuming the speed issue is all in my head :
  1. Low power Bluetooth will preserve battery on the N7.
  2. The devices will pair up when they see each other, so no manual steps to get internet access on the bus. (I need to confirm this – I have a sneaky suspicion that I still need to tell the N7 to use the GNex internet each time they reconnect – which would devalue this for me quite a bit)
  3. I can keep WIFI enabled on the GNex and this tether will simply use that faster connection if it’s available.
  4. I’m not advertising an available WIFI hotspot to everyone on the bus!
Time will tell. I’ll use it for a few days and see how it goes.