Youtube causing high delay on everything.



  • All i've done is configure the traffic shaping using the wizard. Ive set the bandwidth values to 85% of my maximum connection speed (1500/256 kbps actual, set to 1300 and 217). Disabled VOIP priority and penalty box. Enabled p2p queue and catch all, none of the p2p protocols were ticked (As they will be caught under catch all anyway). Catch all bandwidth was left blank.

    I've set options here and there for the programs. HTTP was left on default.

    When i download a youtube video (And probably any other file), my internet comes to a crawl. Pinging a local website i get 500ms (when ICMP is high priority). Ventrilo is high delay even though i set the servers IP/port to high (inbound/outbound).

    What am i doing wrong?







  • My understanding (as I've seen the same thing in a particular network with YouTube) is that the traffic shaper can't really do anything with downstream traffic to you until it gets to your pfSense box.  At that point your downstream pipe is full (due to the download) which would slow down your internet.

    As for slowing down your LAN I'm not sure without knowing more about your layout.  When you say "local website" do you mean a webserver sitting in your LAN?

    I'm trying to find out now if my clients T1 provider can prioritize our downstream UDP traffic to help with VoIP traffic which works fine until someone tries to view a YouTube video or an Outlook client downloads some outrageously funny  ::) attachment that's 5 mbs.  When that happens all incoming (downstream) phone audio gets fragmented while the far end of the conversation (our upstream) is fine.  Doesn't matter if there's 1 person on the phone or 5 lines going.



  • @TreeTopFlyer:

    My understanding (as I've seen the same thing in a particular network with YouTube) is that the traffic shaper can't really do anything with downstream traffic to you until it gets to your pfSense box.  At that point your downstream pipe is full (due to the download) which would slow down your internet.

    As for slowing down your LAN I'm not sure without knowing more about your layout.  When you say "local website" do you mean a webserver sitting in your LAN?

    I'm trying to find out now if my clients T1 provider can prioritize our downstream UDP traffic to help with VoIP traffic which works fine until someone tries to view a YouTube video or an Outlook client downloads some outrageously funny  ::) attachment that's 5 mbs.  When that happens all incoming (downstream) phone audio gets fragmented while the far end of the conversation (our upstream) is fine.  Doesn't matter if there's 1 person on the phone or 5 lines going.

    While what your saying sounds reasonable at first, but technically ALTQ should be able to handle this.

    Here's why:  Since the incoming traffic is coming in as packets, at first you would be correct in that the incoming traffic would be overwhelming the other traffic you want coming in, and the incoming queue would be filled with youtube packets.  However, once just one of the higher priority packets enters that queue then it is pulled out before all others, and acknowledged, before any of the previously queued up youtube packets.  So then the next VoIP packet would come down the line pretty quick and get precedence again.  The fact that the packets are 1500 bytes in length should ensure that the VoIP quickly starts getting precedence, and the youtube video starts throttling back.

    There definitely seems to be a problem with the way ALTQ is getting setup by PFSense, because ALTQ by itself should be able to handle this.



  • ive read things here and there on this forum and one thing pfsense can do is set hard limits on queues and borrow bandwdth when available.

    if i hard cap p2pcatch all to say 500 kbps and allow it to borrow 1000kbps if its not being used, i think ky rpbem would be solved.

    as to how to do ths, i have no idea



  • Again, from my understanding, once the lower priority (downstream) traffic hits the pfSense box the packet is dropped (which would be correct), with no ACK back, and the packet is sent again thus flooding the downstream pipe again.

    I've done a test where I "reserved" 512kb bandwidth for VoIP on a T1 (symetric 1.5 mbs).  Running a speed test resulted in 1.5 mb down (which I "requested") and 1.0 mb upload (which was managed by the traffic shaper).



  • Again, from my understanding, once the lower priority (downstream) traffic hits the pfSense box the packet is dropped (which would be correct), with no ACK back, and the packet is sent again thus flooding the downstream pipe again.

    Surely you could delay the ACK or tell the sender that you are over loaded, Im no TCP expert. It's doable using NetLimiter.



  • @TreeTopFlyer:

    Again, from my understanding, once the lower priority (downstream) traffic hits the pfSense box the packet is dropped (which would be correct), with no ACK back, and the packet is sent again thus flooding the downstream pipe again.

    If the sender is behaving appropriately, the sender would be naturally throttled just by the fact that it is waiting for the ACK.  Thus each packet that is dropped will delay the sender, and allow the higher priority packets to come through.


Locked