The packet loss goes away under load? I don't know but perhaps a CPU governor is idling your CPU and then a hardware buffer is dropping packets because it's not being served?
@dlakelan
That sounds like something is horribly broken if you get congestion with that kind of bandwidth. I have several connections that are 10mbit+ which works perfectly fine incl VoIP however about all run FreeBSD boxes as routers except one (OpenWrt) which also seems fine.
@Conno
How are you measuring packet loss (against your local gateway or something else)? PPPoE? I can tell you're pushing with it trying to do QoS reliably at 500mbit and it will also struggle with PPPoE at those speeds. Does it occur on the router itself (netdata + fping for instance)? Is it still an issue if you try a snapshot (master)?
Nope. That's not how this works. TCP continues to increase the bandwidth until you get dropped packets. So if you have say a 2 minute video and you upload it to Google Drive which is connected by a FAT pipe (like 40Gbps or 100Gbps) and can handle your gigabit no problem, you will max it out. I can max out my connection with a speedtest no problem.
Perhaps your connections are via DOCSIS cable? The latest DOCSIS standard specifies that the modems have to have queue management built in which makes it seem like there's no need for it on your end. Also it can be built into the head-end.
Also if you're using your ISP's VOIP service, this is getting prioritization over your internet traffic already, I'm sure all those ISP devices with the telephone jack built in give priority to the VOIP packets. Whereas my VOIP is 3rd party and lives on an ATA device behind my router.
Assuming send and receive windows are sufficiently large otherwise you might still see an apparently throttled connection, but no packet loss.
Unlikely, the connection seems to offer symmetric 500/500, until fill-duplex DOCSIS is ready I see no chance of getting 500 Mbps uplinks in the Coax-part of a DOSCSIS network
Yes @Conno has the 500/500 connection, but the question about DOCSIS I was referring to @dizzy
The concern with @Conno's issue is that if it were SQM causing problems, you'd expect to see them under load, and you'd expect to not get a very good speedtest/bufferbloat under load. But he sees this packet droppage at idle... and that suggests some kind of driver problem or cable problem or something else.
@dlakelan
You're wrong and without major tuning (irregardless of OS) you wont saturate 40-100Gbit period. Speedtest is far from very reliable, it can give you an idea but don't rely in the results like the holy grail. I did also suggest that he could turn off QoS earlier. Regarding VoIP, that only applies if you use your ISPs gateway as any latency issue will occur as soon as traffic leaves your local LAN and potentially will increase due to load on backbone and peering points etc, SQM wont help at all in that regard. All connects are non cable (ie DOCSIS).
Just to prove my point regarding speedtest http://www.dslreports.com/speedtest/40161924 (100/100, FTTH, no PPPoE, no SQM/QOS), not 100% dedicated connection during the test which should give you worse results...
The test was silghtly misconfigured*, using 30 streams down and only 6 up is almost guaranteed to give you lower up than down rates. (These multi-stream speedtest make up for the lack of tuning of individual TCP flows to high bandwidths by running multiple TCP-flows n parallel, that combined can saturate a link).
I am assuming here you talk about the imbalance between down 92.7 and up 88.9. Whether 92.7 is actually okay for your link depends pretty much upon what your ISDP considers to be 100 Mbps (even though naively I would have expected goodput around 94-95Mbps).
*) Well as the log shows:
0.00s Start testing Fiber
00.48s Servers available: 7
00.53s pinging 7 locations
05.54s 30ms Darmstadt, Germany, EU
05.54s 32ms St. Ghislain, Belgium, EU
05.54s 33ms Frankfurt, DE, EU
05.54s 33ms Amsterdam, Netherlands, EU
05.54s 36ms Zurich, Switzerland, EU
05.54s 42ms London, UK
05.54s 51ms Dublin, Ireland, EU
05.55s WARNING could not assemble 32 streams with available or selected servers
The configuration was sort of okay, but dsl reports could not satisfy the configuration.
I note that this is tangential to your actual point, so you can just ignore this....
