Search found 20 matches

by orangetek
Thu Mar 28, 2019 4:04 am
Forum: Gargoyle Development
Topic: Mikrotik 16mb SPI/NOR build
Replies: 1
Views: 7521

Mikrotik 16mb SPI/NOR build

Hi,

Has anyone managed to build for Mikrotik devices? I tried but my final images dont boot (initramfs). I also noticed that the image size is over 11mb. Some guidance would be great.
Forgot to mention, OpenWRT 18.06 does work.

Regards
by orangetek
Sat Dec 19, 2015 7:08 am
Forum: Monitoring / Quota / QoS Issues
Topic: Understanding QoS
Replies: 7
Views: 6433

Re: Understanding QoS

Thanks so much Volaris and orangetec! I think I understand most of it now. :) You guys are awesome. I still have a nagging question on my mind regarding QoS (upload) : So I found that my optimal "Maximum (upload) Bandwidth" is 550kbit/s by having Computer 1 upload a big file at full throt...
by orangetek
Fri Dec 18, 2015 5:54 am
Forum: Monitoring / Quota / QoS Issues
Topic: Understanding QoS
Replies: 7
Views: 6433

Re: Understanding QoS

Limiting your upload to 90% of it's total capacity is only part of the solution. That alone will not resolve your issue. You need to understand that TCP sends (upload) an ACK (ackknowledgment) packet for every packet you download. If that ack packet cannot be sent because your upload is saturated, t...
by orangetek
Fri Dec 11, 2015 6:22 am
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

Hi tapper. I had the same issue and it turned it out that my isp was dropping pings regardless of link saturation. This may not be the case for you but i would monitor your pings just to make sure. I have modified ACC to ignore ping timeouts and it has helped a lot.
by orangetek
Tue Dec 01, 2015 5:07 am
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

Ok guy's, a better option was to change //This variable will be set in pr_pack() if we get a pong that matched //our ping, but in case we don't get we initialize to the period. rawfltime=period; to //This variable will be set in pr_pack() if we get a pong that matched //our ping, but in case we don'...
by orangetek
Mon Nov 30, 2015 4:48 am
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

Well i finally got around to recompiling gargoyle with a modification to ACC. After much testing i went with completely ignoring ping timeouts by replacing the timeout value with the ping limit. Got up this morning and my max limit is almost where it was last night which means its working :) The ori...
by orangetek
Thu Oct 01, 2015 11:19 am
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

Thanks pbix, ill try it this evening during peak hours when the problem starts. I am going on the assumption that a ping timeout cause by bandwidth starvation will show a rapid increase in RTT before the timeout occurs. If ACC is fast enough at reducing the max limit then a timeout should not even o...
by orangetek
Thu Oct 01, 2015 7:23 am
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

Hi pbix, we have 2 120mb/8mb wan connections, each connected to an x86 gargoyle box modded for quad core/4gb. They both go to a 9 core MikroTik cloudCore router that handles the load balancing for both wans and also runs a customized hotspot for our clients. Our interest in Gargoyle is the ACC becau...
by orangetek
Wed Sep 30, 2015 7:59 pm
Forum: Monitoring / Quota / QoS Issues
Topic: Disappointing bufferbloat
Replies: 48
Views: 39997

Re: Disappointing bufferbloat

It works because anything other than important packets (0-512 bytes) go to the default service class. You could set the percentages 50/50 and it would work the same because the packets in the classification rule would never use 50% of your bandwidth. Understanding what those packets are and why they...