This is wrong. Pause frames contain quanta value, which is requested period of “stop” time from sender. Maximum flow control induced delay for a 1Gbps link = 33.55ms.
In any case, what you and CGGXANNX would have me believe is that nomercymahem and dogenzenji both luckily had or bought some random dumb switch which somehow can send maximum throughput on the same 1Gbps link in front of router, without loss or latency, when routerboard itself directly hooked up cannot? Meanwhile, other models/makes of routers (different ones, mind you) can be directly connected without fiddling with flow control and also not have a problem? Hmmm.
For me, if I hook up ETH1 on my hEX refresh to the port on my ONT, I seem to have a failure to properly auto-negotiate link speed. Even though my hEX shows as coming as 1Gb/full, it is behaving as if it is coming up as 1Gb/half. If I force it to 100/full, I get full 100/100 throughput. If I set it back to 1Gb/full or auto, I now suddenly have less than a tenth of the upload speed as I do when I force 100/full. Any other router I have in the house does not have this issue. I only have 300/300 from Verizon, so I’m not asking the ONT or my hEX to do any real work here. I believe there may be a hardware issue on the hEX refresh for sure (at least when using ETH1 to connect to the ONT). I have tried virtually every setting combination I can think of on my hEX (countless hours tinkering), and it doesn’t behave properly until I throw a switch between it and my ONT. Makes no difference if I have flow control turned on or off for my particular issue.
If anyone believe to have found a bug, in software or hardware, they should report the issue to Mikrotik directly, opening a support ticket: https://mikrotik.com/support
The forum is only a place where users exchange their experiences, opinions and when possible try and help each other.
@codelogic; FWIW, most FTTH providers use a soft-cap with line speed set to max, meaning that buffering and traffic shaping are handled upstream in the distribution network at the POP switch.
@Larsa thanks for the feedback/input. I’m more of a lurker on the forum here but I’ve seen many of your posts in the past, very informative.
Given my experience with the hAP ax3 on my FiOS circuit and the shared experience by others re: hEX refresh, I am of the opinion that the MikroTik routers are not handling something properly. Other routers (or a dumb switch hooked up in front?!) work just fine without any throughput or latency problems, or fiddling with any settings which need typically need not be touched.
@nomercymayhem Thanks for jumping back into the “mayhem” Your feedback (and others) is quite telling and also points towards some sort of bug/problem for sure on at least the hEX refresh, if not RouterOS entirely.
Makes sense and I agree that the pattern might indicate something is off with how those models (or a specific ethernet PHY) handle certain flow conditions. That said, it’s probably a wise idea at this point to file a bug report with support, and providing a sniffer trace would probably be a good idea too.
Good call on the sniffer trace – if I get some free time this week I’ll see if I can generate multiple packet captures from my “good” routers vs. my hAP ax3. Would probably be very interesting to compare.
Just got FIOS 300mbps installed and had the same slow upload (< 5Mbps) problem. Tried hard setting 1G full and flow control on, but no improvement. Switched WAN to ether 5 (from ether 1) and problem solve. Just followed this video (https://www.youtube.com/watch?v=UvMtn9y7Pkw&t=35s). Had to edit a few firewall rules that referenced ether 1 , but otherwise all worked. Hope this helps.
Ronin, thanks for your reply. Through sheer coincidence, I just went through a mini hardware refresh at my house. In doing so, I borked the config on my HEX refresh and had to reset it to factory defaults.
I finally used this opportunity to swap WAN from eth1 to eth5. I also decided to take the little five port switch out of the equation, and connected straight to the ONT from eth5. After doing some speed tests, I noticed that my performance was no different moving from eth1 to the mini switch to the ONT. My download speed was a full 300, but my upload would only reach around 150, half of what I was rated for.
With my newly-found info, I searched the forums for what folks were doing in this situation, to see if there was any more info on this situation (I haven’t really looked for updated info all year). Found some folks that had good luck turning on flow control on the port in question, in my case, eth5. I turned flow control TX on and RX on, and lo and behold, I’m finally getting my full 300/300 service from Verizon on my HEX refresh. I’m currently running ROS 7.20.2.
In summary, if you are setting up a brand new HEX refresh with Verizon FIOS, here are the steps you should to take:
Change WAN interface from eth1 to eth5.
Remove eth5 from bridge and add eth1.
Change DHCP client to eth5 from eth1.
Set flow control RX on and TX on for port eth5.
That should get you your full bandwidth, download and upload, from Verizon FIOS.
Your feedback (and others) is quite telling and also points towards some sort of bug/problem for sure on at least the hEX refresh, if not RouterOS entirely.