Bandwidth control should work in both directions. See http://forum.tp-link.com/showthread.php?94717-TL-SG108E-Bandwidth-Control&p=195838&viewfull=1#post195838

irven wrote

how much upload u have?

I tried with 2048 Kbps and 10240 Kbps for download/upload. Uplink is 1 Gbps in both directions.

Sure. Firmware version:





Bandwidth setting for 1024 kbps on port 1:





Some questions for better understanding your problem with TL-SG108E:

First, are you sure it's a bandwidth issue and not a latency issue which causes problems while playing?

If the former:

What is your ISP's downlink and uplink speed?

How many users do you have on your network causing social media traffic? How much traffic is it, did you measure?

It works with my TL-SG108E and I have no idea what could be wrong with your switch.

But if you want to know why IMHO measurements with FTP (or other copy programs) are unreliable, read on.

This are the values with the switch set to a bandwidth limit of 512 kbps ingress/egress and FTP copy of a 350 MB file (note the estimated time left, it's 1.5 hours, so I did interrupt prematurely):

ftp> get movie1.mov
local: movie1.mov remote: movie1.mov
229 Entering Extended Passive Mode (|||28288|)
150 Opening BINARY mode data connection for movie1.mov (367218136 bytes)
2% |* | 8470 KiB 60.07 KiB/s 1:37:08 ETA
^C
receive aborted. Waiting for remote to finish abort.
426 Transfer aborted. Data connection closed.

It tells us to have reached 480 kbps bandwidth (60.07 * 8) after 2% of the file being copied. So far, so good.

Now we try a bandwidth limit of 1,024 kbps ingress/egress and FTP copy of a much smaller file (296 KB):

ftp> get snap.rgb
local: snap.rgb remote: snap.rgb
229 Entering Extended Passive Mode (|||28275|)
150 Opening BINARY mode data connection for snap.rgb (421093 bytes)
100% |*************************************************************| 411 KiB 123.28 KiB/s 00:00 ETA
226 Transfer complete
421093 bytes received in 00:03 (123.02 KiB/s)
ftp>

We get 984 kbit/s (123.02 * 8). Still ok, since we limited bandwidth to 1,024 kbit/s.

Now lets try unlimited bandwidth and a FTP copy of the same file (296 KB):

ftp> get snap.rgb
local: snap.rgb remote: snap.rgb
229 Entering Extended Passive Mode (|||41018|)
150 Opening BINARY mode data connection for snap.rgb (421093 bytes)
100% |*************************************************************| 411 KiB 27.46 MiB/s 00:00 ETA
226 Transfer complete
421093 bytes received in 00:00 (22.40 MiB/s)
ftp>

We reached 179.20 Mbit/s (22.40 * 8). Seems a bit too slow, but this particular FTP server is not the fastest one.

All in all this is a very unreliable method to measure bandwidth if you ask me.


Now lets test upload bandwidth with a faster server and a more reliable measuring method ( Performance CoPilot, developed by Silicon Graphics 20 years ago, now coming back to life again in today's Linux super-computer community. A very reliable measuring tool).

First, I set the bandwidth limits of 1,024 kbps at the TL-SG108E and then fire up iperf to get more exact results not affected by any disk I/O activity.
Next, I monitor the target system with PCP running on a graphical workstation used as the monitoring system, so it does not influence the results:






1.312e+05 is 131,200 bytes/sec = 128 kbytes/sec = 1,025 kbits/sec = 1 mbit/s. Perfect, bandwidth control is working.

No let's try the same with unlimited bandwidth:






1.22e+08 is 122,000,000 bytes/sec = 119,140.625 kbytes/sec = 953,125 kbits/sec = 930.7 Mbit/s (limiting factor being the Ethernet interface card of the server)

As you can see, bandwidth control of the TL-SG108E works as intended.