Web Browsing Performance affected adversely with a single PC uploading
-
its not so much that the bandwidth requirements are too high.. But that you have a queue of packets.. If you fill up the queue/buffer, then have to wait in line.. This cause delay, dns is time sensitive.. Users are use to page instantly coming up when they put in http://instantgrat.com etc…
I agree a dns query is small, also a http get also small.. But if you have 10,000 packets in front of your query -- takes time for that query to happen.. Term sometime used to describe this problem is buffer bloat..
Filling up your upload pipe can kill performance.. Don't fill up your pipe is easy fix.. Do pfsense show your upload pipe full?? Looking at your traffic graph?
-
Not really sure what's up for disussion here…. When your uplink is saturated by the cloud shit, everyone will suffer from high latency. Get a better uplink or set up a limiter on the host. While you may consider this a "a fairly normal task", an idiot trying to upload tens/hundreds of gigs of data to cloud will kill your connectivity for days.
-
doktornotor, does your Cloud shit = a single PC using google drive is enough to affect every other user in a network but on a home connection (slower speed, no pfSense) the same problem doesn't show.
Does anyone have a better idea for this problem and how to resolve?
-
there is no problem to solve.
this is normal behavior.previous posts gave you answers to your question: limiters and/or qos
-
does your Cloud shit = a single PC using google drive is enough to affect every other user in a network but on a home connection (slower speed, no pfSense) the same problem doesn't show.
I don't know about that, but I know that my home connection (30 Mb down, 1 Mb up) turns to shit for everyone else when I'm syncing local data to my ownCloud. No pfSense involved. It's basic networking. If you have a tiny uplink and you saturate it, then everything else will be slow. Simply increasing your upstream bandwidth won't help as your cloud guy will still be pounding the link and continue to saturate it. Traffic shaping is your only real option, and you can solve it by prioritizing DNS and ACK above HTTP/S. You can ask more people if you don't like these answers, but nothing will change.
-
Owncloud is a complete disaster. And – so are most of similar "solutions". There's the Synology NAS stuff with their "local cloud" stuff. I have seen their supershity sync utility for Windows kill networks at a whim. Repeatedly.
-
Users complain when cloud upload is slow, then they complain when it kills the pipe when it uses it all.. Can not win ;)
When companies do stuff in their sync software to try and make sure it doesn't fill the pipe users complain its slow, when they use the whole pipe they complain that their network is slow.. And then these companies continue to sell internet connections with 30/1 – that is a really bad ratio.. Could you even fill that download pipe before your upload is saturated with acks?
-
Could you even fill that download pipe before your upload is saturated with acks?
I can reliably pump about 25 Mbps through it. It was a 25/1 connection that I upgraded to 30/5, but my upload tests all seem to max out at 1 Mbps. I'll have to get on my ISP about that when I have some time.
-
Well if your paying for 30/5 and seeing 25/1 yeah I would complain ;)
-
This is an issue of buffer bloat. The simple solution is to enable CoDel or FairQ traffic shapers on your WAN interface. Just set them to a bandwidth slightly less than your actual bandwidth.
If you need more fine-grain control, then you'll need to delve into traffic shaping, which is a much more complicated answer to your question.
-
yeah I would complain ;)
I already started the process and they came back with a huge list of steps to go through, including connecting my PC directly to the cable modem for the duration of the support ticket. This is not possible in the real world as my kids, wife and MIL would kill me long before the ISP could fix the problem. It's like I have to arrange for a maintenance window in the early or late hours in my own house :-\
-
@KOM:
yeah I would complain ;)
I already started the process and they came back with a huge list of steps to go through, including connecting my PC directly to the cable modem for the duration of the support ticket. This is not possible in the real world as my kids, wife and MIL would kill me long before the ISP could fix the problem. It's like I have to arrange for a maintenance window in the early or late hours in my own house :-\
In instances like that, I add a switch between the modem and the router so I don't have to take the router and its network offline. Then, you can have your PC plugged in and configured however you like. If your modem isn't set to pass through and has a DHCP server on it, then you just plug in and test. You're still inside the LAN of the modem, just not inside the LAN of you router. If you have a single static IP and its set to bridge mode it gets tricky since you can't have them both in simultaneously but if you have multiple statics it becomes a breeze again. Good luck!
-
Or just tell them sure I did that - wtf do they know.. They are most likely level 1 just running through a script.. Have them reprovision your modem with the speeds your suppose to be getting..
-
@KOM:
… they came back with a huge list of steps to go through, including connecting my PC directly to the cable modem for the duration of the support ticket.
Did they specify what the PC OS has to be? If not, install pfSense on a PC and plug it. If they ask, tell them you use FreeBSD. If they require Windows tell them to show you that requirement in their ToS. If they still insist, tell them to send you a Windows installation CD and product key.
-
Not a strange problem at all. In fact to be expected.
http://cable-dsl.navasgroup.com/#Asymmetry
Blast from the past.
-
Did they specify what the PC OS has to be?
No but that wasn't relevant. The issue was that they expected my PC to have exclusive access to the router for the duration of the ticket. That means my whole family is offline for potentially days, and this is unacceptable. That's why I haven't gone further in the troubleshooting process.
-
@KOM:
No but that wasn't relevant. The issue was that they expected my PC to have exclusive access to the router for the duration of the ticket. That means my whole family is offline for potentially days, and this is unacceptable. That's why I haven't gone further in the troubleshooting process.
If they are anything like my ISP they will look at the attached MAC address and assume from that what you have connected. If your using a PC as your router hardware it just might fool them.
-
The issue was that they expected my PC to have exclusive access to the router for the duration of the ticket.
That is normally about 20 to 30 mins.
That means my whole family is offline for potentially days, and this is unacceptable.
DAYS!? What? It should not take days.
You got to skip level 1 and talk to someone higher up.
-
After tests are run on my end, I submit data and wait for a response. That in itself can take hours. Then some time to investigate the problem on their end etc etc and time slips away. It's not like I've got any SLA guarantees to leverage. I'll get to it eventually but it's not really a pressing concern for me at the moment. We're getting the extra downstream bandwidth I paid for, and I couldn't really care about upstream.
-
I had a similar issue that occurred with either an upload or a download by one machine locking out other machines. This started when I installed pfSense ( 2.2.2) in place of a Cisco ASA.
DSL Supports first move was to have me remove pfSense and of course the problem was solved as far as they were concerned since the problem only existed with pfSense inline.
After much research and packet sniffing I disabled Queue management or Q0S on the DSL router. (F@ST 1704N) That did the trick. It was on by default. Every few months they reset me and I have to turn it off again and re-enter the virtual servers.
What got my eye here is your reference to RRT time increasing. Was the same here.
